Linux founder Linus Torvalds delivers a smackdown like no other

[Cudni]

from
http://www.attendly.com/linux-founde...like-no-other/
"..
You don’t have to be a Linux user, or even a nerd, to love Linus Torvalds. His arrogant and irreverant sense of humor draws scores of views, shares and upvotes on almost anything he says online.

He cares very little about what others think, and will publicly lambaste anyone he deems deserving. Which to be honest, appears to be most people.
.."

[CogitoTesting]

Wow. I love Linux but I think that guy is using too much of whatever he is taking.

[Hungry Man]

Linus is generally just the type of person who says what they think. He simply has the clout to pull it off most of the time. Though I disagree with his "bugs are bugs" philosophy towards security and I think that it actually has caused significant hard to the Linux kernel.

There are advantages to running Linux, and there are disadvantages. IMO Linus Torvalds is both.

[Kyle1420]

Haha I love it.

[safeguy]

"Like it or hate it - I don't care."

That's Linus Torvalds for you.

[NGRhodes]

Originally Posted by Hungry Man

Though I disagree with his "bugs are bugs" philosophy towards security and I think that it actually has caused significant hard to the Linux kernel.

Why do you think that ?

[Hungry Man]

It's led to a lot of downplaying of security vulnerabilities in the kernel. It's also just the wrong attitude - bugs and vulnerabilities do not effect people the same way. If I can crash a server I've done damage to a company. If I can hack a server I've done damage to the company and I've done damage to the customers and it's far more costly.

[NGRhodes]

Originally Posted by Hungry Man

It's led to a lot of downplaying of security vulnerabilities in the kernel. It's also just the wrong attitude - bugs and vulnerabilities do not effect people the same way. If I can crash a server I've done damage to a company. If I can hack a server I've done damage to the company and I've done damage to the customers and it's far more costly.

Server crash could do as much damage as a hack.

[Hungry Man]

Anything can do anything. A horrible bug that causes physical damage to the system might cost a company more than a vulnerability that allows for some encrypted database to be pulled. But the potential for damage is greater with a potentially exploitable vulnerability.

Bugs will cause data loss, vulnerabilities will cause data theft.

[NGRhodes]

Originally Posted by Hungry Man

Anything can do anything. A horrible bug that causes physical damage to the system might cost a company more than a vulnerability that allows for some encrypted database to be pulled. But the potential for damage is greater with a potentially exploitable vulnerability.

Bugs will cause data loss, vulnerabilities will cause data theft.

A bug can be just as damaging an exploit, exposing private data publically for example, will have exactly the same impact as hacking the same data.

[Hungry Man]

What you're describing sounds like a vulnerability ie: a bug that allows for data to be accessed that could otherwise not be accessed.

Without getting into a useless discussion about the definition of a bug vs vulnerability I would say that my point is that data loss is not as bad as data theft - that a bug/ vulnerability that leads to data theft is worse than a bug/ vulnerability that leads to data loss.

Whether you call it a bug or vulnerability it's the action taken by the attacker to exploit it that matters.

It's the same reason you'll get panics and force closes when certain security violations occur - data integrity is second to data confidentiality.

[NGRhodes]

Originally Posted by Hungry Man

What you're describing sounds like a vulnerability ie: a bug that allows for data to be accessed that could otherwise not be accessed.

No because there is no hostile attack, the data was exposed under normal operating conditions.

Originally Posted by Hungry Man

Without getting into a useless discussion about the definition of a bug vs vulnerability I would say that my point is that data loss is not as bad as data theft - that a bug/ vulnerability that leads to data theft is worse than a bug/ vulnerability that leads to data loss.

It does not matter if the data was accidentally or deliberately compromised. What matters is the data that you have lost control of, not how.

Originally Posted by Hungry Man

Whether you call it a bug or vulnerability it's the action taken by the attacker to exploit it that matters.

No, its the data that has breached that matters.

Originally Posted by Hungry Man

It's the same reason you'll get panics and force closes when certain security violations occur - data integrity is second to data confidentiality.

