4 ms·

> Description: The cargo release build does not strip symbols, so they will be included in the final binary. (..) Impact: Since the code is open source, there i

by comex 3y ago

> Description: The cargo release build does not strip symbols, so they will be included in the final binary. (..) Impact: Since the code is open source, there is not much information to be gained, but removing these symbols might make reverse engineering of the binary harder. What a ridiculous finding. I can try to steelman the argument. Sure, maybe "reverse engineering of the binary" is useless most of the time for an open source project because you can just look at the source code. But if there were hypothetically a memory corruption vulnerability in sudo-rs, then an attacker would want to identify the specific machine code corresponding to the vulnerable source, in order to determine how it could be exploited. That wouldn't be too hard to achieve without symbols, but symbols would definitely make it easier. Except… even if the binary has symbols stripped, you can just `apt install sudo-rs-dbgsym`, or use debuginfod, to get the full debug info including symbols and DWARF records. Because distros provide that for all their packages. As a feature. To assist debugging. Even if distros didn't distribute debug symbols, today's security best practices include reproducible builds, which means you should be able to rebuild the package yourself and get the exact same binary, plus the symbols. So while it might save a tiny bit of disk space to strip the symbols, the security benefit is absolutely nil. …Well, in theory anyway. In practice, Debian's sudo-rs package seems to be missing both a dbgsym package and reproducible build info. But that's a bug!

Smaug123 3y ago
That is what "low" means as a vulnerability severity! "Low" means "you totally don't need to do anything about this". The reported property does make the attacker's job slightly harder, after all, since they need to go and work out where the symbols are rather than just having them right there in front of them.
- comex 3y ago
  The problem with the report isn’t just that it’s minor. The problem is that it’s directionally wrong. If the change makes life even slightly harder for attackers, then it makes life harder to exactly the same extent for legitimate users trying to debug their programs. The fact that debuginfo is widely distributed demonstrates that distros prioritize the benefits of debuggability over the benefits of obscurity, and there’s no reason that weighting should be different in the small versus in the large. So, if security and debuggability were the only concerns, debuggability should win and distro binaries should never be stripped. It just so happens that there is an unrelated concern, disk space, that justifies stripping them anyway, but that doesn’t justify characterizing the lack of stripping as a security flaw, not even an incredibly minor one.
3c6bYDXLMj 3y ago
Come off it. That’s what the severity rating is for. Anyone used to reading these sorts of reports comes to expect these things. And someone saying “all you have to do, is simply…” doesn’t change the fact that there’s suddenly more effort involved.
Kab1r 3y ago
You could also always compile it from source with the debug symbols even if it wasn't provided by a distro.
mtlmtlmtlmtl 3y ago
If you can apt-get stuff, why would you be trying to exploit sudo? Even assuming apt-get was the only thing you could run as root, that would essentially allow arbitrary filesystem changes anyway. Escalating to full root from that would be trivial.
- kaba0 3y ago
  You can do that on an identical system you have access to. Then you discover the necessary vulnerability and apply it on the target system.
- codetrotter 3y ago
  You don’t need to be root to retrieve the debug symbols from apt if the debug symbols were in the apt repository Something like apt-get download sudo-rs-dbgsym mkdir -p ~/tmp/ dpkg -x sudo-rs-dbgsym.deb ~/tmp/ should provide what you need I think
deleted 3y ago
[deleted]
kaba0 3y ago
> Even if distros didn't distribute debug symbols, today's security best practices include reproducible builds, which means you should be able to rebuild the package yourself and get the exact same binary, plus the symbols Well, that’s why binary randomization/fuzzing is an important security research topic. If everyone would be running semantically identical, but not binary-identical programs, a ROP-based vulnerability would not be able to spread across computers, or in absence of the correct binary on the target device, it would be infeasible.
- GauntletWizard 3y ago
  This is the very definition of security through obscurity. If everyone were running "semantically identical, but not binary-identical programs" there would be debugging tools to automatically patch your patches for each target device.
  - kaba0 3y ago
    How would that work with fuzzing at the compiler step, say, inlining a non-critical function at a place in one place but not in the other? This is a real security topic, don’t handwave it away without knowing about it.
    - GauntletWizard 3y ago
      The same way any decompilation works - By looking at patterns, understanding how the original compiler worked, and following the execution path as it runs. Antimalware analysts have been doing far more complex for many years, including packed, encrypted, and self-modifying code. It temporarily obfuscates what's going on, but execution tells all. Not that you'd need anything that advanced, when you have the source code and can compare possible fuzzed outputs. ASLR is a real technique that can make targets harder to pop on the first try, giving you time to detect the problem. It does not prevent bugs from being exploited, at least not reliably and for long. This is not a real security topic, this is minor roadbumps, urban myth, and quackery.
      - 3y ago

