Exploiting Software

prostoalex writes "Why are networked computing environments so insecure? You've heard the story before - early computers were not designed to work in the network environment, and even most software written later was designed to work on benevolent networks. As Bruce Schneier says in the preface to Building Secure Software: How to Break Code, 'We wouldn't have to spend so much time, money and effort on network security if we didn't have such bad software security.'" Read on for prostoalex's review of Exploiting Software, which aims to balance that situation somewhat. Exploiting Software: How to Break Code author Greg Hoglund, Gary McGraw pages 512 publisher Addison Wesley Professional rating 8 reviewer Alex Moskalyuk ISBN 0201786958 summary Techniques and software used to attack applications.

What kind of secure are you after? There are many published titles on the topic of software security are numerous, but most of them follow certain patterns. Building Secure Software by Viega and McGraw was mainly concerned with proper techniques and general software engineering mindset without going into specifics. Then there was Writing Secure Code , by Howard and LeBlanc, which provided concrete examples and showed the "right way" to do secure coding. I heard the title instantly became a required reading at world's largest software corporation. It's currently in its second edition.

Secure Programming Cookbook for C/C++ by Viega and Messier, was the hands-on title for those developing C/C++ application with security in mind, as the cookbook recipes generally gave examples of good code, with each chapter providing some general background information on the topic discussed (I reviewed it on Slashdot in September last year).

Just in case you were wondering, the list above wasn't just retrieved by a quick search at Amazon. My Master's degree, completed last summer, dealt with the topic of software security, and those are the titles I've read preparing to write the theoretical part.

From the other side With the variety of books on how to write secure software, and what techniques to use to make existing software more secure, there was a niche for a book targeted specifically to those who wanted to break software. Black hat or white hat, the network security experts always had titles like Hacking Exposed to give them an idea of what was available in terms of techniques and methodologies used out there. For software security most of the articles and books generally would tell you something in the terms "do not use strcpy(), as it introduces buffer overruns".

Great, so I won't use strcpy(), did it make my application more secure? Is it more or less hack-proof? What if I am a tester and required to play with this aspect of the application to ensure the application's security before the product ships? Theoretically hanging out at proper IRC rooms and getting lifetime Phrack and 2600 subscriptions should be enough to cover you at the beginning, however, the learning curve here leaves much to be desired, let alone the fact you will probably be kicked out of the IRC rooms for asking n00b questions. Another path would be to take an expensive training course by someone with a name in the industry, but the price tag for those generally leaves out self-learners and those operating on limited budgets, which adds up to about 99% of software engineers and testers out there.

Exploiting Software to the rescue.

Exploiting Software fills the void that existed in this market. Eight chapters take you through the basics and some advanced techniques of attacking software applications with the purpose of executing arbitrary code supplied by an attacker (you).

The book mainly deals with Windows applications for x86 platforms, and some knowledge of C/C++ and Win32 API is required to go through the example applications. To automate some processes and demonstrate possible attacks the authors use Perl, so knowledge of that would help the reader, too. Some chapters, (e.g. the buffer overflow one) show disassembler output, and while you're not expected to read x86 ASM code as if it were English, knowledge of how the registers work and how the subprocedure calls are handled on this Intel architecture are required. After all, if potential attackers know it, you better familiarize yourself with some low-level code, too.

While discussing various possible attacks, the authors post different attack patterns. The patterns themselves usually appear in gray textboxes and talk about the possible exploit in general terms. After that, a series of attack examples follow, with specific descriptions on what can be done, and how. For example, the attack pattern on page 165 is titled "Leverage executable code in non-executable files." The following attack example is "Executable fonts," and it talks how the font files are generally treated by the Windows systems (they are a special form of DLLs). Thus it's possible to embed some executable code into a font library you're creating, for which the authors provide an example in Microsoft Visual Studio.

What's cool is that all the attack patterns are listed in a separate table of contents (alas, not on the Web site table of contents, which just lists the chapters and subchapters), so you can browse to the attack pattern you decide to learn about, read some general info about it and then study specific examples. The examples themselves are not in the table of contents, which I think is a mistake, as it would make searching for possible patterns much easier. After all, how are you supposed to know that "Informix database file system" (p. 189) is under "Relative path traversal" pattern? Well, unless you know specifically that the line http://[Informix database host]/ifx/?LO=../../../etc/ is the one discussed in the example, you would have to either go through the index hoping no omissions were made, or read the chapter in its entirety.

One of the best chapters of the book, Reverse Engineering and Program Understanding, which provides a good introduction into techniques used throughout the book, is available online from Addison Wesley. By having a free chapter you already have 1/8th of the book, but don't think that the low number of chapters makes this 512-page title an introductory book.

Target Audience

Looks like there are two major audiences and reading patterns for this book: those wanting to fix their systems ASAP and thus using Exploiting Software as a reference, and those using it as a text book to learn about security. I've discussed the organization of the book above, and the reference types will probably be more interested in patterns and examples. For a casual reader (although casual readers wouldn't generally pick up a title with C++, Perl, ASM and hex dumps spread around the chapters) this is a book with great educational value, from two authors who have discovered numerous security vulnerabilities themselves.

Exploiting Software is not an easy title to read. Addison-Wesley shipped me the manuscript copy a month before it hit the bookshelves in its final version, and I found myself going through about two pages an hour. The authors bring up sometimes unfamiliar Win32 APIs and occasionally use ready-made tools available on the Web, so generally I found myself visiting MSDN and Google a lot to read through available documentation and download the latest version of the tools used. The book doesn't come with a CD. Some of the stuff, like inserting a malicious BGP packet to exploit a Cisco router (p. 281) is not really testable at home, and I have some reservations about verifying the example with my employer's routers.

The book is probably apt for 2nd or 3rd year computer science students and above. Besides the variety of languages that I mentioned above, you need to be familiar with the basics of Intel architecture, and generally be fluent with terminology like "buffer," "stack," "syscall," "rootkit," etc., as this is not an "Introduction to..." title. From my experience, you probably won't read it from page 1 to page 512 understanding everything perfectly, but for anyone interested in security and those making a career in software development it looks like a bookshelf must-have.

I interviewed Gary McGraw on the current state of software security, the relevance of the topic to the issues beyond C/C++ and improper buffer usage, and future directions in security. Network World magazine also ran an interview with the McGraw in which he talks about the reception of the book at the RSA Conference, whether the economics is right to invest in building secure systems, and whether his book does more harm by providing a compendium of known exploits.

Alex has written numerous reviews of other software and security titles. You can read more of his opinions at his Web site. You can purchase Exploiting Software: How to Break Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Don't forget...

[SCO$699FeeTroll]

...to pay your $699 licensing fee you cock-smoking teabaggers.

Re:Don't forget...

[Anonymous Coward]

This just in... the user "GneccoBoy" at The Network Ministry of Disinformation is a supporter of SCO.

CLOSE YOUR I TAG, YOU FUCKING DOUCHE, TIMOTHY

[Anonymous Coward]

***Here are some of the imdb.com reviews for "Gay Niggers From Outer Space":

Summary: The best homosexual racial minority sci-fi film ever.

"Morten Lindbergs classic cult short, Gay Niggers From Outer Space is one of
the first short films to really stick to what the title suggests. From the
time the first gay nigger walked onto the screen up until the final intense
climax with the Tourette's Syndrome Kingdom in Outer Space, it's filled with
dark comedy, action and plenty of suspense. "

"Gay Niggers from Outer Space is a masterpiece of a film. No other film
portraits emotions as majestically and stunningly since The Legend of Nigger
Charley and Home Alone II. With a cast of all-star African niggers and a
director with Kubrick potential, it is no wonder that Gay Niggers from Outer
Space is marked the greatest film of all time."

"From the very first scene where Gay Nigger Harris throws up on his own face
and commits suicide, to the climactic scene where Nigger Ralph Nader and
Nigger Humphrey Bogart fight over the last hashbrown and pick cotton til
their noses bleed, Gay Niggers from Outer Space is the most magical
portrayal of gay niggers open to the public."

***However, no mention is made of the hazadous lifestyle of gay niggers,
so the following is an attempt to explain those hazards in layman's terms:

Despite cries to the contrary in the media, AIDS is still primarily a gay
and black disease. The media loves to report the "growing epidemic" among
whites, when in fact the rate of infection among heterosexual whites is
dropping off significantly year by year. The media though, reports only the
TOTAL current infection rate, not the RELATIVE. So while there are more
cases each year, the RATE of infection is dropping quickly. Except for the
gay/nigger communities, where it's skyrocketing.

Why does AIDS seem to target gays and niggers so much more so than whites
and straights? Anal sex. The anus was not designed to accommodate vigorous
penetration as occurs in anal sex. Unlike the vagina, the anus has very
delicate membranes, which damage easily. Couple that with the fact that
sperm contains immune system suppressing chemicals. That's why the sperm is
not treated as a foreign protein in the vagina...because of the immune
suppressing effects of the sperm cells. Without this effect, pregnancy
could not occur, as the sperm would be attacked as a foreign protein.

In the anus, sperm has the same immune suppressing effect. During anal sex,
the anal wall is torn and open lesions form. Because there is little if any
sensory nerve endings in the anus, this damage often goes unnoticed. The
sperm then induce their immune suppressing effect, and the stage is set.
Various bacteria both beneficial and infectious dwell in the colon, as well
as viral matter. When the anus is ripped open, exposing the blood to the
immune suppressing chemicals in the sperm, and the viral matter passed
along with it, infection is virtually assured.

***So does the skyrocketing rate of AIDS infection mean that there are
skyrocketing rates of gay niggers???

***Not exactly, because most White people don't realize that a large
percentage of nigger males are bisexual. It's a great irony considering all
of their macho posturing and affectations. They tend to admire the male
physique, and when no women are present, they will hip-hop dance with each
other. Any port in a storm will do, because da' brotha's just gots ta
have it!!! Then they pass along the virus to their wives, girlfriends, and
family members.

***Here is a story about this phenomenon from "The Village Voice":

http://www.villagevoice.com/issues/0123/wright.p hp

And for the Toronto Gay Niggers:

HTML Error

[Anonymous Coward]

Please close your Italics tag.

I used to work with the author Gary McGraw

[Anonymous Coward]

He is a really brillant and interesting guy, but he had a really odd habit of picking his nose and eating the booger. Pretty nasty to watch!

teh spoke?

[Anonymous Coward]

rimjob on teh spoke? what does that mean exactly? anyone? help?

THIS JUST IN

[Anonymous Coward]

+-+-+-+ +-+-+-+ +-+-+-+
|Y|o|u| |A|r|e| |G|a|y|
+-+-+-+ +-+-+-+ +-+-+-+

But does it cover...

[MalaclypseTheYounger]

Stupidity? Security is easy. Making software stupid-proof is hard.

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

-- Douglas Adams

Re:But does it cover...

[IO ERROR]

This is where input validation comes in. Check every input value for sanity. Do something reasonable if the value isn't sane. How often have you forgotten to write error checking or input validation code? Do you check the return value from printf()? (yes, it has one) Every time? (I doubt it)

Writing bulletproof software is TEDIOUS. You still have to verify everything, and still somebody's going to find the one thing you missed and exploit the hell out of it...

Re:But does it cover...

[robslimo]

I agree that creating stupid-proof is difficult, but I'm not so quick to blow off the task of making software secure. One methodology I've not heard much talk about is testing with external software that tries to break the application (though there is at least one company who makes a such a product, eeye.com, I think). Just like any other aspect of ensuring robustness in software, testing is the next critical step after design.

So design it to be secure, then test it! Try to overrun buffers, throw illegal arguments and all around garbage input at it, some specifically designed and even more that are randomized. When it crashes or misbehaves, find out what trashed it and fix it up.

Design, test, test, test, test, test!

Re:But does it cover...

[dilettante]

Making software stupid-proof is also expensive.

Most programmers that i know who have an interest in security have already set up Windows or Linux boxes with known vulnerabilities and attempted to duplicate known exploits. But knowledge is, at best, half of the picture. In most commercial software endeavors, what's really important is convincing everyone along the chain of command that security is important. This seems like it should be simple, but security is one of those horizontal aspects of software development that adds considerably to the expense of system development, but doesn't add many new features.

Further complicating the problem is that even if someone were to develop an environment that attempted to prevent all of the problems caused by programmer errors, it would be horrendously complex and would likely kill performance. Until threat modeling and code inspections with an eye on security become commonplace, this problem will persist.

Re:But does it cover...

[SphericalCrusher]

Exactly. Even though I may pick this book up for a good read, I can already say that a good 50% of hacking is not technical.

The social engineer shows just how easy it is to obtain information from someone than it is to actually copy it from their computer. Just by dressing proper and knowing the correct lingo, you could easily masquarade as an employee for the company.

Read The Art of Deception, by Kevin Mitnick. Great read indeed.

Re:But does it cover...

[corbettw]

Does anyone else find it ironic that a review of a book regarding software security, which should include such topics as how to check for proper input, did not have a closing italics tag? Not that anyone's gonna hijack a site that doesn't have proper text formatting, but I think it's a glaring example that programmers are human, and human error is the root of all security breaches.

Re:But does it cover...

[Bombcar]

I hereby release the ultime software security patch under the GPL.

#!/bin/bash
cat $1 > /dev/null
rm $1 -f

After that, there'll be no security issues in the software!

Re:But does it cover...

[brandonY]

This is why tools like lint exist. Alongside about 1000 other useful things, lint tells you if you ever fail to check the return value of a function call. Sure, it's tedius to always check the return of printf, but it's necessary and to some extent it can be automated.

Re:But does it cover...

[cras]

This is where input validation comes in. Check every input value for sanity.

IMHO this is completely wrong way to do it. Write your code so that you don't have to check input for sanity - your code should be secure no matter what the input is. What input validation is useful is giving user meaningful error messages.

Writing bulletproof software is TEDIOUS. You still have to verify everything, and still somebody's going to find the one thing you missed and exploit the hell out of it...

Yes, like you say here. You're going to miss something if you rely on input validation to catch the security holes.

More ranting about the subject..

Re:But does it cover...

[John Whitley]

Further complicating the problem is that even if someone were to develop an environment that attempted to prevent all of the problems caused by programmer errors, it would be horrendously complex and would likely kill performance.

IMO, a big part of the solution is factoring out solutions for major known security problem areas into the environments, languages, and frameworks that developers use on a day-to-day basis. E.g. if you're using a language with robust automatic memory management, there's little reason to go looking for C-style buffer overflow exploits coded by your developers.

In today's environments (e.g. Windows and current *nix systems) with current popular languages (e.g. C, C++) we're at a big disadvantage. Much of the discussion in this thread presumes that coders can/should amass total knowledge of all levels of security exploits, from binary code injection to cross-site scripting (aka CSS), SQL injection, etc. It becomes overwhelming to a dev who really should be able to focus on the value-added problems at hand. I'm aware of only one cost efficient approach: choose environments, languages, and/or tools that mitigate known security risks.

Where applicable, this can be done by leveraging environments that can limit the scope of attacks. See SELinux and GR Security for ways to patch Linux to meet thess needs, or the EROS project for a fresh view of OS security and compartmentalization models. Environment choise is most relevant to folks providing networked services, where they can control the platform specifics.

The cause can also be aided by using languages/frameworks that encapsulate security knowledge. This can be as "simple" as using a language with automatic memory management(to factor out common buffer overflow problems), or along the lines of using scripting frameworks that standardize policies for correctly managing more complex security issues (e.g. cookie management, web input/output validation, CSS issues, etc).

I'd argue that it is possible to improve software security practices significantly simply by careful choices of tools and techniques available today. But it takes a saavy organization to really commit to providing secure software solutions, and to be able to do so in a cost effective manner. As always, the hard part of the equation is programming the wetware. 8-)

Re:But does it cover...

[johnnyb]

This is true. I've also found that if you over-validate the _form_ of input, then the customer service reps and business entities are going to assume that the _value_ of the input is also correct.

For example, in places where I have validated that phone numbers follow a proper form, the customer service reps assumed that the phone numbers were definitely correct - becuase they were all properly formulated.

It's easier on them if they get a few orders where the phone number is just plain wrong so that they know that this is a USER-generated field and that USERs can lie as much as they want to. It makes it obvious just who is responsible for verifying the validity of the information presented. If you make sure the _form_ is fully prim and proper, people are going to assume that you verified the content as well.