No, that is just bad handling of erronous conditions, nothing to do with data integrity or confidentiality.

[Hungry Man]

If a bug and a vulnerability both reveal the same amount of information to the public, yes, they are both 'equal' in terms of the result.

If you're separating the two terms based on motive ie: one is accidental and one is deliberate - I think that's fine.

If we define a vulnerability as a weakness that can be exploited and a bug as a weakness that can arise atypically I think the conversation becomes a matter of what happens to that data. If data is exposed by an attacker the motivation is to do harm in some way. If data is exposed otherwise there is no motivation.

This is, of course, a very narrow view where we're looking only at bugs and vulnerabilities that both lead to data disclosure. A bug that leads to a server crashing, for example, would not fall into this - there's no data disclosure and I don't think it's worth really discussing whether that's worse than having actual data theft, if you think that it is I'm not really that interested in discussing potential costs and risk assessments - I believe that theft is worse than loss.

I disagree with "a bug is a bug". The mentality has led to patches being labeled in ways that downplay the importance or even patches that don't hint that it's a security issue.

I also just think it's wrong. Some bugs are worse than others. A vulnerability that can be exploited by an attacker is worse than a bug that may be accidentally triggered.

The attacker, the motivation behind the attack, are what make vulnerabilities worse.

Linus Torvalds
Linux kernel non-disclosure policy

Proving that open-source security has not improved much since it relied on the idea of getting enough eyeballs to make bugs shallow, Linus Torvalds demonstrated his incompetence at handling security issues by defending silent patching of security vulnerabilities in the Linux kernel:

So I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special.

Adding insult to injury:

Btw, and you may not like this, since you are so focused on security, one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior.

It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important.

For more background on the current Linux security fiasco, see this thread on Dailydave.

http://pwnies.com/archive/2008/nominations/

edit:

No, that is just bad handling of erronous conditions, nothing to do with data integrity or confidentiality.

No. If I exploit a program I'm doing something that the program didn't consider ie: an erroneous condition. The program can still continue. What's supposed to happen is the program terminates - that's why when violations occur programs terminate, not because exploits actually shut them down. There's also exception handling, which you can obviously build into the program - but that's less about violations and more about dealing with bad input or input validation ie: if (x == true) return 0 if (x !== true) return -1. This doesn't play into termination for something like NX violation that much from what I can see. I don't see how it would.

[Kyle1420]

I really don't see what the point of this discussion is? Everyone is entitled to their opinion.. If you don't like it, That's ok.. You have your own opinion.

From my understanding, Linus at no point said security isn't important..He just states that there is more bugs.. like everything else. It's not to say that he avoids or ignores them.

The good thing about Linux is it is not one persons ideology, It's a collaboration of a very large group of people with no single goal or direction.. This is what pushes linux and ensures that it evolves. E.G You will get people who work with servers, they may find a security flaw, They'll fix it.. and push it to the kernel team for the rest of the community to benefit, the same goes for almost anything...and that is why I like linux.

Remember, That linux is a contribution of many many people, not just a single person or team..

I like his style haha

[Hungry Man]

I think discussion of opinions is generally the point of a forum.

From my understanding, Linus at no point said security isn't important..He just states that there is more bugs.. like everything else. It's not to say that he avoids or ignores them.

He does though. This has been shown multiple times throughout upstream kernel management - they do not take security seriously and a lot of that is Linus. Whether it's downplaying the importance of a bug to not tracking and reporting to vendors it is clear that the "a bug is a bug" is effecting the kernel.

Remember, That linux is a contribution of many many people, not just a single person or team..

And this is its saving grace. The fact that you can basically fork the kernel and have people who understand security deal with the issues at hand ie: pax team and Spender. That's why Linux is so secure. But upstream 'vanilla' Linux? That's suffering. And as long as the current system is in place where upstream is governed the way it is that's not going to change.

[NGRhodes]

Originally Posted by Hungry Man

No. If I exploit a program I'm doing something that the program didn't consider ie: an erroneous condition. The program can still continue. What's supposed to happen is the program terminates. - that's why when violations occur programs terminate, not because exploits actually shut them down

Why do you think the program is supposed to terminate as opposed to have suitable error handling ?
If you use properly scoped and segregated code it is possible to catch errors in sub routines, and gracefully exit that sub routine, destroying any data created in the scope of that sub routine and continue to execute or shutdown to correctly exit with error conditions, roll back pending transactions rather than a pure dumb exit. Improper error handling is what leads to a lot of exploitations in the first place, correcting the error handling is far more graceful than just forcibly terminating.

Originally Posted by Hungry Man

There's also exception handling, which you can obviously build into the program - but that's less about violations and more about dealing with bad input or input validation ie: if (x == true) return 0 if (x !== true) return -1.

No. That is data validation, exception handling is meant to capture the unknown conditions, such as talking to external resources that you can't control the behaviour of. Validation occurs in the normal operational state of running code, exception handling actually freezes the state and allows the system to manipulate that state to recovery/repair/rollback/exit from that specific state (note its not the code itself that handles exceptions).

Cheers, Nick

[NGRhodes]

Originally Posted by Hungry Man

If a bug and a vulnerability both reveal the same amount of information to the public, yes, they are both 'equal' in terms of the result.

If you're separating the two terms based on motive ie: one is accidental and one is deliberate - I think that's fine.

If we define a vulnerability as a weakness that can be exploited and a bug as a weakness that can arise atypically I think the conversation becomes a matter of what happens to that data. If data is exposed by an attacker the motivation is to do harm in some way. If data is exposed otherwise there is no motivation.

This is, of course, a very narrow view where we're looking only at bugs and vulnerabilities that both lead to data disclosure. A bug that leads to a server crashing, for example, would not fall into this - there's no data disclosure and I don't think it's worth really discussing whether that's worse than having actual data theft, if you think that it is I'm not really that interested in discussing potential costs and risk assessments - I believe that theft is worse than loss.

I disagree with "a bug is a bug". The mentality has led to patches being labeled in ways that downplay the importance or even patches that don't hint that it's a security issue.

I also just think it's wrong. Some bugs are worse than others. A vulnerability that can be exploited by an attacker is worse than a bug that may be accidentally triggered.

The attacker, the motivation behind the attack, are what make vulnerabilities worse.

Agreed !
When we assess reported issues, we do it from the perspective of the end user of our code and usually as a result security issues get given higher than normal priority.

[Nevis]

Whatever he says, I dont care, I admire him for what he had done.

[Hungry Man]

Using return codes is exception handling. It can also be used for data validation.

Why do you think the program is supposed to terminate as opposed to have suitable error handling ?
If you use properly scoped and segregated code it is possible to catch errors in sub routines, and gracefully exit that sub routine, destroying any data created in the scope of that sub routine and continue to execute or shutdown to correctly exit with error conditions, roll back pending transactions rather than a pure dumb exit. Improper error handling is what leads to a lot of exploitations in the first place, correcting the error handling is far more graceful than just forcibly terminating.

I don't think that - but with error handling it basically takes the error up the 'chain' of scope and if it can be dealt with it is and if not the program is terminated. And you can use destructors and other methods of error handling. I'm saying that in the event that a program doesn't know what to do, as in after the exception handling, the program is terminated because that's the safest alternative to allowing it to run. The exploit itself (well, it can) isn't what shuts it off, the system doesn't care if two bytes of executable data exist that shouldn't exist unless the system is told to care.

And you're correct, incorrect error handling is dangerous. That's why there's safe and unsafe exits.

But then again you're probably better at programming and I haven't gone into error handling much. This is based on what I do know.

[Mrkvonic]

Security is overplayed. I agree with Linus and Nick.
Mrk

[Hungry Man]

And I agree with Brad Spengler and Dave Aitel.

I am a bit disturbed by the tendency to mislabel potential vulnerabilities; it seems to me not at all fitting of a project that bills itself as open. IMO, "open" means (among other things) being able to admit when you make a hash of things, no matter how big and ugly the hash.