• Why no security support for binutils? What to do about it?

    From Andreas@21:1/5 to All on Tue Dec 31 03:10:01 2019
    Hi,

    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.

    I searched quite some time for reasons for this strange fact, but while
    I found many references to the fact, I didn't find any explanation for
    the reasons for it. Can anybody explain to me, why binutils isn't
    covered or point me to a source giving an authoritative explanation?

    More importantly: What are we as debian users meant to do given the
    lacking security support? What is the best way to supplant the lacking
    security support?

    Thanks a lot in advance

    Andreas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Florian Weimer@21:1/5 to All on Tue Dec 31 10:50:01 2019
    * 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to All on Wed Jan 1 03:20:01 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Wed Jan 1 10:40:02 2020
    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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From PJ@21:1/5 to All on Wed Jan 1 11:00:02 2020
    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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Wed Jan 1 11:10:02 2020
    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.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Florian Weimer@21:1/5 to All on Wed Jan 1 14:10:02 2020
    * 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Davide Prina@21:1/5 to Elmar Stellnberger on Wed Jan 1 13:40:01 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to All on Wed Jan 1 14:20:02 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Florian Weimer@21:1/5 to All on Wed Jan 1 14:20:01 2020
    * 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Florian Weimer@21:1/5 to All on Wed Jan 1 14:30:02 2020
    * 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Daniel Reichelt@21:1/5 to All on Wed Jan 1 14:50:02 2020
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S8qXawoOnPq6nZXC02H25fdLe9qSzXNGx
    Content-Type: text/plain; charset=utf-8
    Content-Language: de-DE
    Content-Transfer-Encoding: quoted-printable

    Some of its checks look inherently dangerous, e.g. the bash -n check for shell syntax.

    Why would bash -n be dangerous?


    --S8qXawoOnPq6nZXC02H25fdLe9qSzXNGx--

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCAAdFiEEg2wMpOXGvc4nunsZnjl+Rc/8gF8FAl4MmTgACgkQnjl+Rc/8 gF8yVg//RZ/KHfMqLK/gCrbAnnQeL6/MDLV2EPeb/hsklnXVvJLD85BP8ooMkVBc U9s1/7FZ7B62eL4/u2amv9RMirZPmGPn0VDGgO6r0vtYQjPybsb298FArSCSSWJb mn/cqe7xlVem8L+AEbxgWZU/jXumSc3yNI+yN8+4+IFfwHaQ1Lhr2TaxIzAgsJeq 4NCOVuAT6HT+cD1NeoMrwn+xZazDHpxn10wonou+ZefXFUVTyKBv2Dvus/nNoRqD Twj+V5YzRpLgKI2ydZhyeBZF5z4QT9FW/GNDDRp9kOuNtN5S7HdPFENNSoWFHOzh Sa2ryYXQgDiuu4W89MlZDwyErmHASB16TsR31dNbYZdFUC6WsI8PixmPp5pDdZwt xim10qo/b7teX9yEQ+ooVJxHcuCVnLeGDzkf/FGU4/vttlar00D7DdNiahOMTjcR om4xHKOnv7o4s1P0FGFvdECdWX0Hk6AFUUvzr5t/rptW6Y44VmMlcVVksUT0qVhY MNgWT4h80s7P/qWYO+Hp177po5qOHxhCb2lNyBETKBI7pxyemvn5NUdFqRxbnG/W ApwNGJGXDY5OabVv2zJugYW2jYb0/SMF/gvYMT866zpCh9cztyV/vvhgT4AZMP4R 6ubphWVtIK+yDRJcupkjsyvvLJPvMpa3xOF2V20A3BfQRLUEE1M=
    =TMgN
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to Elmar Stellnberger on Thu Jan 2 02:40:02 2020
    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

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl4NR+0ACgkQMRa6Xp/6 aaNdVg//f8rPihiHKTgLyfW7+mU47z3PZf7Y3kCx1KQsma6H57qPo821UhrlXn7Q /wn+/5h2uNQNx7M/r2Ywakhame3ysGYEEKAUpT669jurlRsDo3E6pd+qnOOxr3AW gCiTnFG5UEPHQF9L4wHZB48QEKx9weubiWfs79RDHqWSKdhpQWPFIEFbL8j+XkI9 HQnweIRkd8z+VsoKrOiiggS7l/Bw1OPKOprxC3ShFgdzqduN8D3T2HBujPYRCpmc xFUqWx1YKoyDf0aLx9RCYwNXPaQ3yX6NlkI5A4Leqhqn9MnY1vaTFkfA27iwBtNw 1CF29/70kByrmMaEWU0jbGWzI1MtrQlHvM07sGKknpup5O910nd2vSDBX+u4kV01 E/VnLtCEHWFFoAkdOkxnUVCk1eupU52in6KnEd6Z8BjIta+ugOBduABBmhQoKMv/ sD/HooNxuej5w17Fwn1U1mtnvm7aKKXziBkz/vNz2akzro5SCxIiS1MCMg7kZcC4 dbF8tbiGkcX1ScUp5RWZfpK5d64qtXzIyLUbloaxqU7gyCYzt3wKlFvNGyisZN7B Vl93aw5eOEuvgWhJLvWFRu40ozUuNZIDSmafjzoLpfsqv6Ch5/l6bYTmq1PRIEey znSlTGJZIF5wsSIJZ0jxJA+IlFKtLV2S727yDZs5HE3LHX9Iz2s=
    =SQUb
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)