On 7/31/23 7:37 AM, 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?
[...]

It seems like there are still ways for a fortran program to interact
with the OS and the environment other than the ones mentioned above. For
example, with open() and close() statements, you can create, delete, and
overwrite files, even without read and write statements.

The detection of many io errors is compiler dependent, even within just
list-directed i/o.

By using assumed size dummy array declarations, for just one example,
one could purposely overrun arrays, allowing the program to both read or
modify memory outside the original array. This is nonconforming code, of
course, but the compiler is not required to detect or report the violation.

Some OSs support things like read-only memory, where for example fortran
constants and parameters can reside, but that is not required by the
fortran standard. Some OSs will randomize memory allocation addresses,
so that the programmer cannot depend on getting fixed addresses from run
to run, but that is also not required by the fortran standard.

The fortran transfer() function basically allows the programmer to put
any sequence of bits into any data value of any data type. Such a
sequence could corrupt existing OS functions, or if executable memory is
not protected, it could result in malicious executable code. It might
not be portable malicious code, it might need to be tailored to a target
machine, but it could be malicious nonetheless.

$.02 -Ron Shepard