3 ms·

>Wouldn't it be more sensible to learn how to design security systems that are hack-proof than to learn how to identify security systems that are dumb? Sure, b

>Wouldn't it be more sensible to learn how to design security systems that are hack-proof than to learn how to identify security systems that are dumb? Sure, but how does one get the knowledge on how to secure systems? Half the job of a security engineer is thinking like an attacker and trying to poke holes in it. Key mitigations like ASLR and stack canaries are so effective because they specifically block off key resources and techniques that attackers use. It would be downright impossible to invent these mitigations (or even meaningfully understand them) if you did not already have a firm grasp on memory corruption and ROP. I'm not sure it's an argument I actually care to defend, but I do honestly believe that you can't be a strong security engineer if you don't have a grasp on the techniques your adversaries use.

riffraff 4y ago
This confused me too, my interpretation is that the author is saying you should not invest time in learning how to use the exploit or scanner du jour. Being aware of the new hacking techniques is ok, but I think this is arguing against vulnerability scanning tools.
worthless-trash 4y ago
As a security engineer, I can't agree more. If you dont understand your enemy, you can not hope to defend against them.
foooobaba 4y ago
With respect to this example, I think he is saying it would be better if we were using memory safe languages, rather than trying to come up with these sorts of mitigations (which is enumerating the bad). Of course it’s probably not possible in every scenario because we’ve been doing it badly for so long, but I think the principle still holds.
- rfoo 4y ago
  Of course we can avoid all the lasting architecture mistakes we made if we knew it before and had been doing it correctly since the beginning. And it's practical, right? Right? See, when there are no "system security" word on it people suddenly start to make sense of it. I'm glad that we are reviewing this 2005 post in 2023 though, at least we can fight hindsight by hindsight. </rant>
- bombolo 4y ago
  Remember the log4j thing? And yet java is memory safe.
  - albntomat0 4y ago
    I find this line of argument frustrating, personally. Yes, memory safe languages have bugs. But, we’ve been spared a world where big enterprise Java apps also have a bunch of trivial stack buffer overflows, in addition to log4j issues. It’s like saying seatbelts are pointless because folks still get hurt in car accidents, while ignoring all the times they saved lives.
  - foooobaba 4y ago
    This has nothing to do with ASLR and stack canaries.. Log4jshell wasn’t a buffer overflow exploit, it was the result of yet another dumb idea, adding remote jndi loading capability into the logging framework. You can assume any input to your program will be manipulated by an attacker. This implies if you use a non memory safe language you’ll need to make sure there is no way the user can input enough data to overflow your buffer, which will corrupt your memory, and get it right 100% of the time. If you’re building a logging framework it’s extremely likely people will be logging some sort of information from the outside, so not a great idea to execute it as code. Similarly for sql injections, if you simply use prepared statements you remove a whole class of problems. Knowing an attacker will probably inject some garbage into the input of your program, and assuming user input is malicious, is a basic principle you can use to design better systems. I believe this is what the author meant by his statement.
    - hnfong 4y ago
      What do we do in practice? - Personally audit all the 392 library dependencies in our project to make sure they don't do anything dumb? - Ask the intern to write a non-dumb logger (and the other 392 deps) from scratch? - Don't use dependencies and write bare metal assembler? (JDK, libc, OS kernels are dependencies and do introduce a steady stream of CVEs) - Give up on doing anything complicated and congratulate myself at being able to write a simple echo service by implementing the whole TCP/IP stack on bare metal?
deleted 4y ago
[deleted]

riffraff 4y ago

This confused me too, my interpretation is that the author is saying you should not invest time in learning how to use the exploit or scanner du jour. Being aware of the new hacking techniques is ok, but I think this is arguing against vulnerability scanning tools.

worthless-trash 4y ago

As a security engineer, I can't agree more. If you dont understand your enemy, you can not hope to defend against them.

foooobaba 4y ago

With respect to this example, I think he is saying it would be better if we were using memory safe languages, rather than trying to come up with these sorts of mitigations (which is enumerating the bad). Of course it’s probably not possible in every scenario because we’ve been doing it badly for so long, but I think the principle still holds.

rfoo 4y ago
Of course we can avoid all the lasting architecture mistakes we made if we knew it before and had been doing it correctly since the beginning. And it's practical, right? Right? See, when there are no "system security" word on it people suddenly start to make sense of it. I'm glad that we are reviewing this 2005 post in 2023 though, at least we can fight hindsight by hindsight. </rant>
bombolo 4y ago
Remember the log4j thing? And yet java is memory safe.
- albntomat0 4y ago
  I find this line of argument frustrating, personally. Yes, memory safe languages have bugs. But, we’ve been spared a world where big enterprise Java apps also have a bunch of trivial stack buffer overflows, in addition to log4j issues. It’s like saying seatbelts are pointless because folks still get hurt in car accidents, while ignoring all the times they saved lives.
- foooobaba 4y ago
  This has nothing to do with ASLR and stack canaries.. Log4jshell wasn’t a buffer overflow exploit, it was the result of yet another dumb idea, adding remote jndi loading capability into the logging framework. You can assume any input to your program will be manipulated by an attacker. This implies if you use a non memory safe language you’ll need to make sure there is no way the user can input enough data to overflow your buffer, which will corrupt your memory, and get it right 100% of the time. If you’re building a logging framework it’s extremely likely people will be logging some sort of information from the outside, so not a great idea to execute it as code. Similarly for sql injections, if you simply use prepared statements you remove a whole class of problems. Knowing an attacker will probably inject some garbage into the input of your program, and assuming user input is malicious, is a basic principle you can use to design better systems. I believe this is what the author meant by his statement.
  - hnfong 4y ago
    What do we do in practice? - Personally audit all the 392 library dependencies in our project to make sure they don't do anything dumb? - Ask the intern to write a non-dumb logger (and the other 392 deps) from scratch? - Don't use dependencies and write bare metal assembler? (JDK, libc, OS kernels are dependencies and do introduce a steady stream of CVEs) - Give up on doing anything complicated and congratulate myself at being able to write a simple echo service by implementing the whole TCP/IP stack on bare metal?

deleted 4y ago

[deleted]