The 19 Deadly Sins of Software Security

There's a few dupes

Charles wrote:

Here's their software security sin list:

1. Buffer Overflows
2. Format String problems
3. SQL injection (subset of command injection)
   
4. Command injection
   
5. Failure to handle errors
6. Cross-site scripting (see #8)
   
7. Failing to protect network traffic
8. Use of "magic" URLs and hidden forms
   
9. Improper use of SSL
10. Use of weak password-based systems
11. Failing to store and protect data
12.  Information leakage (usually due to #10 and #11)
    
13. Improper file access (again, too similar to #12)
    
14.  Integer range errors (buffer overflow?)
    
15. Trusting network address information
16. Signal race conditions
17. Unauthenticated key exchange
18. Failing to use cryptographically strong random numbers
19. Poor usability

Oh come on, cry me a river. Everyone learns from their mistakes. I'm sure we don't need some Pro programmer to tell us how to secure our software.

Afterall, the software is as secure as the OS it is running on.
Steve.

Steve411 wrote:

Oh come on, cry me a river. Everyone learns from their mistakes. I'm sure we don't need some Pro programmer to tell us how to secure our software.

Afterall, the software is as secure as the OS it is running on.
Steve.

I must respectfully disagree. Although learning from your mistakes is definitely a good way to learn, in certain cases, especially those relating to security, where your users would get the short end of the stick, I think it's better to learn before making the mistakes in the first place.

Software is only as secure as the least secure peace of software that it depends on, including the OS. The least you can do is try to make sure you're not the weakest link yourself. Saying you don't need to secure your software because the OS isn't secure anyway, seems like a really weird attitude to me.

To take an old pro-environment ad-campaign from the government and twist it around a little: "Better security starts with you!"

Steve411 wrote:

Afterall, the software is as secure as the OS it is running on.

Wrong. Generally speaking, the OS can limit the amount of damage an application can run by protecting itself and other applications from the rogue app.

Well I was only making a little joke [hence all the winks] and it sparked an interesting convo. IMHO.

Keep going!
Steve.

Steve411 wrote:

Oh come on, cry me a river. Everyone learns from their mistakes. I'm sure we don't need some Pro programmer to tell us how to secure our software.

Wrong!!

Fools learn from their mistakes, if they're lucky.

The wise also learn from the fool's mistakes.

If he's willing to give me the benefit of his mistakes, for a measly $50, id be a fool not to snap it up.

just My $0.02

John Melville, MD wrote:

Steve411 wrote:Oh come on, cry me a river. Everyone learns from their mistakes. I'm sure we don't need some Pro programmer to tell us how to secure our software.

Wrong!!

Fools learn from their mistakes, if they're lucky.

The wise also learn from the fool's mistakes.

If he's willing to give me the benefit of his mistakes, for a measly $50, id be a fool not to snap it up.

just My $0.02

Oh, well thank you for calling me a fool.

Are you saying that even though i learned from my "mistakes" i'm a horrible programmer because i didn't pay attention to some hairless bald guy with a book on C# in his hand?

This is my $4,000.
I hope not.
Steve

edit: making a mistake takes you to a higher level of thought in the "bug" or problem in question, having the solution right away may solve it but it will not stick with you or provide an alternate answer. Making mistakes and finding multiple ways to fix them is better than having one and sticking with it. Multiple = true experience, Single = .. null..

Charles wrote:

Michael Howard, David LeBlanc and John Viega have come up with a new book outlining the most egregious software development sins that lead to security vulnerabilities that make us all miserable.

Here's their software security sin list:

Charles maybe you should have taken part in Microsoft's thought thieves you would know that you are stealing someone else's copyright and republishing it without permission. Very bad.

W3bbo wrote:

There's a few dupes

Charles wrote: 14. Integer range errors (buffer overflow?)

Wrong. They are talking about number wrap around. So you might push a large number into a signed type and end up with a negative number. There is no overflow.

Here is an example (although unrealistic) - You write a game server in C++. You use a signed int as a session ID, you give normal players a positive session ID and admin a negative session ID. So you can check a player by testing which side of zero their ID falls.

The problem with this is that either by chance or by intentionally reconnecting over and over a 'hacker' could get admin on the server by having the server give them a session ID larger than 4,294,967,295.

W3bbo wrote:

There's a few dupes

Charles wrote: 10. Use of weak password-based systems 11. Failing to store and protect data 12. Information leakage (usually due to #10 and #11) 13. Improper file access (again, too similar to #12)

I don't see what information leakage has to do with weak passwords? And I don't even understand failing to store and protect data so I can't comment on it.

But information leakage can just occur by making a bad request to any web-server. e.g.

Unable to find file /home/myserver/public_html/noneReal.php

That has nothing to do with a password. So I don't see what one has to do with another. Information leakage is very command and as I said is completely unrelated.

Even better would be a code review - have someone else catch it for you That way it never gets out into the wild, you've still learnt your lesson, but you haven't suffered the angst of many annoyed customers.

Sadly, we can't all have someone scrutinize our code over our shoulder (I know I certainly dont ). It'd be nice though. Security is one of those things that's learnt through experience (experience that I, sadly, haven't got yet) - you can't just throw a book at someone and expect them to write secure code.

At the same time, having a good idea of what to look out for definitely wouldn't do any harm.

I find that the best thing that helps me to understand a problem is real-world examples. There are lots of developers here. Let's list some. I've created the 19DeadlySins wiki. C'mon guys, let's fill it out.

Where in the list are the two most common problems I run into trying to secure a workstation by having users run with limited privliges while letting the application run?

1.)Applications require full control for the HKLM/Software/ key. (Not subkeys) Along with full control for the specific subkey for that application. (This is sorta OK)

2.) Appliation requires full control for it's own install directory AS WELL AS full control for root C: drive, even though it doesn't write to C:\.

Fun Fact:Did you know that Microsoft Image Editor doesn't even meet the validated for 2k requirements? (due to being a Kodak descendant I suppose) 

Charles wrote:

18. Failing to use cryptographically strong random numbers

Define "random numbers" on a PC.

manickernel wrote:

1.)Applications require full control for the HKLM/Software/ key. (Not subkeys) Along with full control for the specific subkey for that application. (This is sorta OK)

