Slashdot Mirror
Secure Programming
viega writes "Matt Messier and I have just launched a secure programming web site. While this site does support our new book The Secure Programming Cookbook for C and C++ , it also serves as a thorough resource for developers. It has numerous links to articles and other topical resources, new recipes that demonstrate secure programming techniques a large glossary and the obligatory web log. We accept outside submissions, and will reward the best recipe submission each month-- O'Reilly will publish it on the O'Reilly Network web site and will give the author a free book. There's already a decent amount of new content, including recipes on avoiding malloc()/new-related integer overflows, watching out for security problems in API differences and issues when truncating data. There's also an RSS feed for the web log."
Or for a quick and free guide, you can download the secure programming faq from one of the oldest websites on the internet-
Securing Programming FAQ
--
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
Viega's site disses Schneier's book, which everyone else seems to regard as gospel. What's up with that? I like a juicy feud as much as the next guy.
IEEE Standards Associate, IEEE Information Assurance, IEEE Computer Society and IEEE Baseline Operating System Specification Working Group (BOSSWG) has initiated a call for definitions of a new operating systems intended to securely control nearly all aspect of the operating system (including root).
Kinda sounds like Common Criteria, doesn't it; hopefully better.
This isn't true whatsoever. Only the most glaring issues are fixed. Currently, we're working on a Java Secure Programming Cookbook, and we'll get around to C# after that.
We do a lot of code auditing, and find about 4-5 serious security problems per thousand lines of code of C and C++ code. In languages like Java, we still usually find 1 or 2 such problems.
If only it were that easy! Most of the stuff in the book applies to any language under the sun, but the examples are in C. If the book were just about protecting against buffer overflows, then it would have been 50 pages instead of 800. There's a ton of hands-on material on how to use cryptography correctly in an application. It's still amazing to me that about 90% of the time I see SSL/TLS integrated into an application, it's used in ways that are grossly insecure (e.g., a man-in-the-middle attack is easy). Also, we cover things like how to prevent common input validation problems that happen in any language (e.g., SQL injection).
I agree that they didn't sell that many Lisp machines (maybe a few tens of thousands?). But you are mistaken in your comment about architecture: the Lisp machines only ever had half a dozen instructions that made them different from mainstream CPUs. In fact one of the many reasons for the demise of Lisp machines was that Lisp compilers of mainstream architectures got good enough that they could compete with the Lisp-optimized machines. In principle there's no reason you couldn't run a Lisp kernel on a modern machine -- it's just that there would be no point when 99.9999% of available software is written in non-lisp languages.
Avoiding buffer overruns isn't really about being compiled or interpreted. In any language that doesn't have C-style pointers it's relatively easy to write a compiler that provides automatic array checking with very little performance deterioration. (Strength reduction optimization makes it possible to move most array bounds checks out of loops.) The issue really is whether the language definition makes such a checking compiler easy, or a heroic undertaking. In the case of C and C++, a compiler that produces array-checking code is a heroic undertaking, and even then you have problems with libraries. Of course right now most libraries are written in C or C++ so you would have problems with buffer overruns in libraries regardless of the application language.
Been in the security game for 10 years...
From all these posts, it seems that all programmers don't have a clue about programming in a secure manner. I disagree, its just that times have changed.
Surely, a few years ago this was the case. But certainly not as bad as now. Most PHB worth their weight usually know the security buzz words associated with an implementation are. If they don't give support to the developers to create a secure solution, they arent just lacking in security skills - they are lacking in overall management skills and an understanding of IT. Security has to be part of the overall process when in development, PHB's must invest *training* for programmers and develop standards to follow.
Previous posters saying that it should be manditory for all post grads to have indepth security skills is down right short sighted. Security is a bottomless pit with many variables, a general subject can be taught. However, security can't stem strictly by programming practices. It is a collection of standards from all types, from the network, operating system to the application level. Not to mention the usual deal of people, process and technology.
I've lost count of how many pen tests I've completed where the application design was rock solid, however they had a bad password on their admin portal.
Nuff said....
Bah. That they do not have security holes is implausible, if not actually impossible, to prove. It's hard to even define what a security hole is; a changing threat model has "caused" many security holes. (Is an open relay a security hole? I say yes. Twenty years ago, everyone said no.) I doubt your statement. I can't point at a hole right now, but I have confidence that at least one security hole will eventually be discovered in those programs.
They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.
No, they make it easier to avoid buffer overflows. They don't prevent them: I quote from your hyperlink:
If they use sa.s and sa.len directly, they can screw up and increase len inappropriately. The API seems good in that it makes it much harder to do things wrong, but it is hubris to say it makes you invulnerable. Besides, buffer overflows are possible for things other than strings, so this solves only (the most common) part of the problem. And there's still the legacy code that people can use without porting to stralloc.
It does seem like a good library if you're stuck using C. Another alternative is APR, which makes managing all sorts of memory allocations much easier. Pools are handy things when dealing with a language that primitive.
But there are languages in which it actually is impossible to have a buffer overflow. Please don't confuse the issue by saying that this (which makes it somewhat easier to avoid this error) makes the error impossible.
Overlook? Hardly.
Most open source models encourage reporting of exploits so they can be fixed. (more than 500 in Debian over the past 4 years). How many of those are STILL exploitable? How long between when an error is found and a fix is available?
Your argument is common and entirely false.
When an error is found in Debian, it is soon fixed.
When an error is found in M$, it gets swept under the rug and ignored. When finally made public (usually via 3rd party press release or some spectacular virus/worm) M$ often denies, then grudgingly releases a patch. This patch may or may not fix the problem and may or may not break something else.
- a program enforcing a division of data,
- ensuring a program doesn't let any bits slip through the cracks, and
- creating a system where people can do only the things they are allowed to do.
"Security" to me is (3). Security is a social construct. You can't have security until there is someone who's not allowed access to something.I see a lot of talk about cryptography, preventing buffer overflows, and so forth. But the combining of these technologies in the design of a real-world security application is seldom discussed. It's a hard messy problem.
I suspect if we had a better understanding of the social aspects of security, more secure technology would follow.
> I won't given the color scheme.
Opera (www.opera.com) has two modes, "author mode" and "user mode". In author mode the page is displayed as the author wanted it to be. In user mode, your own settings apply. You can override most attributes, eg disable background grafics, font sizes, etc. The switch between author mode and user mode is done with a simple mouse click (you don't have to wade through menus).
It's a very useful feature for text-biased pages.
I see where you are coming from, however I felt more forgiving about the second point - maybe because the recommendation was more vague. The original poster (grammar aside) suggested that SQL generation should be separated from UI interaction - and this is, IMHO, usually a very good idea. No-one suggested "all SQL should be done at the back end;" Only you seem to think that six times the volume of code would necessarily be required for such a separation; only you suggest that a boss would disagree - and I doubt, at this stage, anyone needs their "sorry ass" fired.
When considering complex systems, architecture is important. Sure, it is often possible to cut corners on trivial systems, but a good programmer will always remember that the system should be easily explicable in order for it to remain maintainable. While 3-tier architectures could be just as poorly implemented as single tier or client-server solutions, there is a wealth of empirical evidence to suggest that 3-tier designs have been a significant benefit in many complex systems. In my opinion, as a rule of thumb, it is a good idea to separate UI implementation from SQL interaction - particularly for applications to be used in adversarial environments. Even ignoring your distaste for the 3-tier paradigm (which I admit is by no means a cure-all design) there remain many other techniques to logically separate SQL generation from UI interactions. I have never in practice seen the need to expose all of the functionality of the often bloated and complex SQL implementations to code primarily concerned with UI interaction... I frequently see myriad benefits in encapsulation.
> and those that think they're safe merely by using a particular programming language are in for a nasty surprise.
That's true, of course, but nonetheless languages make a huge difference.
In applications, buffer overflows, along with (recently) integer overflows, double-free bugs, and printf formatting bugs, are the most common source of exploitable holes by far. (Case in point: the MySQL buffer overflow currently on slashdot's main page, the several recent RPC vulnerabilities in XP, the recent OpenBSD hole, etc.)
All of these errors would be impossible to make in a safe language.
Yes, we still need security-conscious developers, and there are still many things to worry about. But if we can get rid of the vast majority of problems, automatically (and as a side benefit get to program in a modern high-level language, which makes many other things easier), why not switch? Just because it's not a complete solution?