9 ms·

> "In almost all cases, whether or not there's a known local privesc bug, assume that code execution on your Linux systems equates to privesc; this is doubly tr

> "In almost all cases, whether or not there's a known local privesc bug, assume that code execution on your Linux systems equates to privesc; this is doubly true of machines in your prod deployment environment. It depends. I've seen "oh well if someone has rce they probably have root anyway" used way too many times as an excuse to avoid defense-in-depth measures.

tptacek 10y ago
Those people might be right. Defense in depth is a legitimate tactic, but that's all it is, and it's often an excuse for people to waste time layering stupid stuff on top of real security controls. ASLR, NX, and CFI would be an example of a defense in depth stack that is meaningful. SSH, Fail2Ban, and SPA would be an example of a defense in depth stack that basically just wastes time. I would be more comfortable with a system where I knew I had to burn the box if I lost RCE on it than I would be with a system that somehow depended on RCE not coughing up kernel, and persistence, to an attacker. The other thing defense in depth can provide is increased attacker cost. That's why there are economically valuable DRM systems (BluRay's BD+ is an example here). All you have to do is push attacker cost across a threshold (for instance with BD+, that's keeping titles secure past the new release window) to make a defense in depth control valuable. But if someone has a kernel exploit, probably nothing you've done for defense in depth is going to meaningfully increase costs.
- qwertyuiop924 10y ago
  > That's why there are economically valuable DRM systems (BluRay's BD+ is an example here). All you have to do is push attacker cost across a threshold (for instance with BD+, that's keeping titles secure past the new release window) to make a defense in depth control valuable. A really good example of this is Spyro 3: The developers set up a system of overlapping checksums (which could in turn bet part of the data being checksummed by other, overlapping, checksums) so that it was virtually impossible to change even a single bit without failing the test. It was eventually cracked, as the check only ran at boot time (it required 10 seconds of disk access, and adding 10 seconds to every loading screen in the game would have been unacceptable), which meant it took over two months for pirates to get a crack working (unusual for the time). And since most game sales come in the first two months... But that's really just me using this as an excuse to share a bit of technical trivia.
- timtadh 10y ago
  I'm confused, how is SSH an example of defense in depth? It is an access method. You should absolutely harden your SSH configuration. Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). Managing the keys at scale, well that is a different story. I agree with you that ASLR, NX, and CFI are the most important system level defenses to employ.
  - Jedd 10y ago
    > Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). This assertion confuses me. I use fail2ban on boxes I have key-only ssh configured for. Are you aware fail2ban works for services other than ssh? If an attacker / script knocks unsuccessfully on my ssh door, other doors are then closed to them. I also get much (much!) cleaner logs thanks to fail2ban.
    - timtadh 10y ago
      That is true and a good use case for fail2ban. Useless was probably a strong word, what I really meant was of limited utility in increasing the security of the SSH service.
      - tytso 10y ago
        The main reason I use fail2ban is I got tired of the log file noise/bloat. I use key-only access on my servers already, with the key stored on a hardware token (Yubikey).
        problems 10y ago
        I guess the question then is why you're looking at failed Auth logs. Failed auths are boring, doubly so on a key only server. Successful auths are where the fun is at.
        pm215 10y ago
- fludlight 10y ago
  What's a better alternative to SSH?
- simcop2387 10y ago
  I know what everything else is, but what is CFI? An attempt at googling came up with results that didn't make any sense right away.
  - hannob 10y ago
    Control-Flow Integrity. It's a bit of the new hotness in exploit mitigation, however it's quite complicated and there are various solutions that have different advantages and disadvantages. clang docs: http://clang.llvm.org/docs/ControlFlowIntegrity.html http://clang.llvm.org/docs/ControlFlowIntegrity.html
  - tptacek 10y ago
    Shorter CFI: when doing codegen for calls through function pointers (which will involve indirect calls through registers), emit extra code to make sure the register being jumped to is a legit function, thus breaking ROP payloads. There's more to it, but that's the flavor of it.
