Computer experts from more than 30 organizations worldwide have released a consensus list of the 25 most dangerous programming errors that lead to security breaches. The list, which was spearheaded by the National Security Agency, is the first time a broad cross-section of the world's computer scientists have reached formal …
I am sure that the quality of IT teaching is now much improved from the days when I used to fall asleep to the dull drone of a technician who was patently out of his depth. Fortunately for me (and everyone else in my class at college) I had already taught myself BASIC and was sufficiently good at maths to understand enough about the flow of data and logical progression through a program to ace the topic and was happy to use the other half of my time teaching the class during our tutorials.
Moving on to a job as a COBOL programmer I quickly found myself with two interesting skills... firstly the forethought to control the flow of a program in such a way that most 'problems' simply could not exist (specifically the rigid control of inputted data and the writing of numerous distinct, robust and simple modules). Secondly, I had an unnerving knack of being able to identify the weaknesses in programs and was always in demand by the other trainee programmers to "find coding error that crashed their batch run" and to "test to destruction" their own creations.
Ah, the good 'ole days when a "finished product" was compiled and then packaged, ready for distribution... not the offensive torrent of 'beta' releases that never actually get fixed or spend their entire (and short life) being updated, fixed, patched... Rule 1 has got to be, "the project may be complex - but keep the modules simple".
In all my time as a programmer and subsequently in helping others to attain similar qualifications and indeed whilst later teaching myself dBase(III and III+) I have discovered that the single most common problem in IT is sheer bloody incompetence, the source of most errors is inherent habitual laziness, the most common program writing error is a "," instead of a "." and the number one error is not in programming, it is a lack of rigorous testing.
Re:How much is down to M$ ?
"What appears to be worse is that because M$ are who they are, and have published training material on how to do programming and projects badly, the rest of the world's numpties have sat up and, in their very finite wisdom, taken the garbage as their bible."
Actually, MS Press have produced at least two great programming books which I treat as 'bibles':
"Programming Windows 3.1" by Charles Petzold - A fantastic introduction to how GUI's work for people who come from a background of command-line entry and display. Clearly written and you get the sense that Chuck knows exactly which concepts will be most alien to you as you proceed, so he explains them in greater depth.
"Code Complete" by Steve McConnell - A 'common sense' set of guidelines on how to approach every aspect of programming. A lot of the advice is counter-intuitive when you first encounter it, which emphasises the usefulness of this book to all programmers, regardless of where you are in your career. You don't even have to be programming Windows for this to be a goldmine of useful ideas.
Of course, there are many other great programming guides out there and some are available for free - I can heartily recommend ESR's "Art of Unix Programming", which can be browsed online:
You have obviously never written code in real world working conditions.
You have a project that has to go live on Friday, you have 4 days left to work on it and 5 days worth of bugs and amends on your todo list before it can go to the client. The deadline is non-negotiable, if you miss it then the company may be out of pocket thousands of pounds (could easily be over 100k), you will get a bad review, ruin your chances for a bonus and get bumped one position higher on the 'bad programmer/replaceable employee' list.
The managers responsible for the project aren't programmers and don't fully understand your security concerns, their attitude is "just get it done for the deadline". If the project appears to be finished it must be ready to go, your security concerns appear 'petty' and are not critical for release to them.
A) Refuse to let it out of Alpha/Beta, pissing off both client and the company you work for.
B) Smooth over what issues you can and release the software as-is, keeping everyone happy. You can fix further issues as they crop up and shift the blame onto the company you work for.
Then what do you do a month later when the cycle repeats itself with your next project?
Tight deadlines and bad management are probably the number one cause of most of these issues. You often have to cut corners to get the code out on time, let alone even think about a security audit because the people managing the project do not understand the technical implications and requirements for the project and agree the budget/timescale without consulting anyone who does.
PS: If you even consider open sourcing a project the company is being paid to develop in-house, you will get laughed straight out of a job.
>Don't get a lot of those on AS/400 RPG-ILE
Well, I thought you meant real programming not some crappy job control language!
Anyway, example of a heap management problem in RPG-ILE
>'not validating input' is not a programming error, it's a systems requirements omission
There are some things that are taken as read, I bet the requirements don't have things like "Must not wipe the entire hard drive.", "Shouldn't constantly dial the boss' phone number" on simple accounts reports either.
Saw the title...
... and was looking forward to the top 25 stories of computers blowing things up, zapping people, crashing things...
Now, that's what I call dangerous.
@raving angry loony
As a former budget person, now retired, at one of the USofA's largest corporations, I can assure you budget is THE issue today. The truth is it has been for the last two decades if not longer. Right or wrong, low cost clerical personnel are generally the first to go closely followed by IT projects. In reality it may be a different scenario at different companies, buy IT is generally "low hanging fruit" for the accounting/budget trolls like I was.
Right or wrong, that's the way it is. Bad management is certainly a problem. But bad management tactics to help themselves look better is to "get costs out of the business" which has the effect (hopefully) of lowering expenses and raising net income, growing the company and increasing stockholder worth.
very true, my friend.
However, part, if not the major part, of the problem lies with t'management and their project planning. They usually consider a product ready for shipping when it fulfills it's functional criteria. I.e. it produces the correct output from the set of input data. The fact that it cracks right open if you miss out a decimal point, or type "*" when the database is expecting a number, simply doesn't feature: they get picked up in the beta testing (which, BTW is now commonly referred to as version 1.0)
Why these state of affairs is allowed to happen is partly due to timescale pressures - where the development cycle simply *must* produce 2 releases a year. Part of it is due to the way development is done: with stages like code, test, release (without the obvious interlude and time allocation between #2 and #3 of "fix the bugs"), and part is due to the lack of liability that the producers award themselves from the EULAs.
In practice, pretty much all of the 25 listed errors boil down to a single element: failure to design and code defensively, for a hostile environment. But of course, that wouldn't make any headlines as we all know that already.
Good to see this list of twenty five errors is twenty five years old. What do they teach in computer school these days?
A little bugette from El Reg:
[an error occurred while processing this directive] "
Damn, missed it.
I haven't read the list through yet, but is 'embedding a flight simulator in your spreadsheet' on there?
Management to blame
For tossing experienced personnel out and replacing them with MCSE script kiddies who think they know it all, but continue to keep making the same mistakes over and over again... and just when they get competent, they get tossed out on the next project and replaced by a new batch of script kiddies fresh out of college who will make the same mistakes...
Real engineers learned the hard way and ensured that their profession had a suitable qualifying regime (apprenticeships and graduate training schemes) to ensure long term institutional "memory" and that those who called themselves Engineers were worthy of the title.
Software Engineering still (after all these years) isn't mature enough to call itself a profession...
90% of all web-based applications are crap, but the world still seems to turn on its axis.
Mostly customers want cheap or quick above all else - so is it any wonder that developers don't concentrate on security? As far as I can tell western developer morale is at an all-time low - there is only so often you can bang your head against the brick wall of idiotic clients before you just give in and churn crap to earn your wage.
Paris because she has found a much more satisfying career.
A note for the anti C/C++ brigade
C was designed as a high level assembler to write operating systems in. To whit it has to allow you full access to the raw metal as far as possible. Perhaps C/C++ isn't the best language for application development as opposed to low level development but saying it should never be used is like saying assembler should never be used. Fine, you take your high level wrap-you-in-cotton-wool languages like python, java, C# and try and write a low level device driver in them that has to deal with hardware interrupts, DMA, kernel ring buffers and the like without using any libraries written in C or assembler (or in turn call on ones that are). Once you've done that get back to us and your opinion might have some merit. Until then you stick to your safe cosy application development IDEs and let the grown ups do the real programming.
@Tom Cooke and other
Generally the OS only protects a program against writing to memory outside its allocated process space, or memory marked as program (i.e. read only) rather than data. Library calls like malloc() handle the subdividing of memory ultimately allocated by the OS, and it's more usual for programs to overwrite the wrong bit of this subdivided memory.
I'm not keen on the title of this article though; better would be 'The top 25 programming security holes'. It's far more dangerous (from the point of view of getting anything done) to have a program that doesn't work, and the list is somewhat web specific.
The list is probably most useful to managers rather than programmers; a half decent programmer already knows the list, but it might inform the manager why it's important to construct secure software.
"Guarantee that the code is free from those errors" ?
Hmm, Mr Turing had something relevant to say on that ...
RPG!!! Use Cobol Instead
What you describe is not coding errors but a total lack of project management. Have you tried PRINCE2 - nearly as much fun as programming :-))
"Well, I thought you meant real programming not some crappy job control language!"
JCL is the crappy Job Control Language not RPG, which originally meant Report Program Generator, neither is PRINCE2 a RPG (role playing game), its a project management methodology. Anyway, your example of a "heap management problem" is really an example of shit programming.
I'll probably get a few RPGs sent my way for that last remark, RPG as in Rocket Propelled Grenade
Paris, 'cos she knows what to do with RPG,( Rigid P***s, Giant)
Nothing New Here
A good list, but nothing that professional programmers didn't already know. There are all sorts of tools at Microsoft and other places to automatically search for many of these problems. But it's not that easy to identify these kinds of bugs by inspecting source code. This is one of the big flaws in open source ideology. Just looking at source code is a very poor form of QA, compared to dynamic testing, bug tracking databases, unit testing, build tests, etc. This is an area where the UNIX community has been playing catch-up for a long time, because they come out of an academic "hacker" culture of individual effort versus large-team systems management.
"Improper Input Validation" means check your bloody input! Entering data should not break a program, it should fold gracefully and inform the user about the error in a much detail as is necessary.
What's not to get?
Easy way to avoid programming errors
The best way to ensure that the software you use is free from elementary programming errors is to read the Source Code. The second best way is to have someone else, independent of the original programmers and whom you trust, read the Source Code for you. (Which is exactly what happens when you use a Linux distro.)
If they won't show you the Source Code, decline politely and walk away. Be sure to let them see you count your money back into your pocket.
(Fair enough, crappy report generator then!)
>Anyway, your example of a "heap management problem" is really an example of shit programming.
It's an example of how you can mess up the heap. An example of shit programming is what it's supposed to be.
The point was that even in RPG-ILE you can get them if you're a shit programmer who writes in one of the top 25 errors listed. To think that you aren't going to get them cos the system's got IBM on the front is sufficient to show that the guy needs a nice simple example of shit programming in RPG.
Hmmm.. Dunno about the truth of this, but Wikipedia informs me that RPG officially no longer stands for anything at all.
"A) Refuse to let it out of Alpha/Beta, pissing off both client and the company you work for."
I ensure that I don't *need* the job I'm doing so they can't bully me into doing a piss-poor job.
If it *must* be shipped, either get some other donkey to do it or remove whatever bits are making it unstable (if that is likely to fix the problem or at least hide it: if it crashes when you press "Advanced" then remove the "Advanced" button).
re: @ the Anti-MS brigade
Ubunti updates 3000 applications.
Windows update does how many?
Re: A note for the anti C/C++ brigade
You're forgetting something: to the latest generation of code monkeys, "applications" and "software programs" mean exactly point-and-clicky interactive client programs or web applications.
Operating systems, device drivers, and even sophisticated video games with fancy graphic effects are not part of this pool--they are just stuff that you download or buy on a disc. Of course, from that perspective, C and C++ are useless and dangerous, and distract you away from the automagic code generators, garbage collectors, and shiny components.
As for the stuff they downloaded or bought on a disc, it must have been written in PHP, C#, VB.NET or Java. Unless it's buggy, then it definitely was written C, and the programmer should have known better.
"I ensure that I don't *need* the job I'm doing so they can't bully me into doing a piss-poor job."
Congratulations! Any suggestions for those of us mere mortals forced to work for a living?
This is a "list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime." It only applies to Web apps (or others with a client-server model), and flaws that can be remotely exploited. A list of the most dangerous errors in desktop apps would look quite different.
The list seems a bit repetitive, and could be summarized as 'Code Defensively', or 'Program with Paranoia', but it's good to point out how many places that defensive coding is needed in.
errors ? really?
so 'professional' programmers cant be bothered to put in
catch Exception(DefMessage("Oi! put a f***ing number in you tosser"));
Or something like that
But reading about all the buffer overruns? does no one bother checking the size of the file against the size the file says it is?
But there again, I'm from robot programing, where we have to be 100% right if we're not then operators could be hurt or killed or worse still expensive machine tools get broken
i blame the likes of RAM and FLASH memory and Von Nuemann architectures
It's all the fault of running code from RAM and FLASH and Von Neumann architectures
If you have a true harvard machine then there is no such thing as code injection from data space. There is code memory and data memory. you can not execute from data memory. Simple as that. And there is also I/O space. And only code can go to I/O space.
Then there is the memories : when processors only had ROM (mask rom or antifuse rom or OTP ) to run from, there were far fewer errors. First of all the code could not be overwritten by something malicious. The rom was masked during fabrication and that was it. Second point: quality control was much bette.r The attitude now is , oh well we'll fix it in the next release . If you have to shell out for a new maskset you will think at least 500000000 times about each and every instruction you put down.
What's my point ? Why does nobody make an OS that can boot from write protected flash ? you install on a clean machine. Load the OS core and drivers that you need. ONce this install is done : powerdown , flip WP switch and restart. If your machine catches a bug : hit the reset button. bye bye virus, spyware or whatever. I don't care. This could easily be done. Make a split registry and program files directory. The stuff that is critical sits in WP block. The visible file system is a logical OR between the flash and harddisk with the flash having priority. So if a nasty throws a couple of DLL's in virtual 'c:\windows\system' . Let it ! who cares. Those files end up on the harddisk. During boot the OS does not load anything from HDD. THe files on the flash have priority. If a duplicate file is found betwene flash and HDD you get a message after boot that file so and so is in location so and so and a duplicate exisits in flash. Cleanup ? yes-no?
Given that an OS + APPS is small. Couple of gigabyte and flash cost pennies : what are we waiting for ? I would immediatel ybuy such a machine. Primary volume : 8 or 16 or 32Gbyte flashdrive with mechanical WP ( a switch ), data volume : standard harddisk.
The only pain : when you need to install or do an upgrade you need to power down flick a switch and then do that again. Advantage : you always boot from a known good system. If an update is in order : download file. power down. flick switch , launch system ( now in known good state ) deploy update , power down , flick switch to safe , power up. Done. But then again. how many times a year do you install new software ? And when installing software you can give option : to safe zone or to harddisk. ( remember the visible filesystem is a logical OR between flash and HDD ( not at bit level of course but at file/directory level), with the files in flash having priority. So you can install your game to harddisk. but some app that is more critical to flash, in whihc case the installation procedure requires you to do the switch toggling. I would make the switch toggle something like : you need to press this button while powering up. That way you force people from doing the safe procedure.
It's so simple , i wonder why nobody has thought about this before. Especially these days when flash is 1$ a gigabyte...
"If you can write a program without using dynamic memory allocation - then it is probably solving a simple problem - that is why it will run for years."
flight control software
How about the firmware that makes a diskdrive spin ? That is megabytes of embedded firmware. ZERO dynamic memory allocation ! For some portions of that firmware they go so far as to hand allocate the memory locations. This byte here, that word there. And the real critical code is handcrafted assembly. Interrupt handling has to be absolute and deterministic
@ Torben Mogensen
I took a C/C++ programming course 10 years ago and we learned all that back then. Maybe my instructor was ahead of his time (or just knew what he was doing) or maybe too many programmers/project managers don't know or worse don't care?
I don't know the answer, but I don't think you can blame the language. If a project is so pushed for time that there is not enough time to do it correctly using a language that requires a little care, then perhaps the project has been improperly scheduled?