| +1 I was going to post something similar. Also we often see people insulting others when they post exploits too early or describe exploits in depth too early. Posting stuff like: "You're an .ssh.le, wait a few days before posting that". I don't think so. I think exploits should be publicly posted as soon as possible and affecting as many people as people. Maybe even damaging exploits, actively deleting users data or servers data. The bigger the havoc, the sooner the entire industry is going to realize security is a very real concern. People are still considering buffer overflow, SQL injection, query parameters objects instantiation through deserialization exploits, etc. to be "normal" because "everybody creates bugs" and "a lot of bugs can be exploited". I think it's the wrong mindset. Security if of uttermost importance and should be thought of from the start. For example I'm amazed by the recent seL4 microkernel which makes buffer overflow provably impossible (inside the microkernel) or even the Java VM (the JVM) which makes buffer overflow in Java code impossible. It's not perfect (we've seen lots of major Java exploits, but zero were buffer overrun/overflow in Java code... Some in 3rd party C libs, but zero in Java code. Some other Java exploits too of course, but zero buffer overrun/overflow). So security exploits are not a fatality. All we need is people, from the very start, to conceive systems more resilients to attacks. The more attacks, the more exploits, the more bad reputation and shame on clueless developers, the better. I actually start to love these exploits, because they fuel healthy research by the white-hat community. And one day we'll have more secure microkernels, more secure OSes, more secure VMs, more secure protocols, etc. Let them security exploits come. |