by comex 3y ago

Smaug123 3y ago

That is what "low" means as a vulnerability severity! "Low" means "you totally don't need to do anything about this". The reported property does make the attacker's job slightly harder, after all, since they need to go and work out where the symbols are rather than just having them right there in front of them.

comex 3y ago
The problem with the report isn’t just that it’s minor. The problem is that it’s directionally wrong. If the change makes life even slightly harder for attackers, then it makes life harder to exactly the same extent for legitimate users trying to debug their programs. The fact that debuginfo is widely distributed demonstrates that distros prioritize the benefits of debuggability over the benefits of obscurity, and there’s no reason that weighting should be different in the small versus in the large. So, if security and debuggability were the only concerns, debuggability should win and distro binaries should never be stripped. It just so happens that there is an unrelated concern, disk space, that justifies stripping them anyway, but that doesn’t justify characterizing the lack of stripping as a security flaw, not even an incredibly minor one.

3c6bYDXLMj 3y ago

Come off it. That’s what the severity rating is for. Anyone used to reading these sorts of reports comes to expect these things. And someone saying “all you have to do, is simply…” doesn’t change the fact that there’s suddenly more effort involved.

Kab1r 3y ago

You could also always compile it from source with the debug symbols even if it wasn't provided by a distro.

mtlmtlmtlmtl 3y ago

If you can apt-get stuff, why would you be trying to exploit sudo? Even assuming apt-get was the only thing you could run as root, that would essentially allow arbitrary filesystem changes anyway. Escalating to full root from that would be trivial.

kaba0 3y ago
You can do that on an identical system you have access to. Then you discover the necessary vulnerability and apply it on the target system.
codetrotter 3y ago
You don’t need to be root to retrieve the debug symbols from apt if the debug symbols were in the apt repository Something like apt-get download sudo-rs-dbgsym mkdir -p ~/tmp/ dpkg -x sudo-rs-dbgsym.deb ~/tmp/ should provide what you need I think

deleted 3y ago

[deleted]

kaba0 3y ago

> Even if distros didn't distribute debug symbols, today's security best practices include reproducible builds, which means you should be able to rebuild the package yourself and get the exact same binary, plus the symbols Well, that’s why binary randomization/fuzzing is an important security research topic. If everyone would be running semantically identical, but not binary-identical programs, a ROP-based vulnerability would not be able to spread across computers, or in absence of the correct binary on the target device, it would be infeasible.

GauntletWizard 3y ago
This is the very definition of security through obscurity. If everyone were running "semantically identical, but not binary-identical programs" there would be debugging tools to automatically patch your patches for each target device.
- kaba0 3y ago
  How would that work with fuzzing at the compiler step, say, inlining a non-critical function at a place in one place but not in the other? This is a real security topic, don’t handwave it away without knowing about it.
  - GauntletWizard 3y ago
    The same way any decompilation works - By looking at patterns, understanding how the original compiler worked, and following the execution path as it runs. Antimalware analysts have been doing far more complex for many years, including packed, encrypted, and self-modifying code. It temporarily obfuscates what's going on, but execution tells all. Not that you'd need anything that advanced, when you have the source code and can compare possible fuzzed outputs. ASLR is a real technique that can make targets harder to pop on the first try, giving you time to detect the problem. It does not prevent bugs from being exploited, at least not reliably and for long. This is not a real security topic, this is minor roadbumps, urban myth, and quackery.
    - 3y ago