Re: Why no security support for binutils? What to do about it?
On Wed, 2020-01-01 at 10:29 +0100, Elmar Stellnberger wrote: >Up to now I did not see any notable effort to support malware reverse > engineering under Linux. The only program I knew was boomerang for > decompiling malware but it seems to be unsupported since long. I would > really be in need of such software since I have plenty of images of > rootkitted installations and tampered BIOS images (f.i. one does not > boot via USB and does not allow BIOS updates; you can not get rid of it > unless you flash the BIOS chip of you mainboard externally). There are lots of such tools, examples: peframe Radare/Cutter radare-uefi (not in Debian) Ghidra (not in Debian) RetDec (not in Debian) If you want to package the missing ones, check out this: https://mentors.debian.net/intro-maintainers -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Why no security support for binutils? What to do about it?
> Some of its checks look inherently dangerous, e.g. the bash -n check for > shell syntax. Why would bash -n be dangerous? signature.asc Description: OpenPGP digital signature
Re: Why no security support for binutils? What to do about it?
* Paul Wise: > On Wed, Jan 1, 2020 at 1:00 PM Florian Weimer wrote: > >> Doesn't lintian on ftp-master use disposable VMs? > > No mention of qemu/kvm in dak.git nor any qemu processes running on > ftp-master.d.o, so I don't think so. Uh-oh. >> Some of its checks look inherently dangerous, e.g. the bash -n check for >> shell syntax. > > What is dangerous about `bash -n`? IIRC that is supposed to not > execute shell code, but I guess you mean that the shell parsers in > Debian (bash/dash/etc) are particularly fragile? Yes, exactly. > The same can probably be said for the manual page checks and > probably other parts of lintian. Which means that it's not reasonable to make lintian checks part of the trusted computing base. And objdump (or BFD/binutils) is just a tiny aspect of that. Just to be clear here, I'm not saying that a safe objdump or GDB wouldn't be useful. (Trusted GDB across container binaries could be quite interesting.) It's just unrealistic that it's possible to achieve anything close to that with the current code base.
Re: Why no security support for binutils? What to do about it?
* Daniel Reichelt: >> Some of its checks look inherently dangerous, e.g. the bash -n >> check for shell syntax. > > Why would bash -n be dangerous? In the past, the bash parser was not very successful at inhibiting command execution. I doubt that this has changed, although some corner cases have been fixed.
Re: Why no security support for binutils? What to do about it?
On Wed, Jan 1, 2020 at 1:00 PM Florian Weimer wrote: > Doesn't lintian on ftp-master use disposable VMs? No mention of qemu/kvm in dak.git nor any qemu processes running on ftp-master.d.o, so I don't think so. > Some of its checks look inherently dangerous, e.g. the bash -n check for > shell syntax. What is dangerous about `bash -n`? IIRC that is supposed to not execute shell code, but I guess you mean that the shell parsers in Debian (bash/dash/etc) are particularly fragile? The same can probably be said for the manual page checks and probably other parts of lintian. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Why no security support for binutils? What to do about it?
* Paul Wise: > On Tue, Dec 31, 2019 at 9:47 AM Florian Weimer wrote: > >> BFD and binutils have not been designed to process untrusted data. >> Usually, this does not matter at all. For example, no security >> boundary is crossed when linking object files that have been just been >> compiled. > > There are definitely situations where vulnerabilities in binutils > (mostly objdump) are important and a security boundary could be > crossed, for example; running lintian on ftp-master, malware reverse > engineering and inspection of binaries for hardening features. Doesn't lintian on ftp-master use disposable VMs? Some of its checks look inherently dangerous, e.g. the bash -n check for shell syntax.
Re: Why no security support for binutils? What to do about it?
On 01/01/20 10:29, Elmar Stellnberger wrote: Up to now I did not see any notable effort to support malware reverse engineering under Linux. The only program I knew was boomerang for decompiling malware but it seems to be unsupported since long. probably here you can find some useful: http://www.backerstreet.com/decompiler/decompilers.htm https://en.wikibooks.org/wiki/X86_Disassembly/Disassemblers_and_Decompilers https://retdec.com/ Ciao Davide
Re: Why no security support for binutils? What to do about it?
Am 01.01.20 um 10:48 schrieb PJ: Maybe ultimately one needs monitors and diff-machines built in hardware (and more or less by oneself). If compilers can be subverted, so can assemblers. It would be really worthwhile to have a decompiler! It is not assemblers that are subverted but machine instructions not executing the way they were specified. If intelligence is everywhere, so is intel. If controlling people is everywhere, so is manipulation. If exercising power goes beyond oneself, so does one's own corruption. I am not corrupt. Overall money gives little motivation to me. Attaining freedom does! The only real solution is in one's own efforts to love, and thus to become one with The One. Those who think they are already there are just blind for what is beyond their perception.
Re: Why no security support for binutils? What to do about it?
Am 01.01.20 um 10:29 schrieb Elmar Stellnberger: > Am 01.01.20 um 03:14 schrieb Paul Wise: >> On Tue, Dec 31, 2019 at 9:47 AM Florian Weimer wrote: >> >>> BFD and binutils have not been designed to process untrusted data. >>> Usually, this does not matter at all. For example, no security >>> boundary is crossed when linking object files that have been just been >>> compiled. >> There are definitely situations where vulnerabilities in binutils >> (mostly objdump) are important and a security boundary could be >> crossed, for example; running lintian on ftp-master, >> malware reverse engineering > > Up to now I did not see any notable effort to support malware > reverse engineering under Linux. The only program I knew was boomerang > for decompiling malware but it seems to be unsupported since long. I > would really be in need of such software since I have plenty of images > of rootkitted installations and tampered BIOS images (f.i. one does > not boot via USB and does not allow BIOS updates; you can not get rid > of it unless you flash the BIOS chip of you mainboard externally). > Maybe ultimately one needs monitors and diff-machines built in hardware (and more or less by oneself). If compilers can be subverted, so can assemblers. If intelligence is everywhere, so is intel. If controlling people is everywhere, so is manipulation. If exercising power goes beyond oneself, so does one's own corruption. The only real solution is in one's own efforts to love, and thus to become one with The One. Those who think they are already there are just blind for what is beyond their perception. > >> and inspection of binaries for hardening features. >
Re: Why no security support for binutils? What to do about it?
Am 01.01.20 um 03:14 schrieb Paul Wise: On Tue, Dec 31, 2019 at 9:47 AM Florian Weimer wrote: BFD and binutils have not been designed to process untrusted data. Usually, this does not matter at all. For example, no security boundary is crossed when linking object files that have been just been compiled. There are definitely situations where vulnerabilities in binutils (mostly objdump) are important and a security boundary could be crossed, for example; running lintian on ftp-master, malware reverse engineering Up to now I did not see any notable effort to support malware reverse engineering under Linux. The only program I knew was boomerang for decompiling malware but it seems to be unsupported since long. I would really be in need of such software since I have plenty of images of rootkitted installations and tampered BIOS images (f.i. one does not boot via USB and does not allow BIOS updates; you can not get rid of it unless you flash the BIOS chip of you mainboard externally). and inspection of binaries for hardening features.
Re: Why no security support for binutils? What to do about it?
On Tue, Dec 31, 2019 at 9:47 AM Florian Weimer wrote: > BFD and binutils have not been designed to process untrusted data. > Usually, this does not matter at all. For example, no security > boundary is crossed when linking object files that have been just been > compiled. There are definitely situations where vulnerabilities in binutils (mostly objdump) are important and a security boundary could be crossed, for example; running lintian on ftp-master, malware reverse engineering and inspection of binaries for hardening features. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Why no security support for binutils? What to do about it?
* Andreas: > there is no security support for binutils in debian stable > (buster). Given the importance of binutils this seems to me to be a real > problem. BFD and binutils have not been designed to process untrusted data. Usually, this does not matter at all. For example, no security boundary is crossed when linking object files that have been just been compiled. All these vulnerabilities do not seem very relevant, so most distributions (not just Debian) focus on fixing other issues instead.
