Building Secure Software

greg pryzby writes: "A friend has been pushing me to read a number of technical books lately. After reading Building Secure Software: How to Avoid Security Problems the Right Way (BSS:HtASPtRW), I decided I needed to spread the word." Read on below for Greg's word on this one. Building Secure Software: How to Avoid Security Problems the Right Way author John Viega, Gary McGraw pages 528 publisher Addison-Wesley rating 8.5 reviewer greg pryzby ISBN 0201-72152-X summary Good information for anyone involved with the creation of software which should be secure.

BSS:HtASPtRW should be available at your favorite book outlet. It is available in hard cover from Addison-Wesley Professional Computing Series (white cover with blue strip). Since it is a security book, the forward is by Bruce Schneier and displayed on the cover. When you open the book, there are three pages of "Advanced Praise" for the book. So, the stage is set and the expectations are high. Will the book live up to the hype? I thought so.

Who should read the book? Anyone who cares about security. There is information for the manager, coder and everyone in between. Throughout the book, there are plenty of examples which I found very useful. John and Gary use code to show th at what they are talking about is not 'just theory'. That is right, there is code that shows the problems. That means samples of bad code, 'secure' code and code to show exploits.

I decided to look at a few chapters and talk about them specifically. Why did I pick these chapters? Because I found them interesting and thought others would too. I can't cover each chapter because I want John and Gary to write more books , so they need to sell a few copies!

Why do they do this? Isn't this giving the bad guys what they need? The bad guys have the information already. There is belief in the security community of full disclosure. This means not keeping things security and calling it secure. "Full disclosure means that hackers publicly disseminate information about your security problem, usually including a program that can be used to exploit it (sometimes even remotely)." (page 81)

Chapter 7 is on buffer overflows. I have read about buffer overflows for years. The chapter starts by explaining what a buffer overflow is and why it is a problem (pointy headed manager stuff). At this point John and Gary talk about how to protect yourself from buffer overflows. They start by listing problems in C and show why it is a problem. A list of functions that are 'bad' are given, but as any list, this isn't comprehensive. While avoiding the list is a good idea, you need to read why the calls are a problem so you can think about any call you use and why there maybe a buffer overflow.

The chapter then turns very technical. The difference between a heap and stack o verflow is discussed. An example is given that takes a C program and shows how to smash the heap and then how to smash the stack. This is pretty technical stuff , but very interesting. Finally an exploit is given. Very informative.

Chapter 9 is on race conditions. Time-of-check, Time-of-use (TOCTOU) is used to demonstrate a race condition. There is discussion on what a race condition is. John and Gary again step through code that is vulnerable and explain why it is vulnerable. Of course they show you how to write the code securely.

Chapter 10 is on randomness and determinism and lives up the the others. I know that random() isn't really random, is a pseudo-random number generator and should not be used when you need a real randomness. John and Gary give a great example to show how an online gambling poker application was open to cheating. Using some math and educated guessing, a GUI was written that would show you everyone's hand and how to win.

The next part of the chapter talks about how to generate randomness via software and hardware solutions. A discussion on entropy and how to determine the amount of entropy from the random source is given. Things get technical (I think), but you can follow the details or skim them. Regardless of how you decide to read this section, you will walk away with a better understanding of the problem.

I hope from the chapters I discuss, your curiosity has been peaked and you pick up a copy. There is other interesting stuff, like the 10 guiding principles for software security.

Web Resources
The web site recently was overhauled. The code from the book is there as well are web resources. It is worth it to take a look at the web site for more information and to get a feel for the information the book covers.

Contents
Foreword
Preface
Acknowledgments

1. Introduction to Software Security
2. Managing Software Security Risk
3. Selecting Technologies
4. On Open Source and Closed Source
5. Guiding Principles for Software Security
6. Auditing Software
7. Buffer Overflows
8. Access Control
9. Race Conditions
10. Randomness and Determination
11. Applying Cryptography
12. Trust Management and Input Validation
13. Password Authentication
14. Database Security
15. Client-side Security
16. Through the Firewall

Appendix A. Cryptography Basics
References
Index

You can purchase Building Secure Software from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Comments

Local Shop for Local People

[Anonymous Coward]

THERE'S NOTHING FOR YOU HERE!!!!! I can I can't! You are not logged in. You can login now using the convenient form below, or Create an Account. Posts without proper registration are posted as Anonymous Coward

Re:Local Shop for Local People

[Anonymous Coward]

Edward?

Re:Local Shop for Local People

[Anonymous Coward]

Tubbs!! (Alles Klar Kinder)

*runs to post office*

[RinkSpringer]

I'll send a copy to Microsoft... let's hope they abide it :D

Re:*runs to post office*

[jeff67]

One copy? How about a truckload???

Re:*runs to post office*

[9632]

To late. February is over.

Re:*runs to post office*

[sharkey]

I doubt it. They won't even read their OWN guidelines:

The Windows User Interface Guidelines for Software Design, Microsoft Press.

Quote from book: "consistency makes the interface familiar and predictable".

Referenced from the Interface Hall of Shame.

Re:*runs to post office*

[andcal]

Apparently, you didn't see the article a while back on Writing secure Code from MSPress

Those who have looked at the book seem to come to the conclusion that the knowledge necessary for writing secure code must apparently exist at Redmond, but something besides the total lack of knowledge is what is driving security problems there.

Re:*runs to post office*

[Anonymous Coward]

The security audit is still going on and may continue for all of march.

Re:*runs to post office*

[Anonymous Coward]

Ohhhh March....what happens after that mr. Anonymous coward from redmond.

FIRST POST YEAH

[Anonymous Coward]

Ihhhhhhhhhhhhhhh TOO CLOSE!!!!

Trolling is Dying

[Anonymous Coward]

!=fp!

For security:

[Anonymous Coward]

This is the resource.

Random Numbers

[Joel Ironstone]

There should be a byte available on each chip (or memory cell) that samples thermal noise in some way. This, as I see it, is the only way to get uncorrelated noise. The other systems use iterating functions and take advantage of chaos to produce 'unpredictable' but certainly not random sequences. Know the iterating function and the last result to the precision it is stored in the iterating function- know the next number in the sequence.

Re:Random Numbers

[swagr]

Know the iterating function and the last result to the precision it is stored in the iterating function- know the next number in the sequence.

This can be very hard to determine. Here is a random number generator with period 2^19937-1. Presumably it could be modified to support a larger period.

Re:Random Numbers

[bgeiger]

The most common random-noise collection method in use is measuring the time between keystrokes. It doesn't require any additional hardware (except a keyboard ;-) and is fairly random.

PGP/GnuPG use this method, and if I'm not mistaken, so does the Linux kernel (to feed /dev/(u)random).

Re:Random Numbers

[CrazyBrett]

Interesting idea, but somehow I think it would still be too predictable. Taking the principle even further, they should have multiple sensors that measure thermal noise, sound variations, RF signals, power fluctuations, light levels, and humidity. Then combine all that data with a big old hash function, and you'll probably get as close to "random" data as one could hope for in this distinctly un-random world.

Re:Random Numbers

[wangi]

The most common random-noise collection method in use is measuring the time between keystrokes. It doesn't require any additional hardware (except a keyboard ;-) and is fairly random. PGP/GnuPG use this method, and if I'm not mistaken, so does the Linux kernel (to feed /dev/(u)random).