Re:But does it cover...

[Hiro Antagonist]

Er, how would you report an error to the user if printf() failed?

Re:But does it cover...

[cptgrudge]

Ah, yes, but that begs the question, if there is no software, did the security holes actually exist?

This is similar to the classic quote:

'If a tree falls in a forest, and no one's around to hear it, and it falls on a mime, does anyone care?' - Gary Larson, The Far Side

Re:But does it cover...

[Lucky Kevin]

"Further complicating the problem is that even if someone were to develop an environment that attempted to prevent all of the problems caused by programmer errors, it would be horrendously complex and would likely kill performance. Until threat modeling and code inspections with an eye on security become commonplace, this problem will persist."

Java does a good job with regards to protecting the local machine when running web-based applets. Java is not as fast as some languages but it does not "kill performance" and that seem like a small price to pay.

Re:But does it cover...

[maxwell demon]

Probably the mime does, despite being deaf. :-)

Re:But does it cover...

[thelasttemptation]

perror?

Re:But does it cover...

[Tony-A]

"The code doesn't get secure by polluting it with tons of security checks. It gets secure by keeping the security checks in as few places as possible."

True. Difficult but true. This belongs in the category of making programs more competent, more flexible, faster, and smaller.

The ideal is something that if it passes a few simple tests, is incapable of finding a (complicated) way to fail.

Re:But does it cover...

[Knetzar]

perror()?

Re:But does it cover...

[Tony-A]

Er, how would you report an error to the user if printf() failed?

You use printf(), obviously.
And prinf() had damned well better be recursive.

Now if the failure is intermittent, ... , something gets printed and you unwind the stack.

If the failure is permanent, you need to be able to read the blinking lights.
Works with the old obsolete stuff. With the fancy new stuff you're SOL;)

Re:But does it cover...

[Anonymous Coward]

Test, design, code. write unit test first, think about it, then code if you have to. The absolutely last thing you should ever do is write code.

Re:But does it cover...

[Anonymous Coward]

>using scripting frameworks that standardize policies for correctly managing more complex security issues (e.g. cookie management, web input/output validation, CSS issues, etc).

If you are using client-side scripting to validate your web forms, you need to work on your security.

Re:But does it cover...

[TheLink]

I disagree. Security is not easy, at least not for most people I know/encounter. Making stuff stupid proof is hard, BUT making stuff secure is harder.

Whilst the boundaries of stupidity could have no limits, determined, knowledgeable and smart people are statistically more likely to be able to find and exploit the limits of your software, than the stupid people are by accident or ignorance. The curve is different.

As a consultant, I checked a bank web app before it was due to be launched (after an internal soft launch), and after a few minutes I found by doing certain things you could cancel other people's cheques. They had already launched the app for internal staff use.

In a mobile telco I checked, it used to be that any valid online user/subscriber could see other people's accounts and itemized bills by just submitting the valid account number in a html form.

And this is all simple stuff. There are many others.

Thus the stupidity/ignorance is often at the designer/manager side of the fence and not the user. i.e. stupid managers getting stupid programmers to make software stupid proof (and never thinking about security).

It took months for some of these sites to fix their problems. And some aren't fixed _properly_ too. Go figure.

There are many people smarter and more knowledgeable than I am, and more focused on finding flaws in software. The ones that find stuff and keep things secret are the ones that you should be afraid of. Many bugs go unfixed for years even when reported.

Whoop dee fuckin' doo

[Anonymous Coward]

...and would this be useful for the newbie coders?

[Penguinisto]

The one question that sticks out is yes, learning how something is exploited will help out a guy who already knows how to code (and has enough experience to look at an exploit from both sides of the attack), but what about the newbie coder who, more than anyone else, desperately needs to know how to code properly in the first place?

Someone ought to combine a guide for writing secure code, but with exploit examples that dissect it from both crack and code perspective. (does this book do that, perhaps? Maybe I missed it, but I didn;t see any indication of that in there...)

MOD PARENT UP!

[Anonymous Coward]

Good Reading

[Anonymous Coward]

While I've only read the sample chapter given out at the recent RSA conference, I found it to be extrememly interesting. Useful for those looking for ways to secure consulting gigs fixing blatant security flaws in common software (especially web apps)

Just what we needs...

[Anonymous Coward]

more examples for the kiddies!!

Re:Just what we needs...

[TobiasSodergren]

My _guess_, since I haven't actually read the book, is that it discusses common security practises rather than strange bugs in specific software. I also guess that these security issues are already known among evil-doers.

Or, I just failed to get the joke :)

poetry in motion

[tomstdenis]

Why I love Bruce...

"We wouldn't have to spend so much time, money and effort on network security if we didn't have such bad software security."

Is to smart as

"We wouldn't have some many crumbling roads if heavy vehicles didn't drive on them"

Is to insightful. I still say the best way to experience Bruce's mind in action is in person. In his books he's trying to pander to the market [of let's face it less than apt people] and in person he's talking with fairly brilliant people [e.g. me ;-)]

Tom

Re:poetry in motion

[Anonymous Coward]

Looks like someone flunked the analogy sectin on the SATs. Actually what he said is more like,

"We wouldn't have to spend so much money fixing roads if we would just build more resiliant roads in the first place"

Which is perfectly true. Sure it's not groundbreaking, but then it's not meant to be. The difficult job for quality insurance people is just to make people like you shut up and actually change the problem behaviors.

Re:poetry in motion

[Anonymous Coward]

Yeah, you're a regular genius. Network security and software security are not the same things. Re-read your favorite quote, slap your forehead, go "Oh!" and then get on with your life.

Re:poetry in motion

[IMarvinTPA]

"We wouldn't have some many crumbling roads if heavy vehicles didn't drive on them"

I don't quite agree with that. It is more like: "We wouldn't have so many crumbling roads if large, heavy, spiked/square tire vehicles running on afterburner didn't drive on them."

IMarv

Re:poetry in motion

[GPLDAN]

Schnier seems to have made a career out of stating obvious truisms, like "all security is a tradeoff." I mean, I've read his books. Are these books really considered insightful?

I don't understand the appeal. The Myth of Homeland Security by Marcus ranum is 100x the book that Schnier's is. Ranum actually worked in Washington, he not only shows where security breaks down, but the why of the politics behind it. In 100 years, professors who wish to study Computer Security at this stage of history will put Ranum's book on the syllabus and nobody will remember Bruce.

I guess this all goes back to "Applied Cryptography". A book full of code showing how to code the encryption algorithms widely known about. Compiled from the Internet. It may have made a stink when it was published, but what's worse is Schnier rode the publicity all the way.

Re:poetry in motion

[sammy baby]

Better, but let me try a third analogy:

"We wouldn't have to spend so much money making our roads perfect if we weren't all driving around on bald tires."

That gets, I think, to the heart of the issue - that people blame the road for problems that might be better addressed by looking at the cars.

Re:poetry in motion

[tomstdenis]

You missed my point [usual for an AC]. The point is Bruce is 99% mouthpiece. People quote him because he knows how to use webmail [I've seen him use it personally, it was fascinating], has long hair and says things like "it's the ramifications of the draconian backbone we are all founded on."

Seriously though... in person he's puts on a good show, has a sense of humour and more importantly knows when to turn off the media filter.

Tom

Re:poetry in motion

[Beryllium Sphere(tm)]

>Schnier seems to have made a career out of stating obvious truisms

Evidently they're not obvious to everyone. If you've been through an airport in the last couple of years, or used a mass-market network-enabled software product, or looked at the security advice given by newspaper columnists, you're forced to conclude that the world needs "Beyond Fear" more than it needs Blowfish.

Re:poetry in motion

[Tjebbe]

And here we see that analogies, like code, are hard to get right the first time (or the second).

Re:poetry in motion

[sammy baby]

Brilliant. :)

/*t#R#O#L#L*/

[Anonymous Coward]

