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.
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?
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.
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".
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.