I have a hard time believing this... You're seriously implying that Linux servers (no keyboard) have an inferior /dev/urandom?

Re:Random Numbers

[Fuzion]

Don't the Intel CPUs have some feature like this? I remember them advertising a while ago that they can generate true random numbers for power dissipation on resistors or something like that. I'm not very familiar with this, and am just recalling something I heard a while ago.

If all CPUs implemented something similar then can true random numbers be obtained from that?

Re:Random Numbers

[Tom7]

> I have a hard time believing this... You're
> seriously implying that Linux servers (no
> keyboard) have an inferior /dev/urandom?

That's true, actually. Check out /usr/src/linux/drivers/char/random.c.

/dev/urandom uses all sorts of hardware timings (like incoming packets, hard drive seeks, etc.) to produce add entropy to its pool. Typing or moving the mouse improves this, though I think "inferior" might be too strong a word since they are both nearly unpredictable anyway.

Re:Random Numbers

[mikeage]

The original Pentiums has the ability to do this... it was involked by the FPU, and basically took an integer and returned a float that was offset by approximetly 1E-10, IIRC ;)

Re:Random Numbers

[Anonymous Coward]

Yes, they do--kind of. The entropy pool in linux is seeded by block device access, keyboard/mouse interrupts, and potentially network activity. The latter is generally off by default and isn't supported by all network cards.

This can in fact be a problem for embedded systems that don't have keyboard/mouse and don't have hard drives. In many of these systems, network traffic is the only source of entropy available. There was a big discussion of this on the linux kernel mailing list some time back (last year I think).

Some systems have hardware entropy generators which can be used to get around the need for these entropy sources, but most don't.

Re:Random Numbers

[Yvanhoe]

I have a friend who implemented some cryptographic stuff
in his youg days. As a true random numbers generator he
used white noise from the line imput of a sound card.
It looks like quite unpredictable.

Re:Random Numbers

[PurpleFloyd]

Then combine all that data with a big old hash function, and you'll probably get as close to "random" data as one could hope for in this distinctly un-random world.

This world is incredibly random. While things may seem predictable on the human scale, that tends to disintegrate as you go smaller and smaller. Things like Brownian motion (the more or less arbitrary "vibrating" motion of heated particles) are very random.

You will probably come back with some retort about chaos theory and the formation of patterns, so let me tell you what's wrong with that idea right now: Chaos theory does say that in many cases, "random" data will form identifiable patterns. However, often those patterns are not distinct over a small sample. Even given a few million numbers from a sophisticated random number generator, you would be hard-pressed to come up with a pattern in them - even using incredible amounts of computing power. This is why the NSA was so scared of things like PGP a few years back (and still are!). In short, the world is definately not "un-random", especially in very small domains -- such as those microprocessors operate in.

Re:Random Numbers

[Anonymous Coward]

This is one of the things I liked about the old 8-bit Atari computers. One of their custom chips, Pokey, has a hardware random number generator (used for adding noise to sound). It may not have a very large period, but it interates on every clock cycle from the moment it's powered on--1.7 million times per second! So given any kind of delays in running a program--like hardware interrupts, I/O, or waiting for the user--the values read from Pokey's random number register could be considered almost truly random.

Microsoft == Secure Software

[DonkeyHote]

It looks like microsoft finally got it right with thier latest OS, WindowsXP. It's security is what Gibson of grc.com would say is "Nano-securo-tastic".
I applaud thier great innovation and vision. Its too bad Linux won't ever be this good...

Comments from author

[viega]

I'm one of the authors of Building Secure Software. First, thanks for the flattering review. We certainly worked hard on the book for a long time, and believe that we've produced something that's very useful for anybody involved in the development process. That having been said, I would like to let you all know the shortcomings I see, even though they are all fairly minor: 1) The book hasn't really seen any substantial discounts, as far as I know. Being a 400 page hardcover book, it's somewhat expensive to begin with, and I'm sure some people won't buy it just for that reason. We've requested that the next printing be done in soft cover, but I don't think that's going to happen, unfortunately. 2) New books always have tons of little problems with them. Several unfortunate things have been noticed already. Most unfortunately, there were a few outdated or inaccurate statements on MS technologies. All of the problems we've found so far will be fixed in the next printing, which should be pretty soon. However, if you notice a problem, and don't see it on the web site's errata, send us e-mail. 3) The topic area is moving pretty rapidly. We essentially finished the text minus edits in February, 2001. Since then, there have been some new things come up the pike it would have been nice to discuss. Over time, we'll update the book's web site with articles that are interesting supplemental reading. All in all, I hope that people get a lot out of the book, and that it does well enough that we'll have the opportunity to do a second edition at some point to make the book even better.

Re:Comments from author

[Anonymous Coward]

Look, i'm all about security and that junk, but i think you need more color pictures. Pretty ones. Thanks.

Re:Comments from author

[wangi]

The book hasn't really seen any substantial discounts, as far as I know

Just a heads-up for folk in the UK looking to buy this book - it-minds.com are doing it for £37.99, 10% off of list price. I think you have to go in via theregister.co.uk

amazon.co.uk have got it for £41.99

Re:Comments from author

[richardbowers]

1) The book hasn't really seen any substantial discounts, as far as I know. Being a 400 page hardcover book, it's somewhat expensive to begin with, and I'm sure some people won't buy it just for that reason. We've requested that the next printing be done in soft cover, but I don't think that's going to happen, unfortunately

It's on for a 15% discount at Readme.Doc right now.

Just close source it

[Anonymous Coward]

Closed source software such as Microsoft is the best way to secure your software. You will have full control of it not thousands of people. Whenever an exploit is found, you simply fix it at your leisure.

Sorry - I've been busy...

[LunchLady]

I haven't been able to troll you fag slashdot readers for a few days now...so here's a taste of what's to come...