2.) Appliation requires full control for it's own install directory AS WELL AS full control for root C: drive, even though it doesn't write to C:\.

It is my understanding that LUA (Least-priviledged User Access) will become important for Longhorn.

I hope this at least means that the default user created after an install will not be a member of the Administrators group.

billh wrote:

Charles wrote: 18. Failing to use cryptographically strong random numbers

Define "random numbers" on a PC.

You can look up the sources of entropy for CryptGenRandom in Michael Howard and David LeBlanc's other book, "Writing Secure Code 2nd Edition". IIRC, it uses things like processor performance counters and other hardware-derived information to produce random numbers. The difference between this and a typical pseudo-random number generator is that, if you know the algorithm of a PRNG, and a short sequence of numbers it generated, you can predict the next number. You cannot predict the next sequence of random information from CryptGenRandom.

The downside of course is that CryptGenRandom is a lot slower. If you're doing simulations, an ordinary PRNG is sufficient. Use CryptGenRandom when you're generating things that need to be truly unpredictable, like encryption keys.

Mike Dimmick wrote:

billh wrote: Charles wrote: 18. Failing to use cryptographically strong random numbers Define "random numbers" on a PC.

You can look up the sources of entropy for CryptGenRandom in Michael Howard and David LeBlanc's other book, "Writing Secure Code 2nd Edition". IIRC, it uses things like processor performance counters and other hardware-derived information to produce random numbers. The difference between this and a typical pseudo-random number generator is that, if you know the algorithm of a PRNG, and a short sequence of numbers it generated, you can predict the next number. You cannot predict the next sequence of random information from CryptGenRandom.

The downside of course is that CryptGenRandom is a lot slower. If you're doing simulations, an ordinary PRNG is sufficient. Use CryptGenRandom when you're generating things that need to be truly unpredictable, like encryption keys.

Thanks for bringing that up...I've heard debates about using "hardware related sources" to generate random numbers...but even those are a little bit predictable I would think. If you really, really, really wanted to dig into it enough and bury yourself in the math. Not like I have that much time to sit and figure that out.

Steve,

While I understand your intent at humor, and I also understand your point regarding learning through experience, there's value in learning from someone else's mistakes, so much that I have to post this even though you were mostly kidding.

Even though we're destined to make mistakes ourselves, for those of us who are too green to have had to solve a particular problem, it's nice to at least attempt to avoid it.  We could all blunder through the world re-inventing the wheel as we go, but I'd much rather quickly absorb what's already been established and try to push the envelope a little further than my predecesors.  That's kinda sorta how the advancement of civilization works (unless each new generation is inherently smarter than our bearers, but that's arguably not the case, or at least, not by any significant amount.  The point is that they're more informed).

Experiencing lessons the hard way makes us stronger, but there's a lot to be said for trying to proactively avoid the negative experiences for the betterment of the industry.  I'd prefer not to introduce security holes in my applications because "although I could have avoided it, I needed to experience making the mistake in order to really learn how to solve it."  That only serves to hurt the consumers in the end, and is a great way to find the unemployment line.

To summarize my ramble, I believe "learning from mistakes" is used only to fill in the holes left after we've attempted to educate ourselves properly

I think they're missing one:

1. Failure to validate input

Your program must validate any input it receives from the outside world, even if it comes from a trusted source or from data your program wrote earlier. Assuming your program will receive only legal input is just asking for trouble. Not only does validating input close security holes, but it also helps to detect bugs and avoid version skew problems.