You know, Skapare, even Kernighan and Ritchie admit that C has serious security problems. I've talked to them both about it. As for C++, it is a complete dog of a language that would be best stricken from the planet.
You may snicker, but I am a scheme programmer at heart.
This is a nice posting. Do note, however, that most game hacks against MMORPGs do not involve network-level packet twiddle. Instead, most attacks involve reversing the actual client program and manipulating that. It's a new paradigm (and one not very familiar to most computer security people).
Just for the record, the fact that the Warden uses (weak) crypto to try to protect its data transmission over the network does nothing at all to stop the Governor program. The silly thing about the Warden is that it runs on the client it is supposedly monitoring in user mode. The Governor can be run with higher privilege, interpositioning using Detours in the kernel. That means it can perform a "lobotomy" on the Warden.
Most of the exploits that are interesting in our book have to do with the fact that too much state data is exposed to shenanigans on the client. Expect much more of this in the future.
gem
http://www.cigital.com/~gem
Nope. We have code for some of the stealthy rootkit-like bots in the book, but there are some techniques in common use now that we did not include code for. The coolest techniques involve making use of a multi-core system and hardware interrupts.
What immcintosh said. What we did in the book is not illegal as far as we know. I wrote an article about the state of the law and computer security through the lens of MMORPGs for darkreading. Here's a pointer:
http://www.darkreading.com/document.asp?doc_id=136128&WT.svl=column1_1
And just for the record, our books do sell pretty well (EOG is off to a fine start), but we do it to help improve the state of software security from the dark ages to the Bronze age.
gem
http://www.cigital.com/~gem
teaching kids to code using robotics is a great idea with deep roots. I recall the turtle language Logo from WAY BACK WHEN. I also recall burning a hole in the carpet at my rental pad in Bean Blossom working on "carbot" with professor blank.However, I would like to see a robot that automatically conjures up tequilla shots, including sliced lemons when asked.
Doug, can you get on that please?
gem
company http://www.cigital.com/
podcast http://www.cigital.com/silverbullet
book http://www.swsec.com/
Um, in the mid 80's I was in high school in East Tennessee. Had a little company named "M^2 Computing, Inc." with my friend and current compiler god Greg Morrisett (Cornell CS).
More detail here .
Oh yeah, and I was an apple ][+ kid.
gem
I vehemently disagree with Gary McGraw too...and I *am* Gary McGraw.
I actually made a number of reasonably salient points during the long interview, but the reporter seems to have latched on to a twisted version of what I meant. Alas, this happens all the time. It's one of the classic risks of talking to the press!
Sorry to have sounded like a bufoon! We all know that security problems are really the fault of the telecom providers...right?!
Of course there is no such thing as perfect security or perfect software! I don't think I said that. It's all about risk management.
Here's what Bruce Schneier says about "Building Secure Software" in the preface that he graciously agreed to write for it:
"We wouldn't have to spend so much time, money, and effort on network security if we didn't have such bad software security... Sometimes, network security can defend against these vulnerabilities. Sometimes the firewall can be set to block particular types of packets or messages, or to only allow connections from trusted sources. (Hopefully, the attacker is not already inside the firewall, or employed by one of those trusted sources.) Sometimes the intrusion detection system can be set to alarm if the particular vulnerability is exploited. Sometimes a Managed Security Monitoring service can catch the exploit in progress, and halt the intrusion in real time. But in all of these cases, the original fault lay with the software. It was bad software that resulted in the vulnerability in the first place."
A point well worth pondering. Now go read the book and *then* you will be allowed to rant.
Happily there are many more specifics and tons of code examples in the book that I was (in fact) plugging on cnet.
The second half of Building Secure Software has detailed chapters on: buffer overflows, access control, race conditions, random numbers, applying crypto, input validation, password systems, tamperproofing, and getting through firewalls. There's (too much) C, some Java, and a bit of python to make things real.
Security weenies tend not to understand that software lies at the heart of the security problem, choosing instead to throw firewalls and crypto at the problem and call it solved. You guys know better.
Even companies that have traditionally used egregious licenses to escape the blame for their bad shovelware are coming to realize that users are demanding better stuff.
For security, things are further complicated because in general, functionality and security trade off badly against one another. Plus security is not a feature...it's a property.
We wrote "Building Secure Software" to help developers negotiate that tradeoff (and other related thorny tradeoffs). In the real world of "should have shipped it last quarter" developers concerned about security need all the help they can get!
Slashdot Mirror
You may snicker, but I am a scheme programmer at heart.
gem
Probably the best book on security for builders to read is "Security Engineering" by Ross Anderson,
I happen to think that "Software Security" is good too. Then again, I wrote it.
http://www.amazon.com/Software-Security-Building-Gary-McGraw/dp/0321356705/ref=sr_1_1?ie=UTF8&qid=1314456538&sr=8-1
gem
Software Security
http://www.amazon.com/Software-Security-Building-Gary-McGraw/dp/0321356705/ref=sr_1_1?ie=UTF8&qid=1314456538&sr=8-1
gem
gem
http://www.cigital.com/~gem
Just for the record, the fact that the Warden uses (weak) crypto to try to protect its data transmission over the network does nothing at all to stop the Governor program. The silly thing about the Warden is that it runs on the client it is supposedly monitoring in user mode. The Governor can be run with higher privilege, interpositioning using Detours in the kernel. That means it can perform a "lobotomy" on the Warden. Most of the exploits that are interesting in our book have to do with the fact that too much state data is exposed to shenanigans on the client. Expect much more of this in the future. gem http://www.cigital.com/~gem
The techniques in the book are most interesting because they are a harbinger of hacks to come in fat-client (real web 2.0/SOA) software.
Perhaps you should look at the book?
gem http://www.cigital.com/~gem
Nope. We have code for some of the stealthy rootkit-like bots in the book, but there are some techniques in common use now that we did not include code for. The coolest techniques involve making use of a multi-core system and hardware interrupts.
It's all real.
gem http://www.cigital.com/~gem
gem http://www.cigital.com/~gem
Here's a basic article that might help set this in context: http://www.informit.com/guides/content.aspx?g=security&seqNum=284&rl=1
gem
http://www.cigital.com/~gem
What immcintosh said. What we did in the book is not illegal as far as we know. I wrote an article about the state of the law and computer security through the lens of MMORPGs for darkreading. Here's a pointer: http://www.darkreading.com/document.asp?doc_id=136128&WT.svl=column1_1 And just for the record, our books do sell pretty well (EOG is off to a fine start), but we do it to help improve the state of software security from the dark ages to the Bronze age. gem http://www.cigital.com/~gem
teaching kids to code using robotics is a great idea with deep roots. I recall the turtle language Logo from WAY BACK WHEN. I also recall burning a hole in the carpet at my rental pad in Bean Blossom working on "carbot" with professor blank.However, I would like to see a robot that automatically conjures up tequilla shots, including sliced lemons when asked. Doug, can you get on that please? gem company http://www.cigital.com/ podcast http://www.cigital.com/silverbullet book http://www.swsec.com/
Um, in the mid 80's I was in high school in East Tennessee. Had a little company named "M^2 Computing, Inc." with my friend and current compiler god Greg Morrisett (Cornell CS). More detail here . Oh yeah, and I was an apple ][+ kid. gem
gem
"snakeoil"
I actually made a number of reasonably salient points during the long interview, but the reporter seems to have latched on to a twisted version of what I meant. Alas, this happens all the time. It's one of the classic risks of talking to the press!
Sorry to have sounded like a bufoon! We all know that security problems are really the fault of the telecom providers...right?!
gem
Gary McGraw
Of course there is no such thing as perfect security or perfect software! I don't think I said that. It's all about risk management.
Here's what Bruce Schneier says about "Building Secure Software" in the preface that he graciously agreed to write for it:
"We wouldn't have to spend so much time, money, and effort on network security if we didn't have such bad software security...
Sometimes, network security can defend against these vulnerabilities. Sometimes the firewall can be set to block particular types of packets or messages, or to only allow connections from trusted sources. (Hopefully, the attacker is not already inside the firewall, or employed by one of those trusted sources.) Sometimes the intrusion detection system can be set to alarm if the particular vulnerability is exploited. Sometimes a Managed Security Monitoring service can catch the exploit in progress, and halt the intrusion in real time. But in all of these cases, the original fault lay with the software. It was bad software that resulted in the vulnerability in the first place."
A point well worth pondering. Now go read the book and *then* you will be allowed to rant.
gem
Gary McGraw
"a random joe blow"
Some people believe that computer security problems lie in the network cable connecting a LAN to the Net. That would be wrong.
gem
The second half of Building Secure Software has detailed chapters on: buffer overflows, access control, race conditions, random numbers, applying crypto, input validation, password systems, tamperproofing, and getting through firewalls. There's (too much) C, some Java, and a bit of python to make things real.
Security weenies tend not to understand that software lies at the heart of the security problem, choosing instead to throw firewalls and crypto at the problem and call it solved. You guys know better.
Software, the proactive security solution.
gem
Gary McGraw
http://www.cigital.com/~gem
For security, things are further complicated because in general, functionality and security trade off badly against one another. Plus security is not a feature...it's a property.
We wrote "Building Secure Software" to help developers negotiate that tradeoff (and other related thorny tradeoffs). In the real world of "should have shipped it last quarter" developers concerned about security need all the help they can get!
gem
Gary McGraw
http://www.cigital.com/~gem