lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: mitch_hurrison at ziplip.com (mitch_hurrison@...lip.com) Subject: No Subject (re: openssh exploit code?) Hi Paul, > Admins and management base decisions on those differences. Now > let's look at the case at hand, which you characterize as > "devastating". Yes, lets. > Note the words "may......cause a denial-of-service condition" and > "may.....execute arbitrary code". It is those vagaries that folks > who run large networks need clarified. If something *may* cause a > problem, the correct preventative action could be entirely > different from something that *will* cause a problem. Decisions > about whether or not to take critical services offline **right > now** for patching are *frequently* based on those nuances in > wording. Then this means that, if you as an admin cannot rely on the proper designated outlets for security alerts. You are forced to seek guidance in the public realm? That's an awfully big dependence on people who are in no way employed by your organisation. > First of all, I object to your characterization of an entire > organization based on the *alleged* actions of one individual. > And I would ask you to ask yourself, *why* do you feel the need > to make such statements? Because I'm a condescending jerk, remember? How would you feel about returning to the old, pre full disclosure, state of affairs. Where admins of government networks, university networks and any other admin that could prove they had a valid use for the information, were privvy to private security bulletins. Allowing them to internally disclose the details needed for the confirmation of exploitability of a certain issue. Without hanging out their dirty laundry for all the world to see? Personally I'd love to see a return to the days of old. A public exchange of exploits and the methodologies involved is an illogical and irresponsible way of going about things. By atleast attempting to keep something that can be considered weaponry in a time of network dependance, from a largescale audience you eliminate alot of noise, and eventually eliminate the untalented people out there who are still writing papers on formatstring abuse and posting lnx86.S execve opcodes. I think both the administrator community as the true hacker community is willing to go back to this state of affairs. Most of us are confident enough in our own research abilities that we won't suffer from a public dry-out of cookbook bug reports and exploits. It's only those who can't think for themselfs and be creative in their use of a debugger who get worried at this notion. Because at the end of the day, that's all exploit dev is. Creative debugging. That's why I'm so opposed to even linking to pre-fab papers on exploiting any "technique" of sorts. There is no such thing as a set technique. Exploit dev is based on everyday real life skills that any CS major should be familiar with. There is no magic secret. And that's why so many people doing real exploit dev refuse to recognise the info-sec world as a legitimate business. You're using skills that cover an innate understanding of the architecture in question to debug a certain bug in a software implementation using that architecture. You're just looking at the debugging process from a different viewpoint. Now this includes understanding how a certain malloc implementation functions, or determining how the heap is used in a certain application. These are all skills any competent CS professional and/or enthusiast should be, or atleast could be at home with. Now having a sparkle of creativity or original thought in you, that's a different story. But I'm digressing.. Sure there will be the occasional leak in a non-disclosure enviroment, sure there will be the occasional hack. But isn't "occasional" preferable to a state in which every dimwit in the world is armed to the teeth with an arsenal of exploits? By taking away the spoonfeeding of exploits and exploit research you dissolve a large part of the problem. It's not like it would be some great unjustice, you're just forcing people to think for themselfs again. Hopefully leading to a "you want the exploit? well go ahead and write it"-mentality. So yeah, there should be no need for the public disclosure of exploits. And if there is a valid need for exploit confirmation this disclosure should occur in a closed forum. That way hackers can get back to hacking, and admins can get back to adminning. Full disclosure is an excersise in futility. With regards, Mitch
Powered by blists - more mailing lists