Re: Gera's Insecure Programing abo7

[Shaun Clowes <shaun () securereality com au>]

Hi Sin,

> I'm working on Gera's insecure programing stuff, currently on abo7; as i
> understand it, this is unexploitable on most (all?) current platforms
> because of the order the sections are linked in?

I haven't looked at Gera's examples so my answers are based entirely on the 
issues you mentioned.

> 1) what exactly is .dynamic used for?

The dynamic section corresponds exactly to the dynamic segment, it exists 
to provide important information to the dynamic linker at run time. It's 
quite well covered in the ELF specification, which can be found translated 
into plain text at:

http://www.muppetlabs.com/~breadbox/software/ELF.txt

> I mean obviously its something to do
> with dynamic data of some sort, I assume libc symbol stuff? What I am more
> asking is, where can I find more information on it; what exactly belongs
> where in .dynamic?

The following is a typical dynamic segment:

bash-2.05b$ readelf -d /bin/ls

Dynamic segment at offset 0xf4b0 contains 21 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

- These are the shared libraries needed by the program, expressed as 
offsets into the dynamic string section

 0x0000000c (INIT)                       0x80490d4
 0x0000000d (FINI)                       0x80538bc

- These are pointers to the initialization and termination functions, optional

 0x00000004 (HASH)                       0x8048148
 0x00000005 (STRTAB)                     0x804893c
 0x00000006 (SYMTAB)                     0x80483bc
 0x0000000a (STRSZ)                      943 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)

- These point to the symbol tables and hash tables used to resolve external 
symbols needed by the program, e.g printf

 0x00000015 (DEBUG)                      0x0

- This is a pointer to dynamic linking debug information, filled in at run 
time

 0x00000003 (PLTGOT)                     0x8058594
 0x00000002 (PLTRELSZ)                   640 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x8048e54
 0x00000011 (REL)                        0x8048e2c
 0x00000012 (RELSZ)                      40 (bytes)
 0x00000013 (RELENT)                     8 (bytes)

- These point to various relocation information indicating how the 
executable image should be modified in order to be able to reference and 
call external symbols

 0x6ffffffe (VERNEED)                    0x8048d9c
 0x6fffffff (VERNEEDNUM)                 2
 0x6ffffff0 (VERSYM)                     0x8048cec

- These point to versioning information which allows the executable to 
require particular versions of libraries/functions

 0x00000000 (NULL)                       0x0

- The dynamic segment always ends with a NULL entry

> (this question applies to really all sections; where
> can i find specific information pertaining to like the plt, rplt, etc; ive
> read some about them, and i have a working idea of what they do, just
> looking for more details)

In the ELF specification

> 2) there is no way i can just overwrite .dynamic and change the 0's to say
> 01's is there?

Hmmm... this could possibly work, the dynamic linker reads most of the 
information it needs before it begins process execution, from then on it 
only needs the dynamic section when it is called to resolve external 
symbols. Perhaps if you used the LD_BIND_NOW environment variable to 
resolve all symbols immediately at startup the section could be safely 
overwritten. Not sure.

> 3) how far back into gcc history do i need to dig to get a version that
> assembles the sections in a different order. (is this a gcc thing? an as
> thing? or a glibc thing? [i realize this isnt gnu specific])

This isn't a gcc thing, it's a GNU ld (linker) thing. But I wouldn't get my 
hopes up about finding one that does things much differently.

Cheers,
Shaun