Would it be accurate to say that a fortran program that reads only from standard in (read(*,*)), writes only to standard out (write(*,*)), and never calls "system" or "execute_command_line" can be offered as a cgi program to the world without any worries about format string attacks, buffer overflows, or creating other intrusion vulnerability for the server, even if it contains fortran code with undefined behavior?

My thought is that the fortran standard specifies that input discard unexpected characters, so that most dangers are eliminated. Is it possible that some compilers are still vulnerable? Would modern features such as pointers make a blanket statement unwise? Are there common operating systems that would not terminate a program that referenced memory assigned to another process? Can a compiled fortran program write over the code segment? I suppose all this depends on the OS, I am only interested in the most common ones - Windows, Linux, OSX.

I did find https://www.open-std.org/jtc1/sc22/wg23/docs/ISO-IECJTC1-SC22-WG23_N1295-24772-8-fortran-draft-after-mtg-20230522.docx (sorry if the URL wrapped) which is about "vulnerabilities", but as far as I can tell, all of the vulnerabilities are about program correctness, not about potentials for intrusion. For instance, it warns about integer overflows, out of bounds array subscripts, loss of information on type conversion, implicit typing, etc. I don't think an of those errors can lead to arbitrary code execution - can they? Is there something simple that would reassure an auditor?

On Monday, July 31, 2023 at 5:37:09 AM UTC-7, Daniel Feenberg wrote:
> Would it be accurate to say that a fortran program that reads only from standard in (read(*,*)),
> writes only to standard out (write(*,*)), and never calls "system" or "execute_command_line"
> can be offered as a cgi program to the world without any worries about format string attacks,
> buffer overflows, or creating other intrusion vulnerability for the server, even if it contains
> fortran code with undefined behavior?

Buffer overflow is harder in Fortran than C, but not impossible.

Some systems have a user "nobody" with minimal privilege.
You can also, with most Unix-like systems, chroot(), which prevents access to files
outside of ones specifically given to the program.

> My thought is that the fortran standard specifies that input discard unexpected characters,
> so that most dangers are eliminated. Is it possible that some compilers are still vulnerable?

The C gets() call is well known for problems. There is nothing quite that bad in Fortran.

> Would modern features such as pointers make a blanket statement unwise?