/*/*/*/*
| TROLL |
/*/*/*/*

Re:...and would this be useful for the newbie code

[kneecarrot]

I would hope that no one lets a newbie coder get his grimy little paws anywhere near code that requires a careful consideration of security.

Note: I did not post this anonymously so I MUST NOT be a troll.

De-Italicize

[TwistedGreen]

Looks like you forgot a closing tag...

</i>

How about..

[SpanishInquisition]

a book about exploiting the tag

Re:How about..

[Anonymous Coward]

OMG! Who could have expected you?

Re:How about..

[Anonymous Coward]

Nobody expects the Spanish Inquisition... O_o Nobody, I say!

eXPloding softwar gangsters' payper liesense?

[Anonymous Coward]

the FraUDuleNT badtoll is nearly over? lookout bullow.

consult with/trust in yOUR creators.... the kode has been showed.

Who modded this informative?

[bad enema]

Hello? An AC claiming to work with the author? First post?

Quel naive.

Exploiting software

[Anonymous Coward]

The authors never state that security is not adequately addressed by software engineers but rather there is no lack of mistakes not to be made in designing a product that is inherently insecure.

italics

[golden spud]

Editors - please fix the non-closed italic tag in the entry so the front page of the site doesn't show up in all italics. Thanks :)

Let the environment help us

[Lucky Kevin]

We need to use more intelligent environments to protect us from ourselves (and other less good proogrammers :-)).
Like the security manager in Java and the security "taint" stuff in Perl.

Electron Band Structure In Germanium, My Ass

[Anonymous Coward]

Abstract: The exponential dependence of resistivity on temperature in germanium is found to be a great big lie. My careful theoretical modeling and painstaking experimentation reveal 1) that my equipment is crap, as are all the available texts on the subject and 2) that this whole exercise was a complete waste of my time.

Introduction

Electrons in germanium are confined to well-defined energy bands that are separated by "forbidden regions" of zero charge-carrier density. You can read about it yourself if you want to, although I don't recommend it. You'll have to wade through an obtuse, convoluted discussion about considering an arbitrary number of non-coupled harmonic-oscillator potentials and taking limits and so on. The upshot is that if you heat up a sample of germanium, electrons will jump from a non-conductive energy band to a conductive one, thereby creating a measurable change in resistivity. This relation between temperature and resistivity can be shown to be exponential in certain temperature regimes by waving your hands and chanting "to first order".

Experiment procedure

I sifted through the box of germanium crystals and chose the one that appeared to be the least cracked. Then I soldered wires onto the crystal in the spots shown in figure 2b of Lab Handout 32. Do you have any idea how hard it is to solder wires to germanium? I'll tell you: real goddamn hard. The solder simply won't stick, and you can forget about getting any of the grad students in the solid state labs to help you out. Once the wires were in place, I attached them as appropriate to the second-rate equipment I scavenged from the back of the lab, none of which worked properly. I soon wised up and swiped replacements from the well-stocked research labs. This is how they treat undergrads around here: they give you broken tools and then don't understand why you don't get any results. In order to control the temperature of the germanium, I attached the crystal to a copper rod, the upper end of which was attached to a heating coil and the lower end of which was dipped in a thermos of liquid nitrogen. Midway through the project, the thermos began leaking. That's right: I pay a cool ten grand a quarter to come here, and yet they can't spare the five bucks to ensure that I have a working thermos.

Results

Check this shit out (Fig. 1). That's bonafide, 100%-real data, my friends. I took it myself over the course of two weeks. And this was not a leisurely two weeks, either; I busted my ass day and night in order to provide you with nothing but the best data possible. Now, let's look a bit more closely at this data, remembering that it is absolutely first-rate. Do you see the exponential dependence? I sure don't. I see a bunch of crap. Christ, this was such a waste of my time. Banking on my hopes that whoever grades this will just look at the pictures, I drew an exponential through my noise. I believe the apparent legitimacy is enhanced by the fact that I used a complicated computer program to make the fit. I understand this is the same process by which the top quark was discovered.

Conclusion

Going into physics was the biggest mistake of my life. I should've declared CS. I still wouldn't have any women, but at least I'd be rolling in cash

something else too

[Anonymous Coward]

I just used a public toilet and there was shit on the fucking seat! I sat down in someone elses fucking shit!!

Re:something else too

[Anonymous Coward]

Well, you shouldn't be reading Slashdot while you're looking for somewhere to sit...

Can't build security on a weak foundation

[Theodrake]

I keep reading all these books about how to fix the holes in existing s/w. How to not build systems that are full of holes. It seems we need a decent foundation and its not C. The DoD tried with Ada to design a language that eliminates a lot of the coding mistakes, but it just wasn't embraced. It just seems we are attempting to layer security on top of an inherently insecure software language.

Re:Can't build security on a weak foundation

[Anonymous Coward]

power comes with responsibility.

remove all power and you have something secure, and something quite useless.

Re:Can't build security on a weak foundation

[cmburns69]

While C can easily be insecure, it's still one of the fastest and most powerful languages. Other languages are powerful as well, but nobody benchmarks against Java as their base. The reason is because to do all that checking internally, you have overhead.

C does not have that overhead unless you add it. I don't think that adding another layer is the solution. I think better training of coders would help more. (Which is where a book like this comes in)

Re:Can't build security on a weak foundation

[tedgyz]

That was actually one of the primary goals in the design of Java. After writing Java code for several years now, I can't imagine having to use strcpy or worry about whether I'm supposed to free an object or if the API I'm using will free it for me.

I'm sure the C/C++ bigots will flame the hell out of me. Nonetheless, many of the exploits we read about every day simply wouldn't exist if a safer language were used.

BTW, I participated in the whole "Ada thing" back in the 80's, having worked for a hardware vendor that needed Ada as a "checklist item" (what a freakin' expsensive checkbox that was!). Ada got a lot of things right, but didn't go quite as far as Java in incorporating inherently safe language constructs. What I really liked about Ada was the package concept, and built-in language constructs for multi-threading. Ada's biggest faults were trying to bring in too many features and the fact that is was ahead of it's time. It was just too damn slow for the hardware of the day.

Re:Can't build security on a weak foundation

[maxwell demon]

I'm sure the C/C++ bigots will flame the hell out of me.

Well, for the C++ part, only for your shown ignorance of C++. I can't imagine calling strcpy (or strncpy, for that matter), too, when I can just write s1 = s2 + s3 with the C++ standard library string class (while not even having to think about how much memory needs to be allocated, or where it needs to be deallocated later). And in C++, all ressource handling (not only memory!) can be handled by a simple rule: Ressources are allocated only in a constructor, and deallocated only in the corresponding destructor.

Now, when speaking about C ... well, I never liked that.

Re:Can't build security on a weak foundation

[Anonymous Coward]

deallocated only in the corresponding destructor.

Yeah, that's fine and dandy until you bring about the virtual destructors...

Re:Can't build security on a weak foundation

[stevey]

There is far more to security than having to deal with buffer overflow attacks.

Sure Java tends to be more secure, but part of the reason for that is the lack of usage in places where normal C would be - for example I've never seen a setuid(0) Java executable.

For network servers I agree buffer overflows are pretty much prevented by the use of Java. However there are still flaws there to be exploited due to programmer error - such as writing a HTTP server and not filtering out "..".

This kind of problem is independent of the language, a real human error.

Re:Can't build security on a weak foundation

[maxwell demon]

Where's the problem with them?

Re:Can't build security on a weak foundation

[Beryllium Sphere(tm)]

>C does not have that overhead unless you add it. I don't think that adding another layer is the solution.

This is a healthy attitude to take while you're writing code. I produce better code when I try to convince myself that bug-free code is attainable.

If you're designing entire systems, it's safer to take the realistic view that human error occurs at predictable rates in the most highly trained people. Highly trained people are still vulnerable to getting tired, distracted, misled, and to fat-fingering things.

The question is whether you're willing to spend CPU cycles (the cheapest thing in the world) to reduce the scope for human error (the most certain thing in the world).

Re:Can't build security on a weak foundation

[Greyfox]

My favorite sigsegv in C would result in a (probably uncaught) NullPointerException in Java. Dude created a validateInput function which took a string from a tokenizer and the first thing it did in the function was use strlen() to check the size of the string. Except that the tokenizer liked to return NULL pointers for the string if the input was empty. This caused strlen to hork up a sigsev.

s/tokenizer/StringTokenizer/ in Java and create a validateInput() method that calls .size() on its imput string and you'll get a very similar run time crash of your application. Sure it's a potential access exploit in C while in Java it's only a potential DOS, but changing languages does not magically make your programs (or your programmers) more secure. And 5 gets you 10 after your programmer gets the NullPointerException the first time and isolates the cause, he just puts a catch(NullPointerException e) { } in his code (IMHO Java should not allow empty catch blocks...)

You can make your C++ code pretty secure if you actually use the new language features everywhere. You can't really benefit from, say, std::string, if you never use it anywhere.

Personally I like LISP as a not-too-obnoxious language that had most of the useful features of java a decade or two before java was invented. But that's just me...

Re:Can't build security on a weak foundation

[johnnyb]

"Ressources are allocated only in a constructor, and deallocated only in the corresponding destructor."

That is not a 100% solution, especially since knowing when to call a destructor is often difficult as well.

All C++ compilers should have Garbage Collection turned on by default.

Re:Can't build security on a weak foundation

[tedgyz]

Why waste all that time teaching people how to avoid shooting themselves in the foot, instead of simply removing the gun? If you provide an environment that makes it impossible to make certain mistakes, isn't that preferable than hoping that the programmers have learned their lesson? As Bill Joy said, "Hope is a lousy defense."

You're argument for C based on performance is just plain silly. Since most security issues center around networking, are you ready to say that network programs are CPU-bound?

Re:Can't build security on a weak foundation

[maxwell demon]

It's easy: Not at all. The compiler does it for you.
Now, if you are thinking of delete, well, that's again freeing a ressource (memory), and therefore belongs into a destructor.

Re:Can't build security on a weak foundation

[tedgyz]

Now how can you say I'm ignorant of C++. The parent I responded to was talking about C. I mentioned C++ simply because it inherits all of the baggage of C. Sure, I probably would not use strcpy in C++, but I could if I wanted to. C++ would be a bit more reasonable if it prevented the usage of C constructs.

Re:Can't build security on a weak foundation

[tedgyz]

I will whole-heartedly agree that you can write really bad, stupid code in Java. What you can't do is write the kind of exploits that are so common in the C codebases of Windoze and Linux.

Just because you can still make some stupid mistakes is no reason to rule out a language that eliminates a whole category of mistakes. I spent more time than I care to admit chasing down my off-by-1 string copy errors in C. Then there are all the memory management errors, such as using a freed object - the silent killer. It doesn't fail now, but add in some new logic a year from now and suddenly that free memory is corrupt. Bork bork bork!

Re:Can't build security on a weak foundation

[johnnyb]

But which destructor? If X is passed as a pointer into two different data structures, how does each one know when they should kill X?

Re:Can't build security on a weak foundation

[maxwell demon]

If X is passed as a pointer into a data structure, then X was not allocated in that data structure, and therefore X is not to be deleted in that data structure
(smart pointers are being the obvious exception; here the allocation should happen directly in the constructor argument and is for the sake of this rule considered part of the smart pointer constructor).

According to the rule, X was newed in a constructor, therefore X must be deleted in the corresponding destructor.

Re:Can't build security on a weak foundation

[Anonymous Coward]

Yes! Certainly in Java, where the "thread everything" mentality can throw a CPU into context switching hell for even a small number of connections.

But that is all beside the point. The real solution is sound engineering and using the right tool for the job, be that C, Java, Perl or w'ever. And don't forget, less code is more. Seasoned C developers can code solutions w/ 1/10 the source of those who refuse to learn how to properly scope the problem (and those people might be using a supposedly more "productive" and "safe" language).

Re:Can't build security on a weak foundation

[skrysakj]

Any Ada compilers I ever used were just a layer on top of a C compiler. Meaning, your Ada code was translated to C, and then compiled. That may not be an exact representation, but it's close.
In that kind of a situation, you are subject to the graces of the compiler writer, and still vulnerable to certain C security issues.

But, as a whole, Ada was a good way to write something with fewer problems. Most of it was due to its higher attention to compile time warnings/errors (most things were errors), strict data type checking, etc.... and any of that can be applied to other languages. Just turn warnings into errors (show stoppers),
write the compiler to slap people on the hand for things like "if x=0" instead of "if 0=x" and you're on your way to mimicking what Ada did.

Re:Can't build security on a weak foundation

[Anonymous Coward]

By your comment, I doubt you've done much in the way of Java programming...

The only way StringTokenizer's nextToken() method will result in a NullPointerException is if the delimiter passed in is null (and I can count on one hand the number of times I've had to parse a string based off a variable delimiter.) Otherwise, nextToken() will always return a String, be it 0 length or otherwise. Also, calling the size() method in java.lang.String will result in a compile-time error since the method to determine a String's size is length().

I agree that there are many times where simply porting to Java doesn't get you much, but your example is one where moving to Java does have an advantage.

Re:Can't build security on a weak foundation

[johnnyb]

But in this case it was created and sent to two DIFFERENT entities, neither of which contained it during construction. It outlives the object which actually constructed it.

Smart pointers work okay, but do not work perfectly. They are especially bad when dealing with legacy code.

Garbage Collection takes care of all of this, without having to have lots of overly-strict resource allocation/deallocation rules.

Re:Can't build security on a weak foundation

[TheLink]

I agree.

In sane languages, simple and common programmer mistakes should very rarely allow an attacker to run arbitrary code of the attacker's choice.

In C such an occurrence is so common that many people think it is normal and near acceptable.

There must be other languages that perform about as well as C and not prone to such insanity. Looks like we're stuck with C and its problems for an indeterminate time.

Re:...and would this be useful for the newbie code

[Anonymous Coward]

Yeah, we put all the new guys on security.

Re:...and would this be useful for the newbie code

[Ytsejam-03]

I would hope that no one lets a newbie coder get his grimy little paws anywhere near code that requires a careful consideration of security.

Everyone writing code should be giving careful consideration to security. In my experience few developers do, but that number is increasing...

Social Engineering

[Bs15]

I wonder if they talk about security risks regarding social engineering.

The hell with software...

[Anonymous Coward]

I'd rather exploit wetware.

Invasion of Italics

[ultrajazz]

The italics have invaded and taken over.

Secure code in risky languages: Hard

[fuzzy12345]

If you've been around long enough to start seeing patterns in software flaws, keep asking yourself: "What misfeatures of the program's source language contributed to this flaw?"

Personally, I find that I rarely need to access the thirty-second element of a thirty element array, and I'd die happy if I never have to type for(i=0; i<offbyone; i++){ again.

I used to think that Perl with taint checking enabled was the cat's meow, but I'm now leaning towards Lisp. For the rest of you, is it fair to blame the programmer when his tools (which are supposed to make his life easier) fail him? Use better tools!

Re:Secure code in risky languages: Hard

[Phisbut]

For the rest of you, is it fair to blame the programmer when his tools (which are supposed to make his life easier) fail him? Use better tools!

Still, a good programmer should know his tools, and know the limits of his tools.

Re:Secure code in risky languages: Hard

[asrb]

Still, a good programmer should know his tools, and know the limits of his tools.

True, but the problem is that there are so many dangerous limits and gotchas in C/C++. This requires a programmer to spend a large chunk of his time and mental energy thinking about and dealing with these issues. That is time that isn't spend on the business/technical problem the software is supposed to solve.

Wouldn't it be better to use a safer language, where one can do something like:

for X in My_List'First..My_List'Last loop
-- Do something with X
end loop;

than to worry about having the size of the list correct, and worrying that you'll introduce a gruesome, hard to discover bug/possible security flaw if you're wrong?

Re:Secure code in risky languages: Hard

[maxwell demon]

You mean like:

typedef std::vector<int>::iterator iter;
for (iter it = myvec.begin(), end = myvec.end();
it != end;
++it)
{
do_something_with(*it);
}

Granted, it's a bit more to type (I'd like to have myvec::iterator!), but where do you have to know the size of the list here?

BTW, if you just call a function, you can have it even shorter:

std::for_each(myvec.begin(), myvec.end(), do_something_with);

Re:Secure code in risky languages: Hard

[Phisbut]

There ya go. There is indeed a whole lot of tools in C/C++. Some are more risky than others.
Programming is no different than any other building job. A good C++ programmer knows what tools to use and what tools not to use. Just like a good carpenter knows which hammer to use in each situation.

Therefore, I believe that one can blame the programmer that his tools failed if he didn't use the right tools for the job.

Re:Secure code in risky languages: Hard

[elFarto the 2nd]

Java:

ArrayList array = new ArrayList();
array.add("foo");
array.add("bar");
Iterator it = array.iterator();
while (it.hasNext())
{
Object obj = it.next();
doStuff(obj);
}

VB:

Dim myarray(10) as String

for i = lbound(myarray) to ubound(myarray)
doStuff(myarray(i))
next i

Regards
elFarto

Re:Secure code in risky languages: Hard

[Tokerat]

This is why I think that for debugging builds (and perhaps this day in age, when it's usually acceptable to waste a few extra cycles, for final builds as well) C/C++ should have runtime array bounds checking built in. You could always do pointer arithmatic to get around that when it's nessesary, anyway.

Also, better tools would be an editor that allows you to make macros for common stuff like the for you mentioned.

/observe ensuing vi vs. emacs flamewar ;-)

Re:Secure code in risky languages: Hard

[Anonymous Coward]

Personally, I find that I rarely need to access the thirty-second element of a thirty element array, and I'd die happy if I never have to type for(i=0; i

That's fair, but how do you get offbyone at all?

int array[ARRAY_SIZE];
for (i=0; i&lt;ARRAY_SIZE; ++i)
etc(array[i]);

You'd have to manually insert a +1. I suppose you might accidentally use &lt=, but if you're not thinking about what you're doing, you'll manage to screw something up anyway.

I would think the most common off-by-one array error would be:

string_b = new char[strlen(string_a)];
strcpy(string_b, string_a);

For the rest of you, is it fair to blame the programmer when his tools (which are supposed to make his life easier) fail him?

Anti-cliche? "It's a poor workman that blames his tools." If the language works in a consistent and predictable way, then it is not failing. If you can't understand that consistent and predictable way, it's not the language's fault, you just probably shouldn't be using it.

It's not the bicycle's fault if you don't know how to work it and keep falling over. Maybe you'd be better off walking or calling a cab.

How Secure is Secure??

[Un0r1g1nal]

You can write up about security, and tell people to code properly and validate everything but there are always going to be either exceptionally skilled hackers or totally inept users who will be able to do something that you didn't think of, and cause problems.

Look at some of the breaches that have been published in the last few years, and then consider if they are the ones they published (usually because they caught the person who hacked them) how many more are unpublished, either because they couldn't catch the attacker, couldn't figure out how the hacker got in in the first place or because said attacker penetrated so deeply they didn't want to be embarresed by it.

But as a good point, it allows people to keep being employed in the network security industry :P So all in all it's a good thing...

Re:How Secure is Secure??

[owlstead]

Most security issues are from bad designs or bad tools/techniques. That anything can be broken by a genius hacker or genius fool is complete non-sense in my opinion. Maybe this is used as an excuus, or just romanticism, but I've never seen any proof to that theory.

Things like buffer overruns (bad tools and/or bad design) and plain stupidity (build part of IE into kernel space) are the biggest problems in my opinion.

Re:How Secure is Secure??

[Anonymous Coward]

You can write up about security, and tell people to code properly and validate everything but there are always going to be either exceptionally skilled hackers or totally inept users who will be able to do something that you didn't think of, and cause problems.

I don't think so. All input can be divided into a finite (and small) number of classes, and each class of input can be dealt with.

Computers can be made absolutely secure.

Look at some of the breaches that have been published in the last few years, and then consider if they are the ones they published (usually because they caught the person who hacked them) how many more are unpublished, either because they couldn't catch the attacker, couldn't figure out how the hacker got in in the first place or because said attacker penetrated so deeply they didn't want to be embarresed by it.

That doesn't support your point at all. There are certain types of flaws that are very common, usually caused by inattention or the assumption that the user will always enter correct data. If the fix for one class of bugs was applied to all software as soon as the first exploit discovered, this mess would all be behind us by now.

The problem starts at management...

[kbonin]

I write security software for a living, occasionally. I'm back in it now, after leaving it for a while out of frustration, among other things.

The problem is that even for us security geeks, its nearly impossible to get management to buy into spending the time to make things secure. Nobody would believe the stories I could tell about having security features gutted 'cause marketing decided certificates were too complicated, or 'cause access control systems were too hard to use, so "just put the built in passwords back in", or "*** wants a copy of the private keys", or "*** told me to tell you to check the private keys into version control". Stupid, stupid...

Until companies start caring about making products that are ACTUALLY secure, instead of just hiring security geeks to act as figureheads, then not letting them do their jobs, then system will continue to get hacked.

Sounds interesting

[plcurechax]

It sounds like I thought I was getting when I bought Hacking: The Art of Exploitation by Jon Erickson, which is fairly basic and easy to read level, other than some of the writing is not as polished as it could be. It did get through the basic concepts explained in various classic Phrack articles but without the 'leet speak which drives me crazy.

It sounds like this is a more serious and rigious book, and those that were turned off of Jon Erickson's Hacking might prefer it. I think I will take a look at it.

I think new programmers are likely better served reading something like Writing Secure Code: Practical Strategies and Proven Techniques for Building Secure Applications in a Networked World by Michael Howard and David LeBlanc or Building Secure Software by John Viega than get bogged down in details of this book.

Re:Sounds interesting

[Anonymous Coward]

Microsoft has a book called Writing Secure Code? I looked in the humour section at the bookstore but I couldn't find it.

Why care about insecure software?

[Anonymous Coward]

There are harsh sentences for computer hacking, and U.S.-style laws are being pushed all over the world, so I don't see why we should focus on making software "secure". Lawmakers made it clear that they want to be in charge of computer security, so let's not worry about it. The idea is that if programmers don't have to worry about security so much, then software development time gets reduced, which helps the economy.

Unreasonable expectations.

[ron_ivi]

From the article: " early computers were not designed to work in the network environment, and even most software written later was designed to work on benevolent networks "

Ugh that's like saying "most office desks aren't secure since their locks are weak and can be drilled easily".

Part of the problem is one of expectations. When people use insecure components and have unreasonable expectations that the'll magically be safe because one piece asked for a password.

There's nothing wrong with components (desk locks or computers) that expect to be kept in benevolent environments.

Next they'll be telling us Wikipedia's not secure because their password-checker is weak.

Re:Unreasonable expectations.

[maxwell demon]

I think his point is that they are not in such an environment any more, due to the internet. That is, your office desk is now at some public place, with lots of people who'd really like to get in. A place for which it wasn't designed, and for which the security doesn't suffice any more.

Re: oh, really?

[Anonymous Coward]

Looks like your closing tag can't handle it either, you ic!!

Writing is bad enough, testing is worse

[RLW]

It is true that writing bulletproof software is TEDIOUS. However, after watching our test staff I have determined that testing it is beyond tedious. It is mind numbing!

The company I work for makes software for wafer fabrication. If the software fails, no one dies but millions of dollars of materials and time can be lost: we spend a lot of time testing and retesting and verifying our tests and going over scenarios to make sure we get it right. Event with all that, over the last couple of years we've logged over 600+ defects of various types. All the way from a misspelled word on an error message to miss-processed data to crashes. Most of those errors are detected in house and the customer doesn't see them: but I would guess we get 4 to 8 defects reported from customers every month with most being minor but a few are so egregiously bad that should have been impossible for that to make it through testing. But even a small error can cost tens of thousands of dollars or more in losses so no bug is a good bug.
Most other places I've worked have testing in name only. The code is compiled and run for a few seconds: some edit boxes are typed into and the mouse is wiggled around and that's it.

If architects make buildings like programmers write code then every woodpecker that comes along destroys civilization.

Re:Writing is bad enough, testing is worse

[Greyfox]

I did security auditing in a standard C library in a previous job. We wrote customized automated test for every freaking C library function. Not only did we document potential side effects from each one of those functions, we could run the entire test suite whenever modifications were made to the library to insure that everything still worked as expected. That job was a real eye-opener, let me tell you...

Little things can make a big difference too. Let me give you a hypothetical; Lets say the AIX standard C library strlen() tests its input to make sure it's not a NULL pointer prior to testing the string. Lets further say that the Gnu C library doesn't make this test. Recompiling your AUX application on Linux would potentially introduce crashes whenever your application encrounters a strlen.

While the above was a hypothetical situation, I have uncovered a good many memory overflows and leaks simply by compiling and running an application on a different flavor of UNIX than it was originally written for. Having safe underlying library calls is nice, but it also introduces the possibility that actual errors will go unnoticed for a longer period of time.

I'm pretty well convinced that in a situation where the need for security is high (Say, for example, an OS kernel) documented testing of every single function that makes up the software is a necessity.

Re:Writing is bad enough, testing is worse

[Tony-A]

If architects make buildings like programmers write code then every woodpecker that comes along destroys civilization.

And the architects' answer would be to woodpecker-proof every stick of wood???

If you need to test every case, check every return code, etc, etc, there is something very bad, very fundamentally bad, with the design of the whole mess.

With no testing or checking whatever in the program, it should be impossible to create a disaster all out of proportion to the cause.

Re:Writing is bad enough, testing is worse

[RLW]

Every function should either check all inputs for valid states and conditions or they are hidden functions that have this done for them. If they are hidden they are never exposed as an API or even beyond the class or compilation unit they come from.

As far as disasters all out of proportion to the cause, computers are famous for that. There are cases where I've seen very small changes in the code base result in huge messes. This is usually related to pointers or boundary conditions(inputs approaching, or on, or just past the extreme ranges of valid inputs).

The problem isn't that programmers are any more lazy than the architects. The reason buildings don't fall down from minor stresses is because when they do, people tend to die. Over the course of human history architects have made monumental mistakes that have cost the lives of many, many people. Two things have come as a result of these failures.
1) Materials knowledge: knowing just how much stone, brick, wood, etc. is required to hold up a given force over a given span under specific conditions. Mercifully in this age most of this information comes from intentional failures in stress labs. Even so, modern building failures still happen.
2) Building Code: Given what is know from 1, codes are in place to make sure that architects know what is required to make their buildings safe. Even here though the codes are not perfect and they change fairly regularly.

People make mistakes. Sometimes these mistakes are made in code. When that happens the computer replicates these mistakes unerringly. Sometimes with frightening rapidity.

Re:Writing is bad enough, testing is worse

[Tony-A]

As far as disasters all out of proportion to the cause, computers are famous for that.

The situation is worse.
People are surprised when it happens.

I'd blame unit testing and only attempting integration when the units are "debugged".
I'm lazy. I prefer the approach of throwing the whole mess together immediately and watch the fireworks. It's not enough for a unit to behave properly when the rest of the world is correct. It much behave no worse than can be expected regardless of the bugs in the rest of the system. How many (serious) bugs show up only in the presence of another bug?

All men are created equal. Maybe.
All bugs are created equal. No way.

Re:Writing is bad enough, testing is worse

[Anonymous Coward]

If builderss make buildings like programmers write code then the first woodpecker that came along would destroy civilization

Re:Writing is bad enough, testing is worse

[BiggerIsBetter]

That would be a very good - and extraordinarily boring - Linux kernel sub-project. A testing framework that runs continuously over the source tree and flags when things are broken/out-of-limits/unsafe etc, makes a lot of sense. It's the sort of thing that should be on the kernel.org page, showing that state of say, stable, pre-patch, development, etc. I'd sure feel safer *knowing* that my OS is secure and reliable, not just that smart folks *think* it is.

Re:Writing is bad enough, testing is worse

[Qui-Gon]

You can do that today. Splint

Re: Writing is bad enough, testing is worse

[gidds]

Having safe underlying library calls is nice, but it also introduces the possibility that actual errors will go unnoticed for a longer period of time.

Isn't the solution to have libraries that are safe, spotting and handling many types of errors, but that log those errors somewhere? That way you get an application that doesn't crash unnecessarily, but you also get early and specific warning of bugs. Of course, they can also test for conditions they can't handle, and stop then and there. Assertions, in other words.

This is a special case of a more general principle: discover bugs as early as possible. That's why I like strong typing and similar features that move discovery from run-time to compile-time. Assertions similarly can discover bugs much closer to their source, before knock-on effects cause odd failures or crashes elsewhere.

Ideally, everyone would use assertions liberally, but in practice we tend not to bother until we hit an awkward bug...

The same applies to testing, too. We should do thorough and disciplined testing, but in practice we don't bother. It is true, though, that some types of application or library are several orders of magnitude easier to test than others. Automated test suites that are easy to write for text-only, non-interactive, single-threaded, single-tier code tend not to work so well when the code involves many threads on many different machines, GUIs, complex DB state, &c...

Re:Writing is bad enough, testing is worse

[Random Walk]

Splint relies heavily on annotations within the code. This has two major consequences:

• it is extremely tedious to use if you have not used it right from the beginning of your project
• it will tell you that your code is OK, if you (via annotations) tell it that the code is OK ... but what if your annotations are incorrect ? I think it just moves the problem from writing correct code to writing correct annotations.

great book

[Dunceor]

I ordered this book just when it came out and got it about an week ago. Im still reading it since I try to read it very careful and Im writing on a review of it and several other books with exploit techniques also. I can recommend this book and it was a nice review..

It's Kind of Sad...

[redragon]

Just in case you were wondering, the list above wasn't just retrieved by a quick search at Amazon. My Master's degree, completed last summer, dealt with the topic of software security, and those are the titles I've read preparing to write the theoretical part.

It's kind of sad that a statement like this is even necessary. It's an interesting statement regarding what kind of qualifications are often necessary just to get a typical reader to give you credit for not being an idiot.

Re:It's Kind of Sad...

[Idarubicin]

It's kind of sad that a statement like this is even necessary. It's an interesting statement regarding what kind of qualifications are often necessary just to get a typical reader to give you credit for not being an idiot.

I don't know--I think it's appropriate for for the author of a review of a book on computer security to discuss his credentials with respect to computer security.

If I were to write this review, I'd probably say something like, "The material was far too detailed and complex. The author expects the casual reader to be intimately acquainted with Perl and assembler. Basic concepts were not explained. Stay away from this book unless you're a masochist."

But that's because my formal training is in physics, chemistry, and biology. Why shouldn't we expect a book to be reviewed by someone competent?

A short blurb about the author of a review (or other article where we would expect the author to be a specialist) is not uncommon in other media--though it is generally added by the editor, not the review author. Something like, "Bob Smith is a professor of Elvisology at Podunk University. He has studied techniques to clone dead rock stars from their hair for many years, and he is a regular contributor to the pages of Weekly World News."

Re:It's Kind of Sad...

[redragon]

Right...so I would agree with short blurbs about authors. No question there.

However, /. more often has statements like the former. Perhaps a rationale for why a particular person was selected for a review would be useful.

Lisp is a great tool

[Anonymous Coward]

Read Paul Graham's article Beating The Averages.

software isn't the problem

[mabu]

As a professional in the security business, I'm responsible for handling tens of thousands of financial transactions on a regular basis. My biggest fear regarding security has more to do with the bad habits my clients have than the integrity of the software I use. When it comes to security, having proprietary software can be advantageous in these situations, as there isn't general knowledge of the system's inner workings freely available.

But the biggest security problem was and likely always will be, people who have access to sensitive information that do not act responsibly. Our systems have never been compromised, but once we transmit information to the client, that data becomes a lot less secure, whether it's from a compromised client machine, a rogue employee or a badly-chosen password.

Re:software isn't the problem

[duffbeer703]

Your argument is akin to "x don't kill people, people kill people". It's a good argument, but it isn't what people want to hear.

Whether you are talking about cars, software or jungle gyms, engineers design things for sensible people.

The problem is that management want silver bullets and airtight systems and users want usability. Nobody really wins in the short term.

Re:software isn't the problem

[mabu]

I agree.

This is because we've turned into a race of people who prefer to ask "What?" or "Who?" instead of "Why?". We've been programmed to expect instant results and preemptive, pseudo-abstract ideas such as "a secure philosophy" don't seem to offer the instant gratification that blaming everything on the software does.

Exploiting people is a lot easier than exploiting hardware and software. Our entire economy is built around exploiting people, but the powers-that-be don't want this issue to be raised because if people become more aware of how their attitudes can empower their security, the powers-that-be wouldn't have much power.

Disappointing

[WryCoder]

Focused on Windows and commercial tools. I read part of the online chapter, which I found superficial. When I got to this

"Sharing buffers is somewhat like sharing food. A restaurant (hopefully) maintains strict rules about where raw meat can be placed. A little raw juice in someone s cooked meal could lead to illness and a lawsuit. A typical program has many buffers...."

I'm afraid I exited acroread in disgust.

Re:Disappointing

[m1chael]

So what you're saying is the food is in the computer? Oh I get it, I see... [pounds the computer]

Use better tools?

[Anonymous Coward]

Sure, by using a tool that is 5x slower you can avoid accidents, but that's stupid. If people would simply learn to use the fast tool more carefully, we'd be ok. Being forced to use training wheels to avoid accidents is insulting.

Re:Use better tools?

[Anonymous Coward]

It's only insulting if your ego is too big.
Personally, I'm glad there are tools out there than can help me to prevent fucking up. Because that's what I'm good at. Fucking up. Just like all the other humans out there. Even the ones who don't think they fuck up.

Re:Use better tools?

[Anonymous Coward]

It prevents fucking up because your code won't compile before you've worked on it for 5 hours, preventing you from switching to the next project prematurely.

In C, your code compiles after 1 hour. You should spend the following 4 hours to review it. If instead you jump to the next project right away, that's where you fuck up.

Bill Joy Has The Word

[rixstep]

I find Windows of absolutely no technical interest. They took systems designed for isolated desktop systems and put them on the net without thinking about evildoers, as our president would say.
- Bill Joy

I liked

[g0bshiTe]

Hacking: The Art of Exploitation
It provided these same thoughts on software design, but also delved into more the ASM side of things. The book went on to state that "there is no such thing as secure code." I believe this statement to be true. With the current patch n sniff state of Windows, it is very easy to overflow a buffer to execute code. I have oft heard someone say my pc is unhackable, I run blah firewall, or X N.A.T. the sad fact is they are as easy to compromise as an unsecured network pc is. With the plethora of IE and other browser vulnerabilities out there you don't need to drive a tank through the front door. Seems though Microsoft left a Window open.

Re:I liked

[maxwell demon]

"there is no such thing as secure code."

Hmmm ... I'm still seeking the vulnerability in the following implementation of /bin/true:

int main()
{
return 0;
}

Re:I liked

[g0bshiTe]

a simple patch changing the return value from 0 to 1 would suffice. Again could be done through any webbrowser or java.

Who modded this troll?

[Anonymous Coward]

Some boogers clearly appear in print in a few places in Gary McGraw's older books. Anyone can go to the library and check for themselves.

world's largest software company isn't msft...

[Anonymous Coward]

it's ibm, still after all these years.

Jon Erickson's "Hacking: The Art of Exploitation"

[porkrind]

As a slightly biased source of information (I work for the publisher, No Starch Press) I would recommend the above-mentioned title for those interested in software exploits. It's a great introduction to fundamental ways to exploit software. It may not have quotes from Schneier, but it's a great book. Check it out here: nostarch.com

The other half of the problem

[Brandybuck]

There's another side to the problem. It's insidious. And while Microsoft is fully embedded in this tar pit of insecurity, Open Source projects are rarely better.

This problem is "feature requests from users." If very few developers understand security well enough to write secure code, think about how much less end users know. Yet it is the end user who pays us. They're our ultimate boss, even on the free-beer Open Source side of things.

At work I've had feature requirements come to me from marketing that would absolutely eviscerate the product's security. I've also seen bug reports elevated to top priority that that would reduce or eliminate product security.

Here are some hypothetical (I hope) examples to show the dangers of this in the Open Source arena. While some of these might have been absurd a few years ago, with today's hyper-concern of usability, it wouldn't surprise me if they actually got implemented.

"It's too much work changing file permissions by hand, so we need a way to automatically execute arbitrary files."

"It's too much work remembering passwords, or remembering the master password for a password manager, so there needs to be a daemon running that will remember for us."

"Messages in XYZ email client should be automatically rendered in HTML/CSS/Javascript."

"The interface is too cluttered! Hide file name extensions!"

Or my all time favorite...

"Linux needs a InstallShield clone!"

Re:The other half of the problem

[johnnyb]

"The interface is too cluttered! Hide file name extensions!"

A little OT rant - file extensions are a horrid beast which should never have been allowed to surface. The MacOS method is much better. In fact, computer designers really need to rethink metadata handling from the ground up. I did a short thinking exercise on this here:

http://www.eskimo.com/~johnnyb/computers/MetaInfor mation.html

Re:The other half of the problem

[johnnyb]

Don't follow my link -

Previous link is cut off. Most of the useful info is gone. I'll try to find a backup copy and repost.

Re:The problem starts with the programmers...

[lelitsch]

I don't know why this got voted insightful, but you are making a very good point, although involuntarily:
"Security WON'T work until software engineers and programmers get it into their heads that complicated, invasive security procedures don't work if there are any humans around."

If the security procedures are transparent and easy to use from the user standpoint, they will expend and extraordinary amount of ingenuity and cunning to get around them. Usually more than any product designer can spend to develop the product in the first place. This doesn't only aply to software, but to everything else. If you put a different combilation lock on each filing cabinet (very secure), your office workers will tape a list to the bottom of one desk with all the combinations. If you put a different lock on every door, they'll duct tape over the bolts to keep them from engaging.

The same applies to software. Get over it and develop a protocol that doesn't hurt the user and is secure. It's hard, but not impossible.

Co34

[Anonymous Coward]

That they can Hold everything else as little overhead

Non-computer people just do not understand it

[Lucky Kevin]

Despite all the security flaws being found in software and all the fixes coming out constantly, the man in the street has no idea what we are talking about.

A few years ago I was designing a radio network protocol for an electricity distribution client to control their switches. I said that I was going to encrypt the information, they said "Why?" After explaining the problems they simply replied that they had their own cell phone network for the transmissions, no one would break into it and they weren't interested. I still encrypted it though!

Exploited already!!

[johnnyb]

I have an exploit:

rm -f /dev/null
touch /dev/null

Re:Exploited already!!

[Bombcar]

Ok, I'll use this one:

#!/bin/bash
rm $0 -f

But there is still a 'sploit for this one, too.

The System I Want

[bill_mcgonigle]

Anyone know if this exists?

I want support in a high-level language for a construct like:

[Integer] function doSomething (
[integer var1]
[Foo var2]
[XML::Some::Schema var3]
[optional Baz var4] throws IVException {

where the language declaritively specifies what it's going to get for input, validates that input, and causes a catchable exception if it doesn't. Input validation isn't hard, but it's really tedious, which is why people don't do it. The language is supposed to take care of easy tedious stuff for you.

Re:The System I Want

[Frizzle Fry]

It sounds like you are looking for contract programming. The specification of the input is the "contract" that the function enforces. I have done no contract programming, so that description might not be completely accurate; you should research yourself for more info. The poster boy for this school of design is the language Eiffel.

Re:The System I Want

[bill_mcgonigle]

Thanks, I'll check it out. A crowd of Eiffel fanatics at WWDC freaked me out once (they had a hunger strike against Metrowerks or something) and it scared me away. :)

automated tools

[foxyLady]

what about static/dynamic analysis techniques/tools?

Bruce Schneier is one of the good guys

[Paul Crowley]

If you think that's the foundation of Schneier's career you've not looked at his academic publications. He was a seriously high-powered cryptographer and cryptanalyst in his own right long before he got into writing for a popular audience.

And when he does write for a popular audience, he does an invaluable job getting home the ideas that people seem to miss when they're thinking about this stuff. Some of the ideas he promotes are far from truisms, such as for example his campaign to get insurance companies involved the computer security business in the hope that he can change the economics of the situation to favour better security.

Applied Cryptography was the right book at the right time; the most important thing about it was simply the message that this stuff was no longer secret and anyone could read about it. At the time it was written this stuff was not available on the Net; it was compiled from academic papers that weren't generally available for download.

(Disclosure/bona fides: I know him to talk to from crypto conferences and I once broke one of his ciphers (Solitaire))

Re:Bruce Schneier is one of the good guys

[GPLDAN]

I know he was a mathematician and cryptographer. And some of the stuff in Applied Cryptography was only to be found in journals, although some of it was on the net. And I know the State Department didn't like him doing that, he says so in his book.

But his books for the general public, well, just perform this test. Pick up a copy of Beyond Fear at the bookstore. Open it to a random page. Read a paragraph aloud to a friend. See if the friend says "hmmm" or "duh". I'm going to bet on the latter. Several review of the book have stated what I felt, it's more of the same. If you read Secrets and Lies, there was nothing new there.

Just my opinion.