* g i v e r * g i v e r * * g i v e r * g i v e r * * g i v e r * g i v g::===....111111..=.............111111.111.88M.X88 X0088;8%8/%%80000++%%e
i::==........111111. .. .. .. 1.......1..188X:800000080+++888%%00008+++r
v:=....11......111111111111..111.1.11...=8X:.88880 088X/0M88%00800088+++*
e.....11111111111111111111..1...1......=X0M0888800 808/8888+800080000%%%g
r:=....111.1..1...................=====X0M%XX80088 80XX88X80000000808X%Xi
*:====...1.1111..1.1..............====88X+88888808 0X:80X880000000008888v
g===.1.1111111111111111..1.1........188X%X88888088 088000080000008008888e
i==......1....111...1..1.........== %8X 88X88888080X88XM000000000X0XX88r
v=.....11.1111.111111.....111....1 /X8 :0X88888088.M1=XX000000000;0XX80*
e.=.11111111111..1111...=........1;88./888888008:. .//18XXX8000000:0X880g
r=1=..11111111.111.==.1..===:::=./X8:%8XX8888X;:;/ %%80X8X88800000+XX800i
*.....11111..=::=..1111........1.8+=88XXX88%1.=;:: = :8.088XX0000X+0888:v
g;;:=1111..111111111.11.11......8==8XXXX81/...;;=: :..18X08888000:;088/8e
i:==111111111.111........1....1: ;0XXX88::/.;::=.==.+.80X8XXX8880088:%Xr
v.11111.11.11.1.111111111...1.. =0X88888:=:.=.=;::==1188XXXX8888008=+X8*
e.11111111.1111..1..1.1=:...=. =X0=800800/:://+%%X00/;X8XX888X80808/XX%g
r.=1...111111111111.==...==== .8:;888X88800008888880;%80XX88800000X888%i
*..==..1..1111.1111..=.....1 ;0=+X8X8X8888888888888+.8XXXX880%++++%%888v
g=: .=:...===.....1.1..1... ;0:X8XX888XXX88888888801=XXXX0888%%%8+++/+Xe
i. 1;%88/==..1.==:::=..1..18;;08888888X8XX88XX81.=;1. XX88888;:.1 %0000r
v =+88X88%=.1.1111111111..X0//888888//=::=:;: ..1=;=/X8X88881;++XM80800*
e=%XXX88X88/......1......8 +8+//;=====..=::...1.1.:/XXXX88008;+X00XM088g
r%XX88888888+=1.===.11..+:;.1.:+%8;.1.=:;:::::..11 .88X1+88000%;; 8M000i
*X888XXXXXXX8%:=..==.111=;;++8XXX881=;+++++8%. .11%=..11X8888+; 8M000v
gXX88XXXXXXXX88: .:.:+XX8XXXXXX8XX+888X888+ .. ..;=:/++008; %M000e
i8X888XXXXX8XXX8+/;X8X8XXXXXX88XXX88888X8X%. ......1=/++/8% %0800r
v88888XXXXXXXXXXX%X888XX8XX888X88X888X8/:;1 .1111. .=%%%XX8 +0000*
eXX8M888XXXXXXXXXX8=;:;+X88X8+:1.11.. 1 .:: ..111...=/8XXXXX %000Mg
rX8800888XXXXXXXX8X8+;:=;/:..1.=;::.:=..+88.1 ....111.1=/%X8XXXX= %000Mi
*X8880+888XXXXXXX8XX: .. .+%%X8;:/8%818XXX1. 1=;:==;+8XXXXX8X 80080v
g88888 08XXXXXXXXXXX8;..:/8%;:+//%88X;8XXXX ...:+88;;+%XXXXXXX8.X8000e
i88880+X08XXXXXXXXX8: =%8;/;+8XXXX888XX8XX;. ./%+%8XX%+%8XXXXXX888X8000r
v888008%8XXXXXXXXXX/./8X+/8X8XXXXXX88X80888X8:;88X XXX8+%8XXXXXX8/0X8000*
e8888X%%X88XXXXXX8X18X8+88XXX88X8880000088888X88XX XX80;+XXXXXX8;8MXX000g
r8000%%%%88XXXXXX8.XX%+X8888000888XXXXXXXXXXX88XXX X880=:8XXXXX;;X.8X000i
*8888X0080XXXXXXX+;88%88888088888XXX%%%%%X888888XX XX8;=+XXXXXX% .:8X008v
g0MM00808888XXXX8XX%/;XX880888X+..=;;;/%%;;888X8X8 X80.;88XXX88X 1;8X008e
i008+8000008X8=..=;:808X8088X+:=:;+%++%%%;::;+XXXX XX0.;8XXXX880 1;88000r
v08000000008X...:/;+8888088X+=;;:;/+//+%+//+%XXXXX 88%.;8XX88800 /88000*
e00000000000/=:+X/;88XX808X8/.;/;;;/+++%+++%8XXXXX X81./8XX88800 /8X008g
r80000000000.;+X8X%X8X88X8%. .;++++%%88888XXXXXXX8801.+88X8X800 /8X008i
*00000000000.+X8XXXXX88;/;1.1=;8888X8XXXXXXXXXXXX8 8+1/888888000 +8X000v
g00000000000:%888XXX81..=;::;;+XXXXXXXXXXXXXXXX888 01.+XX8888000 +88000e
i00008000000%%88X8:.11.=;++/:;+%8XXXXXXXXXXXXXX888 0.;%888X80000 +88000r
v00000000000M88X=1.1=:;+%8X88%%%8X88XXXXXXX8888888 M=;+X88800008 /88000*
e0008000000000...=:;+8XXXXXX8%%8X8888888888888808# =;+X888000000 /88000g
r80000000000M...=;+%8XXXXXXXXX%%88X888888888000000 8.;8888800000: /88M00i
*000000088X=..=:/%XXX88XXXXXXX8888X88880000000000; ;/%88880000088 ;8X000v
g808X8800+1..:;+88XX888XXX888XX88XX8000000000001=: %%88888000000X :8X000e
i00000081..=;+%8X888888888888X8XXX800M00000801.::% X8888000000008 :88000r
v00000.1..:/%88X8888888XX888888XX88M000808881=:+80 88080000008000.:X8M08*
* g i v e r * g i v e r * * g i v e r * g i v e r * * g i v e r * g i v*
* g o a t s e x * g o a t s e x * g o a t s e x *
g88888888888888888888888888888888888888888888888g
o8/88888\8888888888888\888888888888/8888\8888888o
a|8888888|8888888888888\8888888888|888888|888888a
t|8888888`.8888888888888|888888888|8888888:88888t
s`88888888|8888888888888|88888888\|8888888|88888s
e8\8888888|8/8888888/88\\\888--__8\\8888888:8888e
x88\888888\/888_--~~8888888888~--__|8\88888|8888x
*888\888888\_-~88888888888888888888~-_\8888|8888*
g0000\_00000\00000000_.--------.______\|000|0000g
o000000\00000\______//0_0___0_0(_(__>00\000|000 0o
a0000000\000.00C0___)00______0(_(____>00|00/000 0a
t0000000/\0|000C0____)/ \0(_____>00|_/00000t
s000000/0/\|000C_____) |00(___>000/00\0000s
e00000|000(000_C_____)\______/00//0_/0/00000\000e
x00000|0000\00|__000\\_________//0(__/0000000|00x
*0000|0\0000\____)000`----000--'0000000000000|00*
g0000|00\_0000000000___\ /_0000000000_/0|0g
o000|00000000000000/0000| |00\000000000000|o
a000|0000000000000|0000/ \00\00000000000|0a
t666|6666666666/6/6666| |66\66666666666|0t
s666|666666666/6/666666\__/\___/6666|6666666666|s
e66|66666666666/66666666| |6666666|666666666|e
x66|6666666666|666666666| |6666666|666666666|x
* g o a t s e x * g o a t s e x * g o a t s e x *

.NET by Microsoft is Alive! Linux is Dead.

Today you will all be briefed on why Microsoft and it's .NET platform are alive and well - and of course why Linux is dying, if not already dead.

Security and privacy are a central part of creating and delivering compelling user experiences. Distributing computing power across numerous systems-both inside and outside the walls of your home or company-creates new types of challenges.
This is one of many areas where Linux falls way short of Microsoft.

The Microsoft® .NET platform is built from the ground up with security in mind. While Linux is built from the ground up by a team of Hackers who don't really know what security is. This leads to administrators of Linux and other such 'free' software to be bogged down with silly configuration and security nightmares.

The .NET Framework, the programming engine at the heart of the .NET platform, provides the means to secure both client and server machines through its core security features. Developers can focus on application logic because security is handled transparently at the core level by the common language runtime. Yet developers can use and extend the security model at any time. As seen simply in Linux each developer must make up for the lack of security contained within the Linux kernel and system around it. This is why Linux is dying. Why would a corporation invest money in developing products for a childish operating system where security comes second?

By using the Internet to enable software applications to more easily work together, Microsoft® .NET promises easier integration within and between businesses, while creating opportunities to more meaningfully connect with consumers. Where is Linux? Where is it? I can't find it anywhere? Because it doesn't do this at all. Linux has a real problem with playing nice. You want to send this file across the country? Not with Linux...
With the tools of the .NET platform, businesses can realize improvements in the time and cost associated with developing and maintaining their business applications, as well as benefitting from empowering employees with the ability to act on vital information anywhere, from any smart device. I guess we are back to the point that no one developes software for Linux because it just doesn't get the job done when it comes to operability and usefulness.

As you all can see, it is pointless to continue this Linux project and you should all consider dropping your current Open Source projects. Leave the programming and application development to the following:

1. Professional who have been schooled in the ways of design and development.
2. Companies who have the resources to actually develiver secure and helpful solutions to the end user.
3. People who take showers.
4. People who do not enjoy looking at the Goatse Man.

The sooner you realize your errors the sooner you can begin to support and extend the knowledge of Microsoft.

Thank You.

The Twelve Steps, originated by Alcoholics Anonymous, now applied to Slashdot. This is the spritual foundation for personal recovery from the effects of Slashaholism, not only for the slashaholic, but also for their friends and family.

Many members of 12-step recovery programs have found that these steps were not merely a way to stop commenting, reading, and retardedly clicking on every link (including all those Goatse links you fags like), but they became a guide toward a new way of life.

Step 1: Honesty
After many years of denial, recovery can begin when with one simple admission of being powerless over CmdrTaco -- for Slashaholics and their friends and family. The Goatse man also owns you, so you should admit that too.

Step 2: Faith
Have faith in the fact that if you stop now - you will be saved. Not only saved but you will never ever have to read or hear about Jon Katz again. Well, I take that back - you will hear about him again, on a legitimate news site where you read that he was finally caught and convicted to the Goatse Man chamber for raping kids.

Step 3: Surrender
A lifetime of slashdot will destroy your soul. Keep in mind that Slashdot is worthless. It does you no good and it is hurting your family. Surrender to the temptation of posting a useful article to slashdot. Surrender to the temptation of even visiting this disease.

Step 4: Soul Searching
Search your soul - why did you first come to Slashdot? WHY? What is here for you? These people are not your friends. They are disgusting dirties that give a general smell to themselves and everyone around you. You all probably notice it when you go places at people look at you funny. It's because you smell like shit.

Step 5: Integrity
Integrity. Not much more needs to be said here. Of course to have integrity one must not smell, and one must have a positive self image. This is also to say - you cannot be the dirty hippie you want to be. So, stop praying to your sun crystals and take a shower.

Step 6: Acceptance
Accept that you will never visit the Slashdot site again. Katz wants you around because you are most likely 14 and he digs little kids.

Step 7: Humility
Practice some humility in your life. Know your place - it is not being a bottom rung goatse link follower at slashdot. The sooner you break the chains of slashdot the sooner you can raise yourself out of the gutter.

Step 8: Willingness
Making a list of those harmed before coming into recovery may sound simple. Becoming willing to actually make those amends is the difficult part. Think of what your parents think about you...are they proud of their dirty anti-shower homosexual hippie child? What about your friends - and not your imaginary friends you fuck hippies. The trees are not alive.

Step 9: Forgiveness
Making amends may seem like a bitter pill to swallow, but for those serious about recovery it can be great medicine for the spirit and soul. Once you have stopped visiting Slashdot - you should take the steps to appologize to your friends (not your imaginary friends, fags) and your family about what an ass you have been over the past X months/years at slashdot. Tell them you are sorry and you didn't know. Tell them you were sucked in my the Goatse Man's ass chamber.

Step 10: Maintenance
Nobody likes to admit to being wrong. But it is absolutely necessary to maintain spiritual progress in recovery. You've visited slashdot and actively engaged in the slashdot moderation system. While this makes you a complete flaming homosexual - there is still hope. You've done wrong in the past - let's make the future a brighter and better place, for everyone.

Step 11: Making Contact
Break the bonds of slashdot that hold you prisoner. You can simply GO OUTSIDE! You fuck hippies could probably use the fresh air - at least it would give your parents a chance to clear out the old smelly air within your room.

Step 12: Service
As a community service. Stop using the internet for at least 1 year. Why you ask? You do this because you have committed sins against the internet community by actively being a part of slashdot. This year off will give you time to reflect about what you have done and about who you have hurt. Also, keep in mind - by the time your year is up - there is no way in hell Slashdot will be online. For one, Jon Katz will surely have been found raping children in the slashdot offices which will destroy the company. If not Katz then the website will fail with it's to be introduced subscription services. Not only will the temptation of slashdot be gone - but the year off of the internet will give you a chance to meet real people - and actually make friends.

Follow these steps are your life will be rich and full.

You've been warned.

Re:Sorry - I've been busy...

[Anonymous Coward]

don't make me r0x0r you

Christmas present

[Mattygfunk]

I gave this book to Bill for Christmas. I'm not convinced he read it though.

Engineered in

[Uruk]

This type of book will no doubt help people write more secure applications, but security in larger projects still needs to be engineered in, rather than added on at a later date as a "feature".

For example, Freenet starts with the assumption that nodes on the network will sometimes be hostile to the network, and that they will fail without reason. That fundamental assumption makes their network stronger IMHO than it would have been if they started with a blue-sky look at the network and added code to prevent certain types of attacks.

Also, it seems to me that security in applications is probably something won by hard experience. I'm not even sure if it's possible for somebody whose been hacking for just 1 year to build a fundamentally secure application, but trying to learn never hurts. :)

Re:Engineered in

[viega]

Actually, that's the thesis of the first couple chapters of the book. We discuss how to incorporate security into the design process from the beginning.

Re:Engineered in

[dkleinsc]

For an example of the results of engineered in vs. added on security, examine Unix and Windows. Unix was from the start a networked multiuser system, and security was paramount. Windows on the other hand was based on DOS which was originally intended for single user non-networked PC's. The result? *nix community worried about a better firewall and password protection, and MS creating a department of 'Security Assurance' to tell customers their software is secure no matter what the truth is.

So yes, designing security in from the beginning is important.

Great Read

[tenman]

This book was a very good read technicly. However, it's dry and we had to strugle to get through it. I just wish Tolkien had written books about crypto and secure software. They would have been more interesting that way. In the end, I recomend Building Secure Software.

Re:Great Read

[tgv]

Tolkien did, and it's called: the Silmarillion.

Re:Great Read

[HiQ]

LOL. I tried to read that book years ago, and I'm still running around dazed & confused.

Re:Great Read

[adamy]

Try again. It is worth it. Once you get into it, you'll wish it were longer.

He Rewrote the stories about Turambar, Beren & Luthien, and Earendel at least 3 complete times. IMHO these are the most important stories. The versions in Unfinished Tales are the best but they are, um, unfinished.

We now return you to your regularly scheduled program

security vs. trade secret

[telstar]

While open-sourcing your project may help ensure that you're a bit more proactive in securing your applications, it also gives the keys to the castle to anybody that decides to find programming mistakes in your code. Closed-source projects, while simply hiding any potential security holes, really does add an additional layer of protection, albeit a very thin one. But the issue of open-source vs. closed source as it relates to security is an entirely different argument of open-source vs. closed source as it relates to a company's right to keep trade secrets as just that. It's my opinion that if a company writes some code that they don't want shared, then they've got every right to keep it that way.

Re:security vs. trade secret

[Anonymous Coward]

You have obviously never used a dis-assembler, or a debugger. Once you use either for a while you quickly notice the patterns in the code (without dwelling on the specifics) and find areas of interest very quickly.

People do not realize how easy it is to make changes to a program, or gleam its purpose/implementation from views of such code fragments.

The average copy protected game is hacked to undo the copy rotection in less than 2 days. Even if it is a new copy protection method.

Re:security vs. trade secret

[telstar]

I have ... that's why I said it's a thin layer. But if all it took to get to the guts of a program was a disassembler and a debugger, then everybody here wouldn't be so hell bent on getting Microsoft to open-source Windows and all of their APIs.

Oh, and your "stat" about the average copy protected game being hacked in less than 2 days ... I agree that it happens extremely quickly (usually before the game hits the shelves), but picking numbers out of the sky doesn't help an argument much.

LOL!

[Anonymous Coward]

Gary McGraw is a former MS employee from the mid-80s. He helped to design their first security protocols for port administration.

Re:LOL!

[viega]

Nice FUD, but untrue. Gary got his PhD under Doug Hofstadter, then went directly to the company that is now Cigital.

Re:LOL!

[Anonymous Coward]

Cigital is a company who is majority controlled by MS. 'Gary', if that is his true name, has a PHD from the University of San Carlos. T

he PHD, which was purchased for less than 200 US Dollars, is in Business CS, and his first job was at MS where he worked for five years as a contractor to Cigital before being brought on full time to their staff (about the same time MS bought majority share in the stock)

Thus, the poster who you claim was FUDing was actually right. Do your research!

Re:LOL!

[bob_clippy]

Was 'Gary' the one who came up with the '80s marketing campaign "Cigital has it now"?

Re:LOL!

[gemcigital]

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

Re:LOL!

[quigonn]

Hofstadter? The "G*del, Escher, Bach" Hofstadter?

Your book would be even better if....

[DonkeyHote]

You had gone into greated detail about the Linux Gay Conspiracy and the Homosexual tendancies of the Slasbot janitors.

Just my Six Sents

Secure Programming for Linux and Unix HOWTO

[geirt]

My favorite:

http://www.dwheeler.com/secure-programs/

Re:Secure Programming for Linux and Unix HOWTO

[viega]

This is indeed a good document. The best thing about it is that it's online, and therefore it can keep up with new things better than a print book. Our book tends to go a lot deeper in general, though. In particular, David's has little to no code.

Hey you two!

[DonkeyHote]

Take your gay-linux bath-house shenanigans elsewhere.

Don't forget to send one to Linus as well

[DonkeyHote]

Gay fucking anti-ms slash-holes. You wouldn't know a suprior OS if it fucked you in the ass.

Security is very important in today's software

[Semi_War]

I'm teaching programming in a college in holland, and we have a nice course here to write a "simple" IntToStr. The outcome is so suprising, nobody thinks about simple things like:

-Minus not followed by digit
-several minus signs after each other
-minus preceded by a digit

It goes to show, it is easy to catch the under/overflows (and even that doesn't happen all to often) but writing good software is hard. This book is definitly going to be on my teachers wish list for this year.

Re:Security is very important in today's software

[GGardner]

Do you mean StrToInt?

If so, I'm always surprised at how many people miss the common case of correctly parsing the most negative integer.

Praise grid for libraries, in this case.

Re:Security is very important in today's software

[Semi_War]

Indeed, Libraries are a good alternative, and yes I did mean StrToInt. The fun part of this whole exercise was that we had a test-program that would test these function on various conditions - (underflow, overflow, bounderies, syntax errors). I can't remember if we actually tested the library StrToInt. But sometimes we lay to much faith in libraries, and i guess that's the bigest security risk of all. That's probably the reason why so many programmers say: If you want to have good software you'll have to write it yourself... Although i must agree that OpenSource is the best step in making software bug-proof. I remain sceptic on the question if OpenSource is actually hack-proof.

Re:Security is very important in today's software

[Arandir]

You have a WHOLE course just to write a StrToInt function?!?

Security is like Online Gaming.

[Anonymous Coward]

No, really. Software for both has to be designed from the *start* with certain ideas at hand.

For security? Everyone and everything around you is a hax0r. Games? Everyone and everything around you cheats.

Look at a game like EverQuest. Are their cheaters? Certainly. Are nintey nine percent of the subscribers to EQ affected by them? Nope. The reason being, EQ realizes that to remain 'cheat free', it has to look at every aspect at the game that the design team proposes, and sit their thinking of ways that people might try to take advantage of and cheat with them.

Other games don't do this. The Diablo series, with duping/etc. Phantasy Star Online, with duping/illegal player killing/corruption of characters/etc. Half-Life and its mods, with spiked models/etc.

The result? Games which believe the player is guilty until proven innocent tend to remain, for the most part, cheat free. Those which don't end up ridden with so many cheaters that the game then becomes unplayable.

Security is the same way. If you think, "No one will do that." with your program, you've already lost. Because, in the end, someone will, just to be an ass.

As has been said quite a few times before, security isn't an option. It's not something that can be added as an afterthought. It's a vital part of the design process, and cannot be left out.

Software isn't the United States - remember, it's okay to design with the thought that all your users are malicious.

Re:Security is like Online Gaming.

[Inexile2002]

I can't help but agree. Where I work, one of the senior developers' creed is: trust the user. Every time he says this, I think of my next performance review and getting comments like "Good work on finding those bugs by the way." The simple rule should always be: You are not the user, so design it for morons and maniacs.

Re:Security is like Online Gaming.

[Geeky]

Like online gaming.. and slashdot.

Many changes to the mod system are rejected because of the possibility for abuse (see the FAQ). Not to say it's perfect as it is, of course.

Re:Security is like Online Gaming.

[Zathrus]

The funny thing is, EQ wasn't designed with security in mind. Yes, they had some vague concept of "don't trust the client", but in fact most of their security was on the presumption that their byte stream wouldn't be hacked.

Well, it was. And so came ShowEQ. And much of the world that was supposed to be "hidden" isn't. ShowEQ gives a tremendous advantage, if only to show things like bugged monsters that won't path back to their home properly and will continue to interfere with pulls. More shady people use it to check on mob spawns in a zone. All of this is possible because during the design of EQ they chose to send the client information on EVERYTHING in the zone instead of just an area near you (this is also why EQ is broken into zones in the first place, and is largely an artifact of EQ's MUD origins and how old it is now).

They've gotten smarter though. They stopped sending the monster's hp's as a signed short and started sending it as a percentage (this also allowed them to exceed 32767 hp on monsters). They stopped sending the actual number associated with faction (-2000 to +2000) and started sending a number indicating level (0 = worst, 7 = best). Numerous other silly things like this, which should never have been in the datastream to the client in the first place, have been fixed.

Of course, there's still the gaping holes of spdat.eff (the Spell Data Effect file - lists every spell in the game and their effects), the fact that they send full item data over the wire when you inspect an item (including undisclosed stuff like haste percentage), they still send mana available for spell casters over the wire, and several other things.

The mantra of network game programming - don't trust the client - should be a mantra for most coding if you want it to be secure. And while you can attempt to patch crap afterwards, if you don't design it in from the start you will wind up with security holes that are too expensive to fix.

Slashdot == Major Disseminator of FUD

[DonkeyHote]

And this is why slashdot is DOOMED

Like the dodo bird, it will go the way of the Linux OS and many other failed freaks of nature

;) [lameness filter text]

[Scoria]

I'm sure that this book will be most helpful. After all, who better to learn from than the staple of application security?

Re:;) [lameness filter text]

[Anonymous Coward]

It must be good. All three "anonymous developers" gave it 5 stars.

Seminar By Author

[Proaxiom]

I find this interesting because I was planning on attending a seminar in a couple of weeks by Gary McGraw, one of the book's authors.

It's hosted by the Centre For Applied Cryptography Research (CACR) at the University of Waterloo. Anyone in southern Ontario who liked the book might consider attending.

Info:
Building Secure Software: How to Avoid Security Problems the Right Way
Gary McGraw, Cigital
Mar 20 (Wednesday), 2:30 pm, DC 1302

It's great that people are writing books like this

[fruey]

If only the right people would read them

Security is like...... well.... Security

[DonkeyHote]

Ok did we really need ONE more brain-dead analogy of how security is like something else? couldn't we have survived the day without having you regurgitate a half-baked idea into the already overflowing trash-dot cesspool?

I for one don't need another psuedo-intellect AC grandstanding.

Oh, and Security is like well.... babyproofing a house.

RWD 2002

Re:Security is like...... well.... Security

[Anonymous Coward]

Security is like ... a stream of bat's piss. It shines out like a shaft 'o gold, when all around is darkness.

Security is a process

[stevey]

Its a well known fact that security is a process, it should be considered right from the word go, and not just prior to a software release.

I've been writing a network server, recently, for streaming MP3's, so I been thinking a lot about the various issues.

I came up with a list of things that I should be doing, partly after reading bugtrack, and partly due to things I've picked up over the years.

I think its good to see books like this come out - if only to educate the newer/younger programmers who've never though about the issues before. After all many programmers just work on applications which aren't installed setuid, etc, so when they have to work on such a beast, for the first time, they're likely to work the way that they always have.

I believe that all the programmer courses available should have a section on security - largely because too many people learn from code printing in books, or online, which has all the error checking omitted, so the user can focus on the example. Its obvious from reading many peoples code that they never expect a malloc to fail!

LOL? So What?

[DonkeyHote]

MS who controls Cigital is controlled by the New World Order and Legions of Nasty Unwashed Jews.

One Jew to Lead them all
One Jew to bind them
One jew to....

All ye beware of the master jew who controls all other jews, the Goatse man, Beware!

BSS:HtASPtRW

[Pentagon13]

This author of this article should have posted this review under the Worst Acronyms headline from a few days ago.

Won't work for MS

[Anonymous Coward]

Why would MS want to produce secure and stable software? It would not be wise for them financially to release an OS or any other product that has the security and stability of BSD or linux. If Win95 didn't BSOD every other minute, then it would still be the standard. Instead we get PokemonXP which has about 10 GB of integrated crap that no one wants.

Truely Random Numbers from Intel

[ka9dgx]

Yes, the 810 (and later) series chip sets include a hardware random number generator, based on thermal noise. They have done quite a few things to make sure that it holds up well as a good source of randomness. Intel has a FAQ on the hardware, and how to use it.

--Mike--

Re:Truely Random Numbers from Intel

[anonymous_wombat]

I read the white paper by the designers of this chip; it sounded like these guys really knew what they were doing. We are a Solaris shop, but will probably write a program to generate random numbers using the Intel chip, and read that over a socket. You could also write the random numbers to CD-ROM.

Before you write another review...

[Anonymous Coward]

...please finish your high school English class.

Speaking of rand() [OT]

[Lancer]

Perhaps someone could point me to an answer on this very strang problem I've got with rand().

I'm taking an Intro to C++ course, and the assignment is to roll two dice, add the results, and keep track of the frequency of each result from 2-12. Easy right?

I've got a function called roll() that returns (rand()%6)+1, and then in main I have a loop that does "results[roll()+roll()]++" 36000 times.

Pretty straight forward program, and works as expected compiling under Metrowerks on Windows and gcc on a Linux box, but under cygnus (egcs 2.91.57) all of the results are odd. In other words, only 3,5,7,9,11 have any results, the evens are completely skipped.

Added in some cout's to see what was happening, and the roll()'s were alternating, without fail, between even and odd results - all numbers 1-6 were present, but they marched lockstep even-odd.

Presuming there was a problem in cygnus' implementation somewhere, the instructor proceeded to try it on a BSD box (with a later gcc - 2.95, I believe) with exactly the same result.

Searching on google proved fruitless (I was crushed!) - anyone know where I could get more info on this?

Re:Speaking of rand() [OT]

[Anonymous Coward]

Some rand() implementations are, well, utter crap.

http://www.samag.com/documents/s=1281/sam0104000 2/

Basically, the LSB has a period of 2, the second LSB has a period of 4, 3rd is 8. It becomes a little better with the more significant bits, but the function still only has a period of 2^15.

use random() instead, and be sure to seed the value.

Re:Speaking of rand() [OT]

[Anonymous Coward]

uhm I think its because of this

(rand()%6)+1

isnt that working out the modulus? which will always be an odd number by definition (if its even then there is no modulus and the whole statment fails) so by adding one you always produce an even number.

can u just declare it as type int? i dont really do much c++ so can't help with a solution..sorry

pkm

Re:Speaking of rand() [OT]

[ccoakley]

Not surprising. Many implementations of rand() return even, then odd, then even, then odd, etc. That is why you should never do rand()%2 for a random bool. It is better to use something like rand()&32&lt&lt5. Anyway, even+odd=odd, so your problem would fit that pattern. Mod 6 and + 1 won't change that (Mod 6 preserves parity and + 1 just swaps parity between your two rolls). Look in Knuth for some better random number generators that don't have such restrictions. For dice rolling, there is a really convenient one that just XORs two bits in a number and shifts everything to the right replacing the leftmost bit with the XOR result. It's extremely easy to code, but I don't have my copy of Knuth at work right now.

Re:Speaking of rand() [OT]

[Anonymous Coward]

"There is a really convenient one that just XORs two bits in a number and shifts everything to the right replacing the leftmost bit with the XOR result."

I use this one for PicPuter.com, and it works better than one would expect. The only modification i made is to XOR the new bit with the bit 0 of a timer that increments evey couple of asm opcodes.

Re:Speaking of rand() [OT]

[Joel Ironstone]

you can xor all the bits sequentually and get a repeating string of 1's and 0's 2^15 in period

Re:Speaking of rand() [OT]

[gweihir]

From the manpage under linux:

The versions of rand() and srand() in the Linux C Library
use the same random number generator as random() and sran
dom(), so the lower-order bits should be as random as the
higher-order bits. However, on older rand() implementa
tions, the lower-order bits are much less random than the
higher-order bits.

I saw an older manpage of rand() years ago, where they explicitely stated that the lowest bit would alternate and recommended only to use the high bits.

For a good PRNG check out the Mersenne-Twister

Re:Speaking of rand() [OT]

[StarDrifter]

The C rand() function has very few requirements imposed on it. Implementations that alternate odd, even, odd, even, ... used to be very common, and there are still some around. This behavior is allowed by the standard. So, for truly random numbers, one should never use (rand() % n). There are warnings to this effect in the Linux man page for rand(3). At least in Debian.

Use random() and srandom() (instead of rand() and srand()) if you have them available. If not, you have to do a little bit of work. The basic idea is to use the result of rand() to produce a floating point value in the range [0.0, 1.0). Then you can multiply that by the width of the desired range, 6 in this case, to produce a value in the range [0.0, 6.0). Truncate that to an integer, producing one of {0, 1, 2, 3, 4, 5}. Then add the lowest value in the range, 1 in this case, to produce a one of {1, 2, 3, 4, 5, 6}. I don't think this is quite perfect; it seems that the highest value would be slightly less probable due to the limited resolution of floating the point. But I think it works in practice. Some code like this (warning, not thoroughly tested):

int rand_range(int low, int high)
{
return low + (int)((rand() / (RAND_MAX + 1.0)) * (high - low + 1));
}

And then, to roll a die, call it like this:

rand_range(1, 6);

HTH

Re:Speaking of rand() [OT]

[SirRichardPumpaloaf]

The problem is almost certainly compiler optimization. When you ask for roll()+roll(), the compiler notices that you are calling the same function with identical arguments twice, so it only generates one call and puts the result in both places. This is why random number functions often take a dummy argument, so that you can do something like rand(dum)+rand(2*dum) to keep the compiler from outsmarting itself. Rewrite your roll() function to take a dummy argument like this and I bet it will start working correctly.

Re:Speaking of rand() [OT]

[Lancer]

Actually, this isn't the problem - if that were actually the case, I would have received just evens, not odds :)

Re:Speaking of rand() [OT]

[SirRichardPumpaloaf]

Well, sure, I suppose if you want to split hairs like that I guess I might have been wrong... :-)

I've got a question

[OsamaBinLager]

Why do you have a chapter on 'buffer overflows' when languages that allow buffer overflows and pointer overhangs, etc, are considered both unsafe and unsuitable for modern software?

I'm talking, of course, about the only languages that actually SUPPORT buffer overflows - C, C++, and Assembly. Not exactly the sorts of languages that are considered seriously in software engineering these days.

Re:I've got a question

[Anonymous Coward]

"I'm talking, of course, about the only languages that actually SUPPORT buffer overflows - C, C++, and Assembly. Not exactly the sorts of languages that are considered seriously in software engineering these days."

They may not be considered, but they're sure used a lot more than other languages these days.

Not that simple.

[dmaxwell]

I think the parent poster was trying to point out that some vulnerabilities conform to general patterns that can be spotted in a debugger. There is a big difference between looking for a few specific cases in the code and trying to reverse engineer an API.

I wouldn't be surprised if black hat tools exist which can scan disassemblies for probable stack and buffer vulnerabilities. Where this gets tricky is figuring out enough of what that section of code does to craft an exploit. It is still less difficult than full blown reverse engineering. The process would be akin to finding cheats in MAME or looking for Nintendo cheats with a Game Genie. One way I can think of to ease that part of it is to rebuild the disassembled code so that it can be single stepped when executed. Something like Bochs could also be used so that the black hat investigator can monitor the execution environment to any level of granularity desired. Once it's known what functionality the suspect code implements, one can start coding prospective exploits.

Recreating a secret API would be FAR more difficult. An exploit is basically something that adds itself to already running code. One doesn't have to have extremely deep knowledge of what the vulnerable code does. A project like WINE attempts to replicate the functionality of that code in a source maintainable format. It's a whole 'nother kettle of fish altogether.

Worst review ever!

[Yankovic]

The book may be good or not. The content may be good or not. The authors may have had insight or not. Too bad no one could possibly know after this review. There are entire paragraphs that make absolutely no sense. I quote:

"I can't cover each chapter because I want John and Gary to write more books , so they need to sell a few copies!

Why do they do this? Isn't this giving the bad guys what they need? The bad guys have the information already. There is belief in the security community of full disclosure. This means not keeping things security and calling it secure. "Full disclosure means that hackers publicly disseminate information about your security problem, usually including a program that can be used to exploit it (sometimes even remotely)." (page 81)"

The first line here starts with a ridiculous comment about why the review is so short. Thanks for telling me you're lazy. Then, the review jumps to the middle of some paragraph that apparently only partially made it on the page. Why do they do what? Could someone please explain to me what "This means not keeping things security and calling it secure." means? I could go on to the rest of the paragraphs which are two line summaries rather than any analysis of quality, but the point is made.

We are a technical audience, and could have had a much more in-depth review without the nuances being lost on us. Even more so, PLEASE get an editor to at least LOOK at the reviews. Now I have to go elsewhere to find a review so that I can figure out whether or not this book is worth buying. The author's positive review sounds like it came right out of:

http://www.quartertothree.com/features/editorials/ lackey/game_reviews_gone_bad.shtml

You're exactly right

[CrazyJim0]

I design and sell 3rd party applications to cheat MMORPGS :) And I design but not develop server code for like 10 years. Once someone cheats, then everyone cheats just to comepete. Its like taxes too.

Whats funny is that I designed Gnutella without knowing about it. I was designing an unhackable version of Diablo 1. Where characters are stored client side... The key was there was a psuedo server made up of the thousands of other people playing who also kept your data... It was a P2p network as base then everyone stored extra data... If you looked like you were cheating by a large % of computer police, then you're no longer in the network... This may sound shady and up for corruption, but online communities do flag people as shady to begin with... Its not really succeptable for conspiracy either because if you want to take your ball and go home, you can do it with your friends too.

Book review

[Teh Grammar Patroll]

There are many punctuation and spelling problems with this article. Far too many to call out in detail. Perhaps my favorite error however, is the author's use of the word "peaked" instead of "piqued". You should say, "...your curiosity is piqued," not "...your curiosity is peaked." Of course, an automated spell checker would never catch this error; one would have to actually know the difference to begin with.

Re:Book review

[pclminion]

Hey Grammar Boy, where is the subject in this "sentence" that you wrote?

Far too many to call out in detail.

Why don't you turn that Discerning Grammatical Eye toward your own writing next time?

Nope, Member of the IRA

[Anonymous Coward]

Gary McGraw is a card carrying member of the IRA! He was their ace in the hole during the early 90's, inserting software backdoors into server apps so the IRA could shut down the Internet and corporatations as a massive political gesture.

Why do all security books concentrate on hackers?

[jlusk4]

Sounds like a goofy question, I know.

I understand the majority of security breaks are perpetrated by people who are already authorized to use the software in question, but do so in a way not consistent with their job description, as if the only security was the job description.

Insiders, in other words.

I went looking for security books a while ago and found lots of books on how to secure your web server and keep your machine from getting rooted and how to encrypt data sent over the wire. Now I see a book with a chapter on buffer overruns.

How hard can it be to write a book on keeping the various legitimate users of the system from snooping around the parts of the system they aren't supposed to go to? Doesn't anybody remember the scandal at the dept of Health & Human Services (I think that's the right dept.) in which users of the system were essentially surfing people's social security data for entertainment? I don't believe that had anything to do with buffer overruns or rooting servers or any of that hacker shit.

Re:Why do all security books concentrate on hacker

[viega]

Do you think a book on building secure software would be anything but laughed at if it didn't talk about buffer overflows? Actually, in the book, we do talk about how insider attacks are the most common kind of attack, and we encourage people to consider that in their risk management process, through design and into implementation.

The problem of malicious insiders is one that the software can only deal with up to a point. You need to have good physical security and good network security (e.g., strong passwords, etc.) I think it'd be good to see a book on defending against malicious insiders, but you can bet it will focus more on aspects other than the software security.

cost

[ChannelX]

21% off at bookpool

BSS

You can also just use a Virtual Machine

[Anonymous Coward]

I'm new, I'm just about to start programming. But I'm not stupid and I've done some research.

The future of programming is programming for Virtual Machines. There are several reasons for this but one of the reasons is security. The number 1 in the list of security risks every year is "buffer overflows". It seems it's very hard to program in such a way that programs don't have buffer overflows.

Instead of twisting and turning into all kinds of strategies to prevent buffer overflows you can instead completely bypass the issue by programming in Java. Java doesn't have "buffer overflows" at all! Scratch that from the list of security flaws for free.

If you have a problem with the control that Sun has over Java (which is sometimes a good thing) you can use this platform instead: http://www.squeak.org/
Although I'm not sure if Squeak is immune to "buffer overflows" or not, Someone please give a noob like me some help and tell me if this is the case? thanks.

I know from articles that .NET is not immune to security flaws so that platform is not the future, maybe just an intermediate step.

The disadvantages of Virtual Machines that I've read about are that they're a bit slower than languages like C or C++. Well I've done some more reading and it seems that problem is almost history. Seems that C++ is only between 2x and 1.5x faster than Java now. Taking into account that PCs will reach 10GHz within a couple of years, I'm convinced that Java like languages are the future.

The only exceptions are things like TCP/IP routing and server stuff like that where every percent of performance is vital.

I know it's difficult to just throw away all that experience in C++ that you have now but if you can find the heart, switch. And if you're new to programming, like me, then there's only 1 sensible choice for the desktop. A Java-like language!

P.S. please don't forget to tell me whether Squeak is immune to buffer overflows or not, thanks.

Re:You can also just use a Virtual Machine

[Tjebbe]

Java is indeed invulnerable to buffer overflows (although the virtual machine itself does not have to be), but Java programs can be attacked on other parts (RMI and classloading are popular targets iirc).

The strange thing is that buffer overflows are very old problems, and have been known for ages. Most (experienced) programmers also know how to avoid them, either by not using some functions blindly or using some form of boundchecking, but STILL they make up about half the security bugs found nowadays. It seems that some people just don't care...

If you do care then remember that the buffer overflow isn't the only security problem source, but just a common (and pretty stupid) one.

Re:You can also just use a Virtual Machine

[Anonymous Coward]

Buffer overflows are not the only thing that count in the world. While being a rather common security flaw, having the whole world switch to Java is *not* going to solve anything. There are some people in the world who like to develop Operating Systems and other such software that is simply not possible to do in Java or any other language that runs on a virtual machine.

I would suggest that you stop reading books and start doing some real work. Most good computer people that I know get extremely annoyed with people who talk like they know what they are doing, but don't write code. Reading to learn is great, but it can't be substituted for experience.

Re:You can also just use a Virtual Machine

[Anonymous Coward]

http://www.jos.org
The Java OS.

Re:You can also just use a Virtual Machine

[aluink]

I am new to programming myself. But i have used C, C++ a lot and tried Java. And I like how java works with buffer overflow. But to trade all the power of C, ++ for a virtual machine I think is an absurd thought. A virtual machine takes so much functionality away. A good programmer should be able to check for that on his own and not have to rely on a language to do it for him. I am still learning how to manage my boundaries. It has been teaching me to be a secure programmer, and to be aware of what is going on at all times. It is teaching me to mean what I say and say what I mean. And to agree with comment #3127358, I have learned exponentially more from experience than from reading C++ in 21 days.

examples corrupted

[brlewis]

I downloaded bss_examples-1.0.tar.gz from the web site, but a lot of the files seem strangely corrupted, e.g. spaces before > where there shouldn't be. Makes HTML look funny and Perl not work.

Re:Why do all security books concentrate on hacker

[Tjebbe]

Try Security Engineering by Ross Anderson, which looks at security at a somewhat higher level..
I just read it and it's great (atm, i'm reading BSS :) )

Har har :D

[The Great Wakka]

... After reading Building Secure Software: How to Avoid Security Problems the Right Way (BSS:HtASPtRW), I decided I needed to ...

Quite an abbrevation, doncha think? :D
Abbreviations are supposed to be shorter than the word... how about BSS (Building Secure Software). One can normally omit the subtitle in an abbrevation

Moderators NB: This is intended as humor. The last bit (about an abbrevation suggestion) was tacked on 'cos it was a thought.

How to solve the buffer overflow problem..

[ugen]

The *RIGHT* way of solving a buffer overflow problem would be to have a return address stored on a SEPARATE stack, different from the stack where the parameters and such are stored for the function being called.
Recall that the way this usually works, is overwriting a return address through the non-bound-checked data with some function address that will execute a shell or something of the sort. If it's not on the data stack - you CAN'T overwrite it.
This will require changes both in compilers and in the instruction set, true. But it will make things inherently more secure. The worst one will be able to do with buffer overflow is corrupting data, but no NEW functionality will be executed.

Re:How to solve the buffer overflow problem..

[Anonymous Coward]

its been tried before and failed. x86 is too deeply entrenched to even allow this to happen at all.

Re:How to solve the buffer overflow problem..

[Anonymous Coward]

The *EASY* way of solving a buffer overflow is not to use unsafe functions.
If I ate 15 twinkies a day, and wanted to lose weight, then I could start jogging 15 miles a day.. Or just stop eating the friggin twinkies.
;)

hey

[YourMissionForToday]

Wear our hoodies!

definitely a good book

[Anonymous Coward]

I find bugs in server software, so I picked this book up as a reference.. Its reminded me of some areas of testing that I hadn't paid much attention to before. Its well-written, modern (at the moment), and provides a good overview of software security issues and how to avoid them. I would definitely recommend it to coders, testers/QA, and maybe even administrators who want to understand software security issues. This book should be required reading for anyone who develops server software products..

More to the book?

[Garen]

Judging from this short review, it just sounds like another in-depth Ode to the various inherent flaws of C. Is that all?

Hopefully not, but from other reviews/stories I've seen here on /. thats what it really seems to boil down to -- and its really beginning to annoy me to hear about some big "security community", and all these "security issues", security this and that, blah blah blah which all boils down to a design problem with C which has been beaten to death by now and is not very interesting.

If that isn't the case, I would have really appreciated a more thorough review (beyond "I liked it").