One interesting attack that otherwise seems to require no privilege is SQL insertion.
(You didn't mention not using SQL.)

Some programs, especially CGI, take input data and use it as part of an SQL query.

If someone puts in SQL commands, instead of, for example, their name,
and the program passes that onto the DBMS, it is possible to attack the data
base system itself. Extract data that they weren't supposed to, or delete data.

Some DBMS might even have the ability to execute system commands.

> Are there common operating systems that would not terminate a program
> that referenced memory assigned to another process?

Modern Windows and any Unix-like system, should be good at that.

> Can a compiled fortran program write over the code segment?

Usual 32 bit systems, overlap the code and data segments.
There are some tricks that are supposed to stop overwriting code.
I am not sure you can make a blanket statement about them.

> I suppose all this depends on the OS, I am only interested in the most common ones - Windows, Linux, OSX.

Daniel Feenberg <feenberg@gmail.com> schrieb:
> Would it be accurate to say that a fortran program that reads
> only from standard in (read(*,*)), writes only to standard out
> (write(*,*)), and never calls "system" or "execute_command_line"
> can be offered as a cgi program to the world without any worries
> about format string attacks,

That is true. Format string attacks are not a concern in Fortran.
You can exactly determine the width of an output string, for
example, but you have to live with having it filled up with asterisks
if it overflows.

>buffer overflows,

No worries - no. Arrays can overflow, as can strings. Fortran is a bit
better than C because it can pass lengths together with arrays or
strings, but it can still be problematic. That depends on how you
write the code.

> or creating other intrusion vulnerability for the server, even if
> it contains fortran code with undefined behavior?

Unlike C, Fortran has no concept of undefined behavior written into
the standard. It has errors that a compiler must detect (or it's
a compiler error) in the constraints. Also, it has many places where
"shall" is used, for example for out-of-bounds array accesses.

If the code violates such a directive, you are on your own as far
as the standard is concerned, and a change in compiler version or
options could give different and unexpected results.

> My thought is that the fortran standard specifies that
> input discard unexpected characters,

It does not. Unexpected characters lead to errors, which are
usually detected by the runtime library and which lead to
the program's termination. You can check for errors yourself,
but then you have to deal with them.

>so that most dangers are eliminated.

If "program terminates on unexpected input" is acceptable to you, then
Fortran is indeed easier to make safe than, for example, C, where
you have to do all checking yourself.

>Is it possible that some compilers are still vulnerable?

It is usually not the compilers which are the problem, it is
the code. If you can spare the cycles, you might want to enable
as many run-time checks as possible, for example bounds checking.

> Would modern features such as pointers make a blanket statement
> unwise?

Fortran has allocatable variables, which take a huge load of a
programmers's shoulders - they are deallocated when they go
out of scope.

>Are there common operating systems that would not terminate
>a program that referenced memory assigned to another process? Can
>a compiled fortran program write over the code segment?

Usually, code segments are read-only. Another issue is executable
stacks, which are vulnerable in principle when overwritten.

>I suppose all this depends on the OS, I am only interested in
> the most common ones - Windows, Linux, OSX.

Code pages should usually be read-only.

> I did find
> https://www.open-std.org/jtc1/sc22/wg23/docs/ISO-IECJTC1-SC22-WG23_N1295-24772-8-fortran-draft-after-mtg-20230522.docx
> (sorry if the URL wrapped) which is about "vulnerabilities", but
> as far as I can tell, all of the vulnerabilities are about program
> correctness, not about potentials for intrusion. For instance, it
> warns about integer overflows, out of bounds array subscripts, loss
> of information on type conversion, implicit typing, etc. I don't
> think an of those errors can lead to arbitrary code execution -
> can they?

Out of bounds subscript are indeed a classic vulnerability -
probably not as common as in C, where the routinely occur
in strings, but still a problem.

Integer overflow can also lead to out-of-bounds subscripts.

>Is there something simple that would reassure an auditor?

Hmm... depends. Running with most run-time checks enabled
(and a paranoid compiler, nagfor is known to be the most
paranoid with the right option) could go a long way.

On Monday, July 31, 2023 at 5:37:09 AM UTC-7, Daniel Feenberg wrote:
> Would it be accurate to say that a fortran program that reads only from standard in (read(*,*)), writes only to standard out (write(*,*)), and never calls "system" or "execute_command_line" can be offered as a cgi program to the world without any worries about format string attacks, buffer overflows, or creating other intrusion vulnerability for the server, even if it contains fortran code with undefined behavior?

More than one Fortran compiler for Linux enables code execution privileges on the stack segment of an executable program to ease their implementation of "thunks" for using internal procedures as procedure pointer targets and actual procedure arguments, so I think that it might actually be easier to hack into those binaries.

On Mon, 31 Jul 2023 10:58:53 -0700 (PDT)
gah4 <gah4@u.washington.edu> wrote:

> The C gets() call is well known for problems. There is nothing quite
> that bad in Fortran.

gets() was deprecated in the 1999 C standard and was removed in the
2011 standard.

Spiros Bousbouras <spibou@gmail.com> wrote:
> gets() was deprecated in the 1999 C standard and was removed
> in the 2011 standard.

The manual page for gets(3) says the following on Fedora 38:

==================================================================
Never use gets(). Because it is impossible to tell without knowing
the data in advance how many characters gets() will read, and
because gets() will continue to store characters past the end of
the buffer, it is extremely dangerous to use. It has been used to
break computer security. Use fgets() instead.

For more information, see CWE-242 (aka "Use of Inherently Dangerous
Function") at http://cwe.mitre.org/data/definitions/242.html
==================================================================

gets() was a big mistake right from the start. It should not
have been invented at all, but the C Standard Library designers
were human and unfortunately they could not conceive a perfect
set of functions.

Another useless but not dangerous C function is creat(2). There
is no point in having it, since open(2) suffices.

Anyway, all C programmers have avoided cursed gets(3) function
for decades.

br,
KK

Thanks to everyone for all the discussion. It looks like Fortran is immune under the conditions I specified. (all I/O is to "(*,*)", there are no open or close statements and no other calls to the system) there are probably no possibilities for user input to result in executing arbitrary code. I do compile with subscript checking, but that is only one way to reference memory improperly. The only worrisome comment is the note that the stack is executable in Linux, but without a buffer overflow or format string attack, it may be impossible to get intrusion code onto the stack. It would be remarkable if an input statement could affect (for example) the value of a subroutine name passed as an argument to a subroutine.

I did try compiling "read(*,*) a" and feeding it a few billion spaces. It didn't disturb anything. so I believe gfortran at least is discarding the input it doesn't need to evaluate.

Again, thanks to everyone.

Kalevi Kolttonen <kalevi@kolttonen.fi> schrieb:
> Spiros Bousbouras <spibou@gmail.com> wrote:
>> gets() was deprecated in the 1999 C standard and was removed
>> in the 2011 standard.
>
> The manual page for gets(3) says the following on Fedora 38:
>
>==================================================================
> Never use gets(). Because it is impossible to tell without knowing
> the data in advance how many characters gets() will read, and
> because gets() will continue to store characters past the end of
> the buffer, it is extremely dangerous to use. It has been used to
> break computer security. Use fgets() instead.

I wrote that part :-)

Thomas Koenig <tkoenig@netcologne.de> wrote:
> I wrote that part :-)

Well done. It is a very clear warning.

br,
KK