3 ms·

Abusing GDB features for data ingress and egress

72 points by skilled 3y ago

overbytecode 3y ago
I’m confused, why would the debugging information file be an executable? These are just debugging symbols, no?
- matthews2 3y ago
  The debug info is stored in an elf file, just like an executable. You can have them together in the same file, or you can use a tool like objcopy to make them separate.
  - mschuster91 3y ago
    > or you can use a tool like objcopy to make them separate which is how Debian generates the -debug packages [1]. [1] https://github.com/Debian/debhelper/blob/master/dh_strip https://github.com/Debian/debhelper/blob/master/dh_strip
- brancz 3y ago
  DWARF is touring complete and not the accidental kind, it has instructions and all. GDB implements the whole set so you can basically make GDB do arbitrary code execution if you control the DWARF data.
  - jcranmer 3y ago
    As far why it's not accidental, one of the primary purposes of DWARF is to be able to essentially describe "this source-level value is described by f(memory, registers)". Even if you wanted to restrict it to just the simple conditions like "this is described at stack offset N", there are cases where there might be variably-sized objects on the stack, and so you'd need to run a small function just to compute "N".
not2b 3y ago
The security issues are already clearly warned about: the debug info must come from a trustworthy server. But I don't see why a black hat would choose this attack vector. They would have to wait for a developer to debug a binary with shared libraries, while fetching debug info from a a corrupted server. The developer would most likely be using a server provided by a distro (say, Red Hat/Fedora), and if a bad guy can replace the debuginfo files on such a server, they can just as easily replace RPMs directly and feed users malware.
- tovej 3y ago
  Yes, it would me more notable if a client could somehow compromise the server, which may work theoretically as an internal attack vector in a software dev organization. I agree that compromising a distro server is unlikely, but I suppose a mitm attack could be plausible though, and this would give arbitrary code execution. EDIT: or is it ACE? The article seems to emphasize sending arbitrary _data_ to the client, so now I'm confused. If you can make the binary print something else, surely you have ACE? Or do you have to step through the code?
- jmprspret 3y ago
  I kind of agree. But another aide to it is that it would be cool to see in a CTF type challenge.

72 points by skilled 3y ago

overbytecode 3y ago

I’m confused, why would the debugging information file be an executable? These are just debugging symbols, no?

matthews2 3y ago
The debug info is stored in an elf file, just like an executable. You can have them together in the same file, or you can use a tool like objcopy to make them separate.
- mschuster91 3y ago
  > or you can use a tool like objcopy to make them separate which is how Debian generates the -debug packages [1]. [1] https://github.com/Debian/debhelper/blob/master/dh_strip https://github.com/Debian/debhelper/blob/master/dh_strip
brancz 3y ago
DWARF is touring complete and not the accidental kind, it has instructions and all. GDB implements the whole set so you can basically make GDB do arbitrary code execution if you control the DWARF data.
- jcranmer 3y ago
  As far why it's not accidental, one of the primary purposes of DWARF is to be able to essentially describe "this source-level value is described by f(memory, registers)". Even if you wanted to restrict it to just the simple conditions like "this is described at stack offset N", there are cases where there might be variably-sized objects on the stack, and so you'd need to run a small function just to compute "N".

not2b 3y ago

The security issues are already clearly warned about: the debug info must come from a trustworthy server. But I don't see why a black hat would choose this attack vector. They would have to wait for a developer to debug a binary with shared libraries, while fetching debug info from a a corrupted server. The developer would most likely be using a server provided by a distro (say, Red Hat/Fedora), and if a bad guy can replace the debuginfo files on such a server, they can just as easily replace RPMs directly and feed users malware.

tovej 3y ago
Yes, it would me more notable if a client could somehow compromise the server, which may work theoretically as an internal attack vector in a software dev organization. I agree that compromising a distro server is unlikely, but I suppose a mitm attack could be plausible though, and this would give arbitrary code execution. EDIT: or is it ACE? The article seems to emphasize sending arbitrary _data_ to the client, so now I'm confused. If you can make the binary print something else, surely you have ACE? Or do you have to step through the code?
jmprspret 3y ago
I kind of agree. But another aide to it is that it would be cool to see in a CTF type challenge.