- startling 10y ago
  Sure, it can go either way. But in the absence of a kernel 0-day, segregating services on the same host is useful.
  - AstralStorm 10y ago
    And if a kernel 0-day is available, putting the services in a VM might help. Depending on whether an exploitable bug in the hypervisor exists.
- hilop 10y ago
  SSH is a waste of time?

tptacek 10y ago

Those people might be right. Defense in depth is a legitimate tactic, but that's all it is, and it's often an excuse for people to waste time layering stupid stuff on top of real security controls. ASLR, NX, and CFI would be an example of a defense in depth stack that is meaningful. SSH, Fail2Ban, and SPA would be an example of a defense in depth stack that basically just wastes time. I would be more comfortable with a system where I knew I had to burn the box if I lost RCE on it than I would be with a system that somehow depended on RCE not coughing up kernel, and persistence, to an attacker. The other thing defense in depth can provide is increased attacker cost. That's why there are economically valuable DRM systems (BluRay's BD+ is an example here). All you have to do is push attacker cost across a threshold (for instance with BD+, that's keeping titles secure past the new release window) to make a defense in depth control valuable. But if someone has a kernel exploit, probably nothing you've done for defense in depth is going to meaningfully increase costs.

qwertyuiop924 10y ago
> That's why there are economically valuable DRM systems (BluRay's BD+ is an example here). All you have to do is push attacker cost across a threshold (for instance with BD+, that's keeping titles secure past the new release window) to make a defense in depth control valuable. A really good example of this is Spyro 3: The developers set up a system of overlapping checksums (which could in turn bet part of the data being checksummed by other, overlapping, checksums) so that it was virtually impossible to change even a single bit without failing the test. It was eventually cracked, as the check only ran at boot time (it required 10 seconds of disk access, and adding 10 seconds to every loading screen in the game would have been unacceptable), which meant it took over two months for pirates to get a crack working (unusual for the time). And since most game sales come in the first two months... But that's really just me using this as an excuse to share a bit of technical trivia.
timtadh 10y ago
I'm confused, how is SSH an example of defense in depth? It is an access method. You should absolutely harden your SSH configuration. Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). Managing the keys at scale, well that is a different story. I agree with you that ASLR, NX, and CFI are the most important system level defenses to employ.
- Jedd 10y ago
  > Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). This assertion confuses me. I use fail2ban on boxes I have key-only ssh configured for. Are you aware fail2ban works for services other than ssh? If an attacker / script knocks unsuccessfully on my ssh door, other doors are then closed to them. I also get much (much!) cleaner logs thanks to fail2ban.
  - timtadh 10y ago
    That is true and a good use case for fail2ban. Useless was probably a strong word, what I really meant was of limited utility in increasing the security of the SSH service.
    - tytso 10y ago
      The main reason I use fail2ban is I got tired of the log file noise/bloat. I use key-only access on my servers already, with the key stored on a hardware token (Yubikey).
      - problems 10y ago
        I guess the question then is why you're looking at failed Auth logs. Failed auths are boring, doubly so on a key only server. Successful auths are where the fun is at.
        pm215 10y ago
fludlight 10y ago
What's a better alternative to SSH?
simcop2387 10y ago
I know what everything else is, but what is CFI? An attempt at googling came up with results that didn't make any sense right away.
- hannob 10y ago
  Control-Flow Integrity. It's a bit of the new hotness in exploit mitigation, however it's quite complicated and there are various solutions that have different advantages and disadvantages. clang docs: http://clang.llvm.org/docs/ControlFlowIntegrity.html http://clang.llvm.org/docs/ControlFlowIntegrity.html
- tptacek 10y ago
  Shorter CFI: when doing codegen for calls through function pointers (which will involve indirect calls through registers), emit extra code to make sure the register being jumped to is a legit function, thus breaking ROP payloads. There's more to it, but that's the flavor of it.
startling 10y ago
Sure, it can go either way. But in the absence of a kernel 0-day, segregating services on the same host is useful.
- AstralStorm 10y ago
  And if a kernel 0-day is available, putting the services in a VM might help. Depending on whether an exploitable bug in the hypervisor exists.
hilop 10y ago
SSH is a waste of time?