On MeeGo, a Budding Geek and the 25 Most Dangerous Programming Errors
Feb 22, 2010 5:00 AM PT
Well it's been a quiet few days on the Linux blogs, as geeks the world over hunkered down and waited for the Month of Love to come to a close at last.
Out with the pink and red, we say!
The blogosphere was not entirely without its diversions, of course -- it never is.
There was the news, for instance, of MeeGo, the joint project between Intel and Nokia that represents the merging of Maemo and Moblin.
One interesting result, as noted by AVee, is that Intel will soon be sponsoring a mobile Linux distro that runs on ARM.
Curiouser and curiouser!
'I Was Approximately 3 Years Old'
Then, too, there was the story of the 9-year-old who is now working on his fifth Microsoft certification.
"My first memory is from when I was approximately 3 years old when I was making simple actions like personalizing Windows," young Marko Calasan told Network World in a recent email interview. From there, Calasan moved on to "installing Windows, making remote desktop connections with workstations and servers on remote locations, and so on."
The gang over at Digg couldn't wait to jump on that one.
"And there I was, thinking our 9-year-old's certificate of participation in youth soccer was worthy of putting on the fridge," wrote alphadoggs.
Then again: "Shows you what a MS certification is worth," opined gabbagabbahey.
Someone introduce that boy to Linux, and quick!
'The Means to Steal the Keys to the Kingdom'
Perhaps most useful of all, though, was the release of the "2010 CWE/SANS Top 25 Most Dangerous Programming Errors" report, which lists each year the programming gaffes most open to exploit for cybercrime and espionage.
Sneak preview: "Failure to Preserve Web Page Structure" and "Improper Sanitization of Special Elements used in an SQL Command" were the top two, representing the "one-two punch of security weaknesses in 2010," according to the authors.
"Even when a software package doesn't primarily run on the web, there's a good chance that it has a web-based management interface or HTML-based output formats that allow cross-site scripting," they explained. "For data-rich software applications, SQL injection is the means to steal the keys to the kingdom."
Also included in the report is a section on "Monster Mitigations," listing practices that can help.
Providing a nice comparison, meanwhile, Red Hat's Mark Cox also recently published an analysis of the key programming errors Red Hat experienced in 2009. No big surprise, many of them appeared on both lists.
In fact, 10 of the 11 most severe flaw types experienced by Red Hat are mentioned in the 2010 CWE/SANS document, though four of them are "on the cusp" and didn't make it into the top 25, Cox notes in his report.
Inspired by the impressive overlap, Linux Girl couldn't resist asking a few passersby in the blogosphere's busy downtown: Does the list of programming errors ring true to you?
'That's Not Actually Helpful'
"The list is too generalized and much too preachy," Montreal consultant and Slashdot blogger Gerhard Mack told LinuxInsider.
For example: "Their fix for buffer overflows? 'Use a different language,'" Mack noted. "That's not actually helpful. A better approach would be to break the programming flaws down by language so programmers can see the flaws inherent in their language of choice."
On the other hand: "That's a pretty good list" was blogger Robert Pogson's assessment.
'I Have Made Most of Those Errors'
"At one time or another, I have made most of those errors," Pogson told LinuxInsider. "Of course, TFA is about security, not correct function, but at some level, correct function and security are synonymous."
A few additional errors also deserve a place on the list, Pogson said:
"Using non-initialized variable or pointer: You would be surprised how many applications seem to run properly until an infrequent event occurs and things break," he noted. "Anything that allows wrong results can also cause vulnerability to malware/malicious hackers."
"Improper loop termination: Off-by-one errors are very common," he pointed out. "Being off by one word can mean a hacker has a word with which to play and inject his stuff; being off by a block or a layer opens everything up. I once brought down an IBM System 360 merely by loading a program of a certain length. My program won the lottery by being the right length to send the loader into an endless loop."
OEMs' Bad Habits
From Slashdot blogger hairyfeet came the perspective of one who repairs PCs when they run into trouble.
For example, "so far I have yet to find a single OEM build that has auto-updates turned on AT ALL," he explained. "Not a single one has even had auto-updates set to notify, much less patch. All of them, every single one, is set with auto-updates to off at the factory.
"Between that and the 30-day trials of crapware like Norton, it is no wonder so many machines are infected!" he pointed out. "Just this Monday, I had a machine cross my desk that had over 1,000 infected objects, and can you guess when the last update had been done on it? At the factory in 2004!"
'Smells Like Last Week's Fish'
Indeed, "the article fails to make any mention of the top real-life causes of security failures, which are all management failures," agreed Barbara Hudson, a blogger on Slashdot who goes by "Tom" on the site.
For example: "Feature bloat; not devoting enough resources to a project; and not dragging people who rely on articles like this one behind the barn and putting them out of their misery -- or at least giving them a position where they can do less harm," Hudson asserted.
"As a programmer, tester or lead or project manager, either you're already aware of these problems and are actively working to avoid them, or you have bigger problems, in which case you can't use this list anyways, because you don't have the knowledge to use it effectively," she told LinuxInsider.
Besides, in the report itself, "I took a peek behind the curtain, followed the links, and in the section marked 'software customers' there's a link to something called 'SANS' Application Security Procurement Language, surrounded by enough buzzwords to fill my bull**** bingo card and then some," Hudson added. "The preamble states 'This is a living document,' but a quick read shows it's DOA and already smells like last week's fish.
"You'd be better off asking David Letterman for a 'Top 10 list' of security vulnerabilities," she concluded. "At least then you'd know SOME of it is good for a laugh and there's no danger of it being taken seriously."
'We'll Patch It Later'
On Hudson's own list?
10. "Pissing off coders for no reason."
8. "Feature bloat."
7. "We gotta ship NOW!"
6. "The entire marketing department."
5. "Letting the president's golfing buddies supply 'useful input.'"
4. "We'll patch it later."
3. "Crunch time! and the 60-hour week."
2. "Ever-changing requirements."
1. "Hey, I read this article at sans.org and from now on we're doing it this way ..."
And, finally, for the bonus:
0. "No, don't refactor it, there's no time -- just put in a comment that SOME_VARIABLE now means the exact opposite of what it seems to mean, and that save_state_to_stable_storage() now exits without saving," Hudson quipped. "And don't worry about that other problem -- nobody will enter a name with exactly 2,083 characters."