Hello pipacs, > also one cannot help but smile at the irony of divineint (put in charge of security > at RH, no less ;) asking for more proper disclosure. how times change ;). Heads up, I am not divineint, never was. Thanks, Eugene
really. or at least according to one Linus Torvalds, who also happens to be the primary reason for not one, but two! of this year's pwnie nominations for lamest vendor response and most epic FAIL. apparently the fundamental issue he cannot understand is that if they don't know what bugs are security issues, maybe they should find people who do. or maybe bother reading those static checker reports that point them out. just a thought. also one cannot help but smile at the irony of divineint (put in charge of security at RH, no less ;) asking for more proper disclosure. how times change ;). also i guess exploit writers would heartily disagree with the notion that there's no difference between bugs and security bugs :P. anyway, without further ado, here's the latest masterpiece: On Sun, 19 Jul 2009, Eugene Teo wrote: > > If the upstream development community can start doing their part by > differentiating normal bug fixes to the security ones, I think most of > us will benefit from it. Ok, so this is a perfect example of the kind of IDIOTIC blathering that I hate to hear from security people. Quite frankly, people who state things like that ARE FUCKING MORONS. I'm sorry, but it's true. Learn it. Think about it. Deeply, and long. This who security exploit is a prime example of exactly why anybody who says something stupid like that is so stupid and so WRONG.(Continue reading)
_______________________________________________ Dailydave mailing list Dailydave <at> lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave
Hi! > Lets say there's a new bug introduced in the kernel. One that presents with the symptom of disclosing a user's password > when the kernel is given some invalid argument to printk while processing the shadow file. However, when processing > the etc/hosts file, it just discloses the contents of that file. Is that a security bug? You could argue yes; you could argue no. > At the end of the day, someone has to do the work to figure out that it either does or doesn't have security implications. Is the Linux kernel designed to disclose the contents of a file like /etc/hosts? If not, then it is a security bug. A secure system is one which is implemented to EXACTLY fit its specification, nothing more, nothing less. Therefore it doesn't matter whether it discloses one file or some other file or what the contents of these files are. What matters is that it provides more functionality than what the specification of the Linux kernel prescribes. That means that Linus' arguments are simply irrelevant. The biggest security issue in this case is that people take Linus' words seriously and try to bend the discussion in such a way as to fit his words. Or, in other words, these people seem to think that Linus is always right. They seem to forget that Linus is a human being and therefore makes mistakes. People seem to forget that Linus' primary interest is to motivate people to write code for the Linux kernel. And Linus, despite being a competent kernel hacker, doesn't understand security in general. People usually aren't motivated to put time in things which they aren't good at. Groetjes, Peter.
On Sat, Aug 01, 2009 at 01:46:07PM +0200, Peter Busser wrote: > A secure system is one which is implemented to EXACTLY fit its specification, > nothing more, nothing less. Then we are back to "all bugs are security bugs and there is no point in trying to make any distinction". Linus is obviously not interested in trying to make the distinction, you are (although your argumentation seems broken). Linus manages the Linux kernel, you don't. You can keep arguing but I doubt it will make much change regardeless of who is right (not that I fully agree on how Linus is handling (security) bugs or people). Can we go back to discuss interesting technical stuff now please? I like this paper http://vanish.cs.washington.edu/research.html and I think it hasn't been posted here yet. It isn't really breakthrough research or anything (despite what you could expect from the title) but it's an interesting combination of existing technologies although the application field seems rather limited and not really corporate or government-friendly.
_______________________________________________ Dailydave mailing list Dailydave <at> lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave
On 6 Aug 2009 at 21:42, Adrien Kunysz wrote: > On Sat, Aug 01, 2009 at 01:46:07PM +0200, Peter Busser wrote: > > A secure system is one which is implemented to EXACTLY fit its specification, > > nothing more, nothing less. > > Then we are back to "all bugs are security bugs and there is no point in > trying to make any distinction". except we don't live in a black and white world. 'security bug' or heck, just 'bug' is not a binary property, there're many shades of grey in what exactly the bug accomplishes. it's clearly not enough to state that 'this commit fixes something but i did not want to bother to understand what', users of said commits need more information than that. fortunately not all developers share linus' mindset although their efforts are sometimes in vain when what he commits intentionally omits security relevant information. > Linus is obviously not interested in trying to make the distinction, even if he was, he's not qualified to do that so it's a moot point. but he can and should encourage active research because of his position instead of downplaying the issue or outright biting the proverbial hand that feeds him/them.
_______________________________________________ Dailydave mailing list Dailydave <at> lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave
On Fri, Aug 7, 2009 at 11:41, Aaron<apconole <at> yahoo.com> wrote: > The 'shades of grey' only exist to security people. To no one else is it > important > that a bug disclose information, allow invalid root access, or escalate > privileges. Rather, 'shades of grey' only exist to critical thinkers who actually understand the problems. If you really think privilege escalation and information disclosure are esoteric problems that should be relegated only to "security people", I know a few thousand non-security system administrators that would like you to stop whatever you're doing and go flip burgers. Pretending that there is no such thing as a security bug is a childish pretense and is the equivalent of closing your eyes and assuming nobody's there because you can't see them. > So the point still stands, why burden the average kernel developer/debugger > to do > security research work for the security researcher? Because, although rather vocal, researchers compose a numerically insignificant subset of the security "industry". The vast majority are sysadmins, engineers, and programmers that need to prioritize fixes based not only on functionality but on exposure as well. The expectation is not for kernel developers to perform ad-nauseum security analysis of bugs, but for them to exercise due diligence and not suppress security information.
Normally I would, of course, kill this thread, but there's lots of the Linux Kernel/Vendor security community subscribed to the list, and I think it's important for them to hear the story. Right now, Linux kernel security is 5 years behind Windows. There's just no leadership on the issue - and it doesn't have to come from Linus Torvalds or the development leadership. Partially, Linus is right - there really is no way to have developers truly know the security ramifications of every change they commit or every bug they fix. But on the other hand, the GRSecurity team and others have shown that for very little additional investment, one small team of good people (throw a half million USD a year at it and be amazed at the results!), the Linux community could be vastly benefited. Modern software development DOES have to incorporate a security model, and Linux is no exception if it wants to be successful. It's always hard for security vendors to learn the lesson from Andrew Cushman about how to handle security researchers. Quite literally, no matter how much security researchers piss you off, you have to embrace and extend their efforts and their community. It's the only way. Every other way, from Denial, to Legal Threats, to Massive PR Effort, just results in continued failure. If a Linux kernel developer suspects their patch has security relevance, and deliberately hides that in their commit message, they are in the Denial phase. The fact that people can be mean when they point that out doesn't change the real failure. In this case, the best move for Linux as a whole is to develop a security center of excellence, possibly hosted somewhere where multiple vendors can contribute to it, and work together to help with Linux's (kernel) security problems. They can start by going through new kernels and pointing out which changes may be security relevant, while training up key Linux developers on modern security techniques. Otherwise it's just not a fair fight. I do so love a fair fight. :> -dave RB wrote: > On Fri, Aug 7, 2009 at 11:41, Aaron<apconole <at> yahoo.com> wrote: >> The 'shades of grey' only exist to security people. To no one else is it >> important >> that a bug disclose information, allow invalid root access, or escalate >> privileges. > > Rather, 'shades of grey' only exist to critical thinkers who actually > understand the problems. If you really think privilege escalation and > information disclosure are esoteric problems that should be relegated > only to "security people", I know a few thousand non-security system > administrators that would like you to stop whatever you're doing and > go flip burgers. Pretending that there is no such thing as a security > bug is a childish pretense and is the equivalent of closing your eyes > and assuming nobody's there because you can't see them. > >> So the point still stands, why burden the average kernel developer/debugger >> to do >> security research work for the security researcher? > > Because, although rather vocal, researchers compose a numerically > insignificant subset of the security "industry". The vast majority > are sysadmins, engineers, and programmers that need to prioritize > fixes based not only on functionality but on exposure as well. The > expectation is not for kernel developers to perform ad-nauseum > security analysis of bugs, but for them to exercise due diligence and > not suppress security information. > _______________________________________________ > Dailydave mailing list > Dailydave <at> lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave
One idea I had for handling this issue is to train some baysiean classifier's on to all of the given bug's identified for any OSS (this is the fix set). Definitely you could also have a super set of all/any bug you can find, but the benefit of training against the self-similar coding style of some codebase would increase the hit rate. What would be handy, is to retroactively process the commit logs for every line of code, you can then identify the crappy dev's from the not-so-crappy or maybe the just-crappy-close-to-shipcommit dev's (OSS ship = when everyone else in my project says so :). Granted this would not get all security bugs and it will not even get all of anything, except for all that itself finds (hah), but you would be able to identify historically dodgy claims. You could go on to assign security impact ratings to source commits and identify the relative "secureness" of some set of code. You could surely find bugs by using this approach, you would need to modify the strategy a bit. So if we are already training on all "known" security fixes, these will likely be highly uniform in their structure (by the way, would treat the data as opaque really, only leveraging lines added/removed and combinations of that), these are the commits which will be under heavy public scrutiny, as such the dev in question would typically work hard to isolate the exact problem and fix only this 1 issue (fearing high regression or being accused of sitting on a security issue long enough to slip in 1 more feature!). To find future bugs, your going to have to do some root cause failure analysis, which is super easy in this case, by implementing a historyflow ((the best looking :) http://benfry.com/revisionist/, http://www.research.ibm.com/visual/projects/history_flow/, http://sourceforge.net/projects/historyflow/) engine. You can then go from fix (which is present day fact), back to original developer feature, this feature set (heh), looks to the future for bugs in OSS software (this is at the end of the day, the more "fun" work for security people, not arguing semantics with specification jock's (not sec ppl)), given that you can't have too much fun, the work part (or maybe the part to charge $ for), is the fix rater. You can then track the relative need or requirement for businesses to fix a bug in any given OSS codebase. Surely the other metrics are fun and interesting, like who copies who and who the top-worst/best developers are (real world, not some contrived coding competition) no doubt would make some great marketing. Give out all your data 3-6 months retroactively so nobody calls you a liar and sell current data. Seems like some COTS mashup would go far here to get results, I bing'd, citeseer'd and google'd around'd for a minute, did not really find too much of an attempt to do this in any serious way, frankly I'm shocked. I could go on, but really, security is not something for developers to play with, just like features are not something that security people should be playing with. Stay in your own sand box and we can all just get along. Given you can do one or the other, not both, any attempt to do so is an inherent conflict of interest which means that neither interest is being served (i.e. the bias will undo and waste any such effort). Stopping myself from going on now. Shane dave wrote: > Normally I would, of course, kill this thread, but there's lots of the > Linux Kernel/Vendor security community subscribed to the list, and I > think it's important for them to hear the story. Right now, Linux kernel > security is 5 years behind Windows. There's just no leadership on the > issue - and it doesn't have to come from Linus Torvalds or the > development leadership. > > Partially, Linus is right - there really is no way to have developers > truly know the security ramifications of every change they commit or > every bug they fix. But on the other hand, the GRSecurity team and > others have shown that for very little additional investment, one small > team of good people (throw a half million USD a year at it and be amazed > at the results!), the Linux community could be vastly benefited. Modern > software development DOES have to incorporate a security model, and > Linux is no exception if it wants to be successful. > > It's always hard for security vendors to learn the lesson from Andrew > Cushman about how to handle security researchers. Quite literally, no > matter how much security researchers piss you off, you have to embrace > and extend their efforts and their community. It's the only way. Every > other way, from Denial, to Legal Threats, to Massive PR Effort, just > results in continued failure. If a Linux kernel developer suspects their > patch has security relevance, and deliberately hides that in their > commit message, they are in the Denial phase. The fact that people can > be mean when they point that out doesn't change the real failure. > > In this case, the best move for Linux as a whole is to develop a > security center of excellence, possibly hosted somewhere where multiple > vendors can contribute to it, and work together to help with Linux's > (kernel) security problems. They can start by going through new kernels > and pointing out which changes may be security relevant, while training > up key Linux developers on modern security techniques. > > Otherwise it's just not a fair fight. I do so love a fair fight. :> > > -dave > > RB wrote: > > On Fri, Aug 7, 2009 at 11:41, Aaron<apconole <at> yahoo.com> wrote: > >> The 'shades of grey' only exist to security people. To no one else > is it > >> important > >> that a bug disclose information, allow invalid root access, or escalate > >> privileges. > > Rather, 'shades of grey' only exist to critical thinkers who actually > > understand the problems. If you really think privilege escalation and > > information disclosure are esoteric problems that should be relegated > > only to "security people", I know a few thousand non-security system > > administrators that would like you to stop whatever you're doing and > > go flip burgers. Pretending that there is no such thing as a security > > bug is a childish pretense and is the equivalent of closing your eyes > > and assuming nobody's there because you can't see them. > > >> So the point still stands, why burden the average kernel > developer/debugger > >> to do > >> security research work for the security researcher? > > Because, although rather vocal, researchers compose a numerically > > insignificant subset of the security "industry". The vast majority > > are sysadmins, engineers, and programmers that need to prioritize > > fixes based not only on functionality but on exposure as well. The > > expectation is not for kernel developers to perform ad-nauseum > > security analysis of bugs, but for them to exercise due diligence and > > not suppress security information. > > _______________________________________________ > > Dailydave mailing list > > Dailydave <at> lists.immunitysec.com > > http://lists.immunitysec.com/mailman/listinfo/dailydave > _______________________________________________ Dailydave mailing list Dailydave <at> lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave
FWIW, also "insane"
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/1/326479/thread#mid-326479
BTW, personally i agreed on the motivations exposed from Linus in the two thread. But is necessary to look in depth on the discussion.
Regards
On Tue, Jul 28, 2009 at 1:09 AM, <pageexec <at> freemail.hu> wrote:
> really. or at least according to one Linus Torvalds, who also happens to be the
> primary reason for not one, but two! of this year's pwnie nominations for lamest
> vendor response and most epic FAIL. apparently the fundamental issue he cannot
> understand is that if they don't know what bugs are security issues, maybe they
> should find people who do. or maybe bother reading those static checker reports
> that point them out. just a thought.
>
> also one cannot help but smile at the irony of divineint (put in charge of security
> at RH, no less ;) asking for more proper disclosure. how times change ;).
>
> also i guess exploit writers would heartily disagree with the notion that there's
> no difference between bugs and security bugs :P. anyway, without further ado, here's
> the latest masterpiece:
>
>
> On Sun, 19 Jul 2009, Eugene Teo wrote:
>>
>> If the upstream development community can start doing their part by
>> differentiating normal bug fixes to the security ones, I think most of
>> us will benefit from it.
>
> Ok, so this is a perfect example of the kind of IDIOTIC blathering that I
> hate to hear from security people.
>
> Quite frankly, people who state things like that ARE FUCKING MORONS.
>
> I'm sorry, but it's true. Learn it. Think about it. Deeply, and long.
>
> This who security exploit is a prime example of exactly why anybody who
> says something stupid like that is so stupid and so WRONG.
>
> Look at the bug that caused it. Look at the fix. Think about it. When the
> fix was committed, nobody thought it was a security bugfix.
>
> Really.
>
> If you cannot understand this FUNDAMENTAL issue, I don't know what can
> make you do so. I absolutely despise most security people, because they
> are idiots who do not understand development. They are idiots who do not
> understand basic facts. They are idiots, who think the world is some kind
> of black-and-white place where you can sort bugs into 'security' and 'not
> security'.
>
> So here's a few simple rules:
>
> - people who argue for full disclosure are wrong
>
> - people who argue for hiding things and vendor-sec are wrong
>
> - people who think that there are "bugs" and "security bugs" are
> fundamentaly wrong, and misguided, and will always do the wrong thing.
>
> The fact is, bugs are bugs. We don't know which of them are security
> issues. We all make mistakes, and we _fix_ the mistakes, and some of the
> fixes turn out to have way more subtle interactions than people even
> realized!
>
> So you can ask developers to "always think of all the possible issues",
> and you will be left with developers who won't have time or motivation to
> actually do any real work. And they'll _still_ miss some subtle issue, and
> they'll _still_ write code that has bugs.
>
> So how about people face REALITY instead of talking about idiotic
> platitudes like people should be "differentiating normal bug fixes to the
> security ones"? And it _is_ a platitude: it's something that sounds
> "obviously correct", but it's at the same time clearly ignoring the fact
> that reality is complicated.
>
> So f*ck me, shut up about idiotic things like that already!
>
> This whole bug really is a _prime_ example of how the bugfix was not at
> all clearly a security fix at all, even though it obviously was a big
> deal. And a security person who cannot understand that is not a security
> person at all - he's just a f*cking poser.
>
> This is why I detest security lists. Lots of posturing and platitudes. And
> look at who actually did the real work: a regular developer, and a regular
> maintainer, neither of whom were thinking in terms of security.
>
> Security people are leaches. The real heroes are the people who do
> development. The last thing security people should do is to ask the people
> who do the REAL WORK to do more.
>
> Linus
>
> _______________________________________________
> Dailydave mailing list
> Dailydave <at> lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>
_______________________________________________ Dailydave mailing list Dailydave <at> lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave
Hi, On Tue, Jul 28, 2009 at 01:44:38PM +0200, yersinia wrote: > FWIW, also "insane" > > http://kerneltrap.org/mailarchive/linux-kernel/2007/10/1/326479/thread#mid-326479 Strong words indicate a weak cause. And it takes one to know one. Anyways, that is an interesting discussion. It is funny to see Theodor T'So mention that SELinux is insanely complex. Apparently it takes several years for certain Linux kernel hackers to reach conclusions which are totally obvious to others. To summerise the discussion: The only thing which counts is how many lines of code you write for the Linux kernel. It doesn't matter whether you have to work hard to find and understand security bugs so you don't have time left to hack Linux kernel code. And if dare to protest against that, we're going to kick you in the nuts for so long that you will eventually shut up. Then we'll steal your candy, do the Penguin dance, and boast to our friends about how cool we are. You cannot imagine how much respect I have for such people. The biggest problem I have with discussions like that is that they are totally boring, they never end, and they never produce anything useful. I cannot understand how seemingly intelligent people can waste their time on things like that. Groetjes, Peter.
RSS Feed