Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Kerckoff's principle only applies to crypto. "Security by obscurity" is used in oodles of systems security applications and broader contexts involving human behavior.

Very very ordinary security best practices rely on obscurity. ALSR is a good example. It is defeated by a data exfiltration vulnerability but remains a useful thing to add to your binaries. Because outside of the crypto space security is an onion and layers add additional cost to attackers.



ASLR is not security by obscurity. The addresses into which all the various things are mapped are secret in the same sort of way as cryptographic secret and private keys are secret, but the mechanism is not secret.


Sure it is. The layout randomization is not at all like a cryptographic secret because it can be extracted from the contents of the binary. Kerckoff's principle means that adversary gets access to literally everything except the private key. If you've got access to the contents of the binary then you can get around aslr.


What? No, the actual addresses as-loaded at run-time are randomized, that's the point of ASLR, and those addresses are secret-like because we don't want an attacker to be able to craft an exploit that works against a running instance of the victim code -- we want whatever exploit they have that needs loaded addresses to fail because it doesn't know those address. ASLR itself is not secret, but the run-time addresses are.

In order to be able to randomize addresses of loaded libraries at run-time... the shared objects need to be built as position independent code, so you can't extract the actual addresses "from the contents of the binary". I suspect you're referring to the fact that in ELF the executable itself is not subject to ASLR unless it's built as a PIE.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: