Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Too Cool For Secure Code?

michael posted more than 11 years ago | from the java-for-everything dept.

Security 471

An anonymous reader writes "Looks like not everyone believes Linux is the monolith of security folks might like us to think. Jon Lasser raises some interesting points in this article over at Security Focus. Though it has to be said, that whilst he focuses on the Linux/Unix side of things, a good proportion of programmers (no matter what they work on) are guilty of similar conceit to some extent."

Sorry! There are no comments related to the filter you selected.

first post (-1, Offtopic)

foobar42 (153386) | more than 11 years ago | (#5606793)

First post!

Sorry, had to...

Re:first post (-1)

Grape Smuggler (569838) | more than 11 years ago | (#5606818)

You fucking pussy. If you are going to grab a frosty piss, then at least be man about it.

"Ooh, please, I am so sorry, but I had to do it. Please don't down mod me."

What a fucking lamer you are.

Re:first post (-1)

pantaweenis (660198) | more than 11 years ago | (#5606906)

you will be sworded. burninate!11

Re:first post (-1)

Grape Smuggler (569838) | more than 11 years ago | (#5607118)

Fuck off you little patsy.

Yeah..all that awesome 'peer reviewed' code... (0)

FatSean (18753) | more than 11 years ago | (#5606795)

Taken a look at sourceforge? My god, some of the work is horrible!

Re:Yeah..all that awesome 'peer reviewed' code... (1)

Vinson Massif (88315) | more than 11 years ago | (#5606832)

At sourceforge you can see it.

Re:Yeah..all that awesome 'peer reviewed' code... (1)

FauxPasIII (75900) | more than 11 years ago | (#5606834)

>> My god, some of the work is horrible!

Most code is horrible, period. That's why you spend extra time and effort on the fundamental stuff like the kernel. If your kernel's working, and you're non-root, then the worst you can do is trash every file and process that you own. ;)

Re:Yeah..all that awesome 'peer reviewed' code... (1)

Manip (656104) | more than 11 years ago | (#5607130)

I went to IRC and tried to ask some questions about buffer-overflows with code execution and they called me a hacker and banned me. This is just insane, if programmers don't discuss or uderstand the problems how can they fix them! Most programmers are still stuck in the 1990's of security and don't intend to evolve let alone to update/fix any problems before they become issues

In Soviet Russia code secures YOU (0)

dmontreuil (464940) | more than 11 years ago | (#5606797)

In Soviet Russia code secures YOU

Re:In Soviet Russia code secures YOU (0)

Anonymous Coward | more than 11 years ago | (#5606896)

No, in Soviet Russia the KGB would secure YOU.

Too cool for security (2, Insightful)

The Terrorists (619137) | more than 11 years ago | (#5606809)

Everyone thinks they can hide in teh crowd. Well is someone is determined to hack YOU then they will hack you. If you have something valuable hacking attempts WILL BE MADE! Many will involve social engineering and stuff like that, they will be targeted at YOU.

Everyone likes to brag about what they are doing and to be nice to people. The best security is social in nature: clam the fuck up about what you are working on, isolate yourself from others who are trained to know the meaning of what you are doing. That's the best security - it leaves you free of determined attempts and leaves only the random attempts at hacking which can be dealt with by techniques mentioned in the article link.

Re:Too cool for security (1)

Omkar (618823) | more than 11 years ago | (#5606871)

"In an age where processing power is cheap, there's no excuse for a mail client written in C or C++."
This sounds like Microsoft's philosophy - bloat because we can afford to.
Why not use security tools and a dedication to high performance?

PLEASE IGNORE (0)

Anonymous Coward | more than 11 years ago | (#5607010)

This was meant to be a main reply, not one to this comment.

Re:Too cool for security (1)

mrtroy (640746) | more than 11 years ago | (#5606886)

Despite your random capitalization of words, I disagree with you. The best security is not
The best security is social in nature: clam the fuck up about what you are working on, isolate yourself from others who are trained to know the meaning of what you are doing.

The reason this does not work is because nobody understood what you just said.
It is true that you cannot always hide in a crowd, because most exploits end up in the hands of script kiddos who run a scan on *.*.*.* from a previously exploited box they use. Then they run auto-exploiters on all the boxes that appear vulnerable. Then they put a little trojan on those boxes, and make a ddos net, which they use to impress their online lovers and the like.

So, you cannot just hide in the crowd, however the best way to protect yourself is not to be stupid. Do not leave admin passwords blank (win2k/xp is famous for this one...the default is blank!), do not run OS's that you do not know how to secure, and do not run any specific programs that you do not know how to configure.

Most exploits are due to misconfiguration or stupidity, so avoid these two things.

Your sig (OT) (-1)

The Terrorists (619137) | more than 11 years ago | (#5606909)

That sort of sentiment is why disarmament and other peaceful processes get stopped in their tracks. One must make a moral committment to voluntary action towards peace.

Re:Your sig (OT) (1)

Shadowlion (18254) | more than 11 years ago | (#5607152)

That sort of sentiment is why disarmament and other peaceful processes get stopped in their tracks. One must make a moral committment to voluntary action towards peace.

First of all, that quote is a Jack Handy quote -- the Jack Handy from Saturday Night Live, a category that includes other quotes like, "If you ever drop your keys in a river of lava, forget about them, becuase man they're GONE" and "".

Second, "moral committment to voluntary action towards peace" sounds nice and flowery, but you're omitting the part that makes that work -- the part about BOTH PARTIES making that moral committment. Peace doesn't work when one party makes that moral committment, and the other party doesn't.

How is peace possible if party X says, "we want peace," but party Y says, "fuck peace -- let's go bomb X!"?

Re:Too cool for security (0)

jhigh (657789) | more than 11 years ago | (#5606897)

Actually, the BEST security is VIGILANT security, which means not negating the necessity of taking every proper precaution, including writing secure code.

Security has to happen on all levels. I think this article is insightful, and we would all do well to check our egos at the door (you know we all have them).

Re:Too cool for security (1)

InfiniteWisdom (530090) | more than 11 years ago | (#5606901)

<blockquote>Well is someone is determined to hack YOU then they will hack you.</blockquote>
Many people will take grave offense at your usage of the word 'hack'... unless you're a piece of open-source code of course :)

<blockquote>
The best security is social in nature: clam the fuck up about what you are working on, isolate yourself from others who are trained to know the meaning of what you are doing
</blockquote>
In other words, security through obscurity?

Re:Too cool for security (1)

usotsuki (530037) | more than 11 years ago | (#5606965)

Yes, that's what he meant...and we know it doesn't work.

Just look at how often Maro$haft systems get "haX0red". That's security?

-uso.

Re:Too cool for security (1)

Omkar (618823) | more than 11 years ago | (#5606902)

Security through obscurity? Yeah, that works, just ask MS.

What's this??? (-1)

I VOMIT ON FAILURES! (652124) | more than 11 years ago | (#5606813)

Michael is posting an article that questions Linux's security? It is April 1 already?

Of course not (2, Interesting)

ch-chuck (9622) | more than 11 years ago | (#5606820)

But it is OPEN meaning a COMPETANT admin can MAKE it very secure. About the closest thing to 'out of the box' security is OpenBSD. My Linux (RH71) box was rooted in less than a day after putting it on the 'net. My OpenBSD box has lasted for almost a year.

Re:Of course not (2, Funny)

Azghoul (25786) | more than 11 years ago | (#5607050)

So, what you're saying is, you're not a competant admin? :)

Re:Of course not (1)

metalhed77 (250273) | more than 11 years ago | (#5607068)

I don't think that's the article's point. The author argues that programming in low level languages reveals bugs inherently. I'm betting your RH7 box was running a few daemons which got rooted. OpenBSD runs many of the same daemons. And sysadmins could care less from a security standpoint as to whether or not it was open as they don't have time to look at every single line of code they're using.

Secure Code... (1)

mrtroy (640746) | more than 11 years ago | (#5606824)

Well first off, I would like to say that every OS has had their fair share of vulnerabilities.

Secondly, we learned at skool (yes some non cool nerds go to school to learn things) certain ways to make your code less likely to be exploitable. For example, making certain objects static is often useful. Object Orientated Programming lends itself to be useful in making secure code.

I will leave it to karma sluts to find a link for me :) (bah, but I will also look for some old sample assignments which demonstrate this)

Re:Secure Code... (0)

kewsh (655090) | more than 11 years ago | (#5606900)

sorry helloworld.cpp doesnt count

Theo (-1)

Anonymous Coward | more than 11 years ago | (#5606831)


Theo de Raadt uses C therefore C is the tool of the security gods.
Linus uses C, therefore C is the tool of slack-jawed yokels.

I am in a connundrum.

Re:Theo (0)

Anonymous Coward | more than 11 years ago | (#5607028)

C removes the processor specific nature of Assembler and is Good. C++ is the beginning of Bad. Coders who can't hack C probably shouldn't be. Depending on a higher level language just means depending on those who maintain the code for that language or languages. People who use Perl are dependent on both the coding quality of the Perl engine itself and the C libraries that it is built from.

Re:Theo (1)

enomar (601942) | more than 11 years ago | (#5607150)

Isn't C dependant on the quality of the compiler and/or the OS system calls it makes? Following your logic, I can only write secure code in machine code.

Right... (1)

CommieBozo (617132) | more than 11 years ago | (#5606848)

Tell me what my mail client should be written in? Java? C#?

Maybe this guy buys a new supercomputer every month, but my Duron at work isn't getting faster any time soon.

Re:Right... (1)

gilesjuk (604902) | more than 11 years ago | (#5606974)

Why reinvent the wheel? plenty of clients out there.

Re:Right... (1)

usotsuki (530037) | more than 11 years ago | (#5606990)

Your mail client should be written in 8088 ASM. *g*

No seriously, I think C is the ideal systems-programming language. It's also the only language ideal for systems hacking that I grok.

-uso.
Leetness does not a hacker make. *g*

Re:Right... (1)

sdokane (587156) | more than 11 years ago | (#5607015)

C# and Java are fast enough for lost of apps. My god, look at how many apps use VB!

Interestingly enough I decide once to see how productive I was and kept track of no of lines of code for a while using C++, VB. It was pretty much that same. Also tracked the number of lines of well written documentation I could produce in a day and it was about the same. Perhaps the best way to improve porductivity is to put everyone on a typing course. Anyway, back on topic...

In defence of C++, the same protection from buffer overflows can be obtained using well written library classes. It then becomes part of the language anyway. The problem is that people dont use/develop/publish them. It's the old snobbery "Well if I use someone stuff, I won't know what going on underneath". (Besides it more fun to use the low level stuff). The attitude extents to GUI and much else. E.g. Maintaining makefile is considered a intelectual activity rather than boring accounting. But manual maintainence can introduce build problems and errors.

On the other hand, the same instinct produces products like LINUX. After all what was wrong with BSD?

Re:Right... (2, Insightful)

Junks Jerzey (54586) | more than 11 years ago | (#5607204)

Tell me what my mail client should be written in? Java? C#?

Or Python. Or Ruby. Or Lisp. Or REBOL.

Maybe this guy buys a new supercomputer every month, but my Duron at work isn't getting faster any time soon.

I assume that you're trolling. An email client is so lightweight--mostly GUI and waiting for sockets--that you could write it in *anything* and even on 200MHz Pentium, and it would be just fine.

There has gotten to be some misplaced angst among younger coders, those who are frustrated at the lack of perceived performance in Windows and KDE and various large applications. They come up with pet excuses for that slowness, most of which are invariably, flamingly wrong.

to cool for secure code? (1)

potaz (211754) | more than 11 years ago | (#5606855)

Not only am I too cool for secured code, I'm too cool for school.

There is secure code out there. (3, Funny)

grub (11606) | more than 11 years ago | (#5606858)


I've been trying to r00t GORILLAS.BAS on my DOS box for years with no luck.

Re:There is secure code out there. (1)

stratjakt (596332) | more than 11 years ago | (#5606945)

Heh.

Back in high school a compiled version of gorilla was about the only 'game' available to students in the libraries computer lab.

It was dead simple to crash it and have it dump out to a C:\ prompt. Though there wasnt much of interest to do from there on in, being a closed net with no access to anything of import.

Re:There is secure code out there. (1)

mrtroy (640746) | more than 11 years ago | (#5606979)

Hehe.
I would have to say that to my best knowledge, no Microsoft products are r00table. :P

Gaining admin access, thats another story!

Re:There is secure code out there. (-1)

Horny Smurf (590916) | more than 11 years ago | (#5607198)

Xenix was r00table.

So true (3, Insightful)

Jack Wagner (444727) | more than 11 years ago | (#5606879)

I've found over the years that most new coders aren't taught the proper basics of coding because they focus on learning high level languages and arcane algorithms, instead of focusing on the art of computing, like Donald Knuth's books.

Only too often have I sat in on meetings with immature little dweebs who rant on and on about XML or the technolofy flavour of the month or hacking at code to achieve Olog(n) cahche hits instead of focusing on making proper underlying designs.

Frank Brooks talks quite a bit about this in his book "The Mythical Man Month" where he states that secure computing is getting worse on the level of one order per generation of new programming languages. That book should be required reading by all CS students.

Warmest regards,
--Jack

I agree! (0)

GreatOgre (75402) | more than 11 years ago | (#5606983)

If I had my moderators points, I'ld mod you up.

Hahahaha (1)

I Am The Owl (531076) | more than 11 years ago | (#5607046)

Jack really brings the morons outta the woodwork for everyone to see. Like a duck call that works on idiots, I suppose.

Re:So true MOD PARENT UP (0)

Anonymous Coward | more than 11 years ago | (#5607048)

Spot on. I've been a coder for 20+ years, cutting my teeth on VAX back in the good days and I couldn't agree more!

Re:So true (1)

Strigiform (240409) | more than 11 years ago | (#5607087)

I wonder to what extent certification (e.g. M$ certification in, say, VB) is to blame for this? Some people think that if someone can program in a language and has certification in that language, that the person is a good programmer. Someone with a broader background in programming that includes algorithm design, has at least read some of Knuth, knows something of how processors work (this is one reason why Knuth uses a virtual assembly language) and knows some theory would have a significant edge on the "one-language" certified programmer.

It's not about conceit (0, Troll)

lavalyn (649886) | more than 11 years ago | (#5606881)

It's about default reality.

In Windows, the main user is often Administrator, and all services run either as Administrator or System. In Unix, most of us use a non-root account (though we may have access to root) and most services are run by its own user, like httpd, or nobody. Combine this with default world-write permissions of "allow" in Windows and "0644" in Unix.

This still doesn't mean much for a script kiddie h4x0r with a rootkit ready to go, but damage is at least slightly mitigated.

Languages not necessarily the problem (3, Insightful)

Ed Avis (5917) | more than 11 years ago | (#5606882)

The thing is, you can program in a low-level language yet still avoid bugs like buffer overflows and failing to handle NUL characters in strings.

In C, it just requires using a library like glib for your string handling, and some similar library to provide bounds-checked arrays.

In C++, it means avoiding char * strings like the plague and using the standard 'string' class instead; similarly using 'vector' or other STL containers instead of C-style arrays.

I think it would help if there were a standard, minimal C string library, and if existing APIs including system calls were given equivalents using these. So open() could take a pointer to a 'const struct String' rather than a char *. Having done this, the existing functions like strlen() and strdup() could be declared deprecated. There are plenty of decent string manipulation libraries for C, what's lacking is a single one library which everyone can agree to support.

At least in C++ there is a standard 'string' type, although some people insist on reinventing the wheel (Microsoft's MFC with CString, Qt with QString).

You can, but it's hard, and why would you want to? (3, Insightful)

Tom7 (102298) | more than 11 years ago | (#5607111)

How do you prevent against double-frees ... Use a garbage collector? Integer overflow ... use a package that checks for overflow on each integer op? Bad pointer arithmetic ... disallow it? Force the programmer to check error conditions on system calls ... use exceptions?

What you're describing, is, in fact, a modern high-level language. Except that if you were to do all this stuff in C, you'd be in such an environment that even the simplest stuff is a pain in the ass... calling special functions or macros to access arrays, etc. Nobody wants to do this, and nobody wants to read code that does -- and that's why nobody does. These high-level safe languages do all this stuff automatically, and transparently, so that you can write clean natural code and it is secure against the most common kinds of holes. Java is an example if you like Object Oriented programming, for my part I like SML.

Of course it's possible to write bug-free C code. But it's really hard when you are at the scale of even a modest network daemon. Even our best programmers make security bugs when writing in C though (see: Quake I, II, III, Half-Life, Linux Kernel, sshd, ftpd, apache, perl, mozilla, and just about every other software package you think is written by great programmers), so how can we expect the rest of the world to do it?

Re:Languages not necessarily the problem (0)

Anonymous Coward | more than 11 years ago | (#5607156)

In C, it just requires using a library like glib for your string handling

It doesn't even require that. Just use the "n" counterparts, E.g. strncmp() instead of strcmp(), strncpy() instead of strcpy() etc. That, and some brains.

There is a reason for reinventing the C++ string class. These days its all about multibyte characters (E.g. UTF-8) but string only does the old ASCII 8bit. If you need to manipulate Unicode strings, you need a new string class.

Re:Languages not necessarily the problem (1)

Deth_Master (598324) | more than 11 years ago | (#5607164)

That's what I'm saying. I mean he (the author of the article) even shot himself in the foot by claiming that he sees bugs in higher level web-languages like PHP.
Just because you use a high level language, if you suck at coding, your program will have security holes.

Referring to the standard, minimal C string library. I used one in the past. I believe it was called APSTRING. It was a nice string object and and it had a method to make it compatible with those older functions that wanted char *'s. Making one library that everyone will agree to support will be difficult, because they all have slightly different implementations of basically the same thing. A defacto standard could be made if you started using one and kept on using it.
There's nothing wrong with writing code in C++ if it's written well. Having access to the lowlevel stuff is handy, but if you don't need it, don't use it. Use the more advanced, safer, if slightly slower libraries. Heck, sometimes (not always) they're even easier to work with.

Re:Languages not necessarily the problem (0)

csguy314 (559705) | more than 11 years ago | (#5607200)

mod parent up.
A bad coder will be a bad coder, regardless of the language they use.

Hey firewall boy... (1)

ReidMaynard (161608) | more than 11 years ago | (#5606884)

SecurityFocus columnist Jon Lasser is the author of Think Unix (2000, Que), an introduction to Linux and Unix for power users. Jon has been involved with Linux and Unix since 1993 and is project coordinator for Bastille Linux, a security hardening package for various Linux distributions. He is a computer security consultant in Baltimore, MD.

Jeeze, he isn't even a programmer..

Re:Hey firewall boy... (1)

ksw2 (520093) | more than 11 years ago | (#5607085)

Jeeze, he isn't even a programmer..

I would think that writing a massively popular security-oriented program (Bastille) would qualify him to comment on secure programming, wouldn't you?

Re:Hey firewall boy... (1)

IPFreely (47576) | more than 11 years ago | (#5607167)

Jeeze, he isn't even a programmer..

What makes you say that?

Experienced professionals don't put programming languages on their resumes, they put job titles and responsabilities. You don't get that kind of resume unless you can do all the work that goes with it, including programming.

Yeah, but..... (1)

IamTheRealMike (537420) | more than 11 years ago | (#5606895)

To be honest, I've thought for quite some time that people should be moving away from C and C++ for most stuff on UNIX, simply for the productivity benefits it would bring - the added security is OK, but as pointed out in the article, high level languages aren't a silver bullet.

Unfortunately, the vast majority of our desktop software on Linux is still being written in C or C++. Why? Well, those are the "native" languages of the two big desktop projects. C++ was chosen in KDE because, well, that's what Qt is. C was chosen in GNOME, ironically partly because it's easier to bind to other languages (when done properly).

I think the one of the reasons more software isn't written in higher level languages is that bindings are a PITA - not only do you have to manually produce them, but in the absence of solid dependancy management for all Linux distros, it grows your dependancy list as well. See the fate of Straw (an python RSS app) for an example of this.

What's really needed is a decent component model, making it easier to choose the right language for the job, instead of choosing a langauge because that's what all the libraries are written for, or because that's what everybody else uses.

Re:Yeah, but..... (1)

Ed Avis (5917) | more than 11 years ago | (#5606968)

The article talks about three big classes of vulnerabilities: format string bugs, buffer overruns, and input validation bugs. The first two need not ever occur in a C++ program: the STL containers do not use fixed-size buffers, and the STL input/output routines don't use format strings, printf() or scanf(). If you deliberately ignore what the C++ standard library provides for you and go back to C library routines and fixed-size arrays you become more vulnerable to these attacks. (Out-of-bounds subscripts can still happen with the STL, unless you are using an implementation which does bounds checking on vector subscripts and the like. IMHO this should be the default, manually turned off for speed-critical code.)

Even in C there is a good choice of libraries for string manipulation and containers which don't allow buffer overruns.

It's not C and C++ which are at fault, it's the C *standard library*.

Bloat my Mail (1)

oliverthered (187439) | more than 11 years ago | (#5606911)

Jesus, I get enough bloat in my email just because of spam. Now this guy want's bloat from the ground up.

Processing power cheap, no way, all you need is 640k, that's what I say.

What he should be saying is re-use code and libraries to avoid bugs.

Re:Bloat my Mail (1)

usotsuki (530037) | more than 11 years ago | (#5607025)

640K? Whatever happened to those halcyon days when 64K was a lot of memory, and Terse-80s, CP/M machines and 40x24 monocase terminals like that of a stock 48K Apple ][+ r00led the world? *g*

-uso.

Ignoring certain realities (5, Insightful)

binaryDigit (557647) | more than 11 years ago | (#5606919)

After programmers take responsibility, perhaps they can consider using the right tool for the job, rather than the right tool for the job of their dreams.

I don't think this macho thing plays into it nearly as much as he states. I think it has to do with comfort and laziness. I've been programming in C/C++ for over 15 years, so obviously, if I have a programming task to tackle, I will lean towards using those languages. I can do a minimal amount of vb, so if I need to slap together a ui, I can, but not anything that did anything interesting. If I have a task, how much time should I spend learning a new language if that language is better suited for the task than a language I know? Since I'm new to this language, how much worse is the code going to be than what I could have written in a less suitable language?

I'm not saying that I'm against learning new languages, but a programmer can only realisticly be "good" at a small set of languages. And the realities are that unless I'm working on a pet project, I don't have the time to learn something new or try to come back up to speed on a language I last used two years ago. Perl is an excellent example in my case, I don't know a lick of it. If I have simple text processing to do, I use the "simpler" text utilities (awk and sed primarily), unless the problem is very simple, in which case I fire up my text editor. If it's more complex, then I use C/C++. Could it be done quicker in Perl, maybe, maybe not. If by quicker you allow me to ignore the ramp up time to learn the language. If I were doing this type of thing all the time, then the rampup could be amortized in the long run. If it's onsie twosie, then forget it, out comes the c compiler.

Re:Ignoring certain realities (1)

smallpaul (65919) | more than 11 years ago | (#5607187)

And the realities are that unless I'm working on a pet project, I don't have the time to learn something new or try to come back up to speed on a language I last used two years ago.

The author is talking about significant applications, not little toy scripts. You are going to be very familiar with (and maybe even expert in) the language used to build a significant application by the time you are done programming it. But another point the author is making is that once you learn a high level language you'll find you can use it for a lot more than you thought. Many programmers get away with using high level languages for 95% of their jobs. And those jobs can involve writing significant (e.g.) ecommerce, content management or client side apps.

Don't get me wrong. Linux is not going to use Python as his major day to day programming language. But I wouldn't be surprised if even he finds the need to program something other than the Linux kernel often enough to justify skill in a higher level language.

Re:Ignoring certain realities (0)

Anonymous Coward | more than 11 years ago | (#5607194)

There is also the matter of code reuse. The columist isn't a coder; and it shows. He complains that there is "no excuse" for writing a mail client in C or C++ these days, but completly ignores the fact that a lot of code has to bind to external libraries. Think about it, if you're writing a mail client and you have a set of libraries to do the IMAP and POP3 connections which have a C API, and you're targetting a platform that uses C++ for the GUI, what will you use? ADA? Or will you just use C++ and some C to bind to the libraries?

In next weeks column: Pigs just refuse to fly because they're lazy, I tell you

comparison is unfair (1)

Kunta Kinte (323399) | more than 11 years ago | (#5606920)

This comparison is unfair.

He's comparing all the vunerabilities in open source programs that he found has been released in a period of time and calls them 'linux' bugs.

Those programs have nothing with the linux kernel. Other than they can be run on it.

Do you want to compare that list with every program from every vendor that codes for microsoft windows. On a hunch, I'd say it's a lot higher.

Re:comparison is unfair (1)

stratjakt (596332) | more than 11 years ago | (#5607017)

Those programs have nothing with the linux kernel. Other than they can be run on it

And an IIS vulnerability has nothing to do with the NT Kernel, only that it's run on it. So if an IIS or SQL worm can be called a 'windows' bug, then an Apache or mySql one can be called a 'linux' bug, it's only fair.

But that's splitting hairs.

His point is valid. Just because the source is open doesn't mean the programmers are any more skilled, although they generally believe they are. That hubris leads to mistakes.

Open source is great because it can be reviewed by it's peers. Wonderful. But who reviews it? Do you? I know I haven't pored through the source for the SAMBA tarball I just installed on one of my boxes looking for holes.

Microsoft no doubt has a team of employees who look for vulnerabilities. Linux has a decentralized team of hackers looking for vulnerabilities. In the end, from a 'how good is the code' standpoint, it's pretty much apples and apples.

There are lots of reasons to like open source (and by extension Linux), but I've never considered "It's super dooper secure!" to be very high among them.

Re:comparison is unfair (1)

Nothinman (22765) | more than 11 years ago | (#5607185)

And an IIS vulnerability has nothing to do with the NT Kernel, only that it's run on it. So if an IIS or SQL worm can be called a 'windows' bug, then an Apache or mySql one can be called a 'linux' bug, it's only fair.


Not really. IIS and MS SQL only run on Windows, Apache and MySQL run on quite a few OSes other than Linux. I personally wouldn't call a MS SQL exploit a "Windows bug" but you'd still be hard pressed to find another environment that it'll cause problems in.


Microsoft no doubt has a team of employees who look for vulnerabilities


If that's true, that team is obviously under no obligation to tell anyone when they find them, not even their employers =)


Open source is great because it can be reviewed by it's peers. Wonderful. But who reviews it? Do you? I know I haven't pored through the source for the SAMBA tarball I just installed on one of my boxes looking for holes.


Not everyone reads the code, not everyone should. But the fact that you can is a big advantage (I actually had to change something in the Samba src once). You (and most people) rely on the Samba developers to review each other, just like when I see a patch posted on lkml a handfull of people flock to it and say whether the patch looks correct or does stupid things, I would expect the same to happen with Samba.

2.5G language (1)

Rovaani (20023) | more than 11 years ago | (#5606933)

Last semester I took a Java-programming course and a course on processor architectures. The latter had me doing a simple program on MIPS R3000 assembler.

This semester I decided to take a C-programming course. At the first lecture the speaker raved about how every possible platform has a C-compiler and how C is 2.5 generation language 2G being assembler and how it was so very good.

To my complete shock he was right. Comparing to my last semester experience C is much closer to assembler than for example Java.

I agree with the original article: for the most part you do not need the extreme speed of C. The maount of time you spend with debugging memory leaks and taking care of buffer overflows could be much better spent creating new features or debugging logical flaws. C is great for device drivers or kernel but let's leave it there!

Re:2.5G language (1)

usotsuki (530037) | more than 11 years ago | (#5607044)

You can get even closer to ASM with some compilers which let you diddle registers, raw-access memory and I/O ports and call interrupts.

Turbo C r0x0r!

That's an absolute *must* if you're writing for CP/M-86, by the way, where there is no Turbo C runtime. *g*

-uso.

Re:2.5G language (1)

transient (232842) | more than 11 years ago | (#5607066)

The maount of time you spend with debugging memory leaks and taking care of buffer overflows...

This diminishes with experience. I write apps for Palm OS, where bare-metal programming is the only logical choice (this is beginning to change with better processors but it's not there yet). I've been programming in C for ten years and I rarely spend more than thirty minutes on memory management errors over the course of an entire release cycle, if at all.

I haven't done much OOP -- mostly just Objective-C stuff on NeXTSTEP and OS X -- but I can say that memory management is a relevant concern in high-level languages too. It's just a different flavor of memory management, with reference counts and retain/release messages instead of handle locking. Both levels have a "null" concept and its associated dangers.

Languages have their place and I agree with the article that mail clients and IRC apps probably shouldn't be written in C. Unless, of course, you're writing them for a platform like Palm OS. And let's not forget that someone still has to write your virtual machine. ;-)

Re:2.5G language (1)

vrmlguy (120854) | more than 11 years ago | (#5607127)

And let's not forget that someone still has to write your virtual machine. ;-)

So obviously, we should write everything in Z-code, which runs on possibly the most portable virtual machine ever created [inform-fiction.org] .

Re:2.5G language (1)

Shillo (64681) | more than 11 years ago | (#5607106)

I strongly disagree with the article. I can tell you for *sure* that neither my C nor my C++ code suffer from buffer overflows. How do I know? Because I don't use buffers. For a lot of my C code I don't even allocate my memory by hand (I'm a proponent of garbage collection, and yes, it can be done in C); for a lot of my C++ code, I don't even bother - STL handles most of my memory management needs, some strategically placed magic classes handle the rest. Furthermore, most experienced C/C++ programmers also do these kinds of things.

What's becoming the real issue is that more and more subsystems are getting integrated into larger chunks. On Windows, the integration is a major marketing point, and also an endless source of nightmares, since the systems that work just fine on their own begin to interact in unpredictable and dangerous ways when linked. This is beginning to happen on Linux, with the similar effects; however, most programmers are smart enough to know when the integration gets dangerous.

Basically, most modern OSes are becoming more complex than we can fathom. Hence the breakage, regardless of the programming language.

--

Are languages neccessarily the problem? (1)

pldms (136522) | more than 11 years ago | (#5606939)

If coders must use C or C++ for everything, there are tools to make these languages a little less dangerous: WireX's StackGuard and FormatGuard come immediately to mind, as do various high-level string libraries.

This part intrigued me. It seems like most of the issues are with the libraries (libc in particular), not with the languages. Forgive my ignorance here (don't do much C) but IIRC there are safe and unsafe ways to copy strings, for example.

The author seemed to be advancing a stronger argument (against C and C++) but this suggests a weaker (but still valid) one.

Not just libraries these days... (1)

Tom7 (102298) | more than 11 years ago | (#5607052)

> This part intrigued me. It seems like most of the issues are with the libraries (libc in particular), not with the languages.
> Forgive my ignorance here (don't do much C) but IIRC there are safe and unsafe ways to copy strings, for example.

Though the libraries are partially at fault (printf is a big one), it's not just strcpy any more. It's easy to grep source code for unsafe library functions and replace them. Buffer overflows these days are usually in programmer-written parsing routines (recent sendmail bug), and other bugs like integer overflow (sshd, sunrpc, etc.) and double-free (zlib) are also manifested independently of the libraries.

He's right, though: a safe language like O'Caml, SML, or Java would make these bugs impossible to make. Writing code in a higher-level language also gives the programmer more time to work on other important things, like the security holes that a compiler can't block automatically! O'Caml and SML (depending on the compiler), for their part, are pretty fast and lean too.

This guy doesn't get it. (3, Insightful)

Omkar (618823) | more than 11 years ago | (#5606951)

"In an age where processing power is cheap, there's no excuse for a mail client written in C or C++."
This sounds like Microsoft's philosophy - bloat because we can afford to.

Re:This guy doesn't get it. (1)

Deacon Jones (572246) | more than 11 years ago | (#5607026)

Not sure about "bloat" ( I don't write anything detailed in either C/C++ or Java), but I am sure about this:

Java proggies run slower on my computer than C/C++ proggies. Guranteed. I know that Java speed is a source of flame wars, but as an end user more than a programmer, I can tell you, I always dread downloading something that is a Java util...b/c it will 9/10 times run slower than an equivalent program in another language.

And, as bad as this sounds, plenty of us will take the security risks and go with speed.

Re:This guy doesn't get it. (1)

Reinout (4282) | more than 11 years ago | (#5607084)

A higher level language doesn't mean "bloat".

Bloat means heaping unneeded functionality upon unneeded functionality. I'll assume instead that you'd put the same functionality in the c and in the python/ruby/whatever mail client. So it isn't a fair comparison, "higher level language" = "M$ bloat philosophy".

Secondly, C is high level compared to assembly or machine code. But everyone programs in C or higher and only uses assembly for the 1% in the code where it does matter (if any). Likewise you could do everything in python and just code the small performance-critical part in C. Parts of python are already programmed themselves in C, like hash tables and xml parsers. So they've probably already taken care of that 1% of your code that could benefit from C.

Likewise, people are calling xml (with all those tags) bloat compared to a binary format. On the one hand you can compress it (into binary...) like there's no tomorrow. On the other hand it is needless optimisation to try to squize half a kilobyte of an xml message when you're downloading 3 iso's full of movies at the same time. Optimise where needed.

Reinout

C & Perl (1)

Rovaani (20023) | more than 11 years ago | (#5606956)

I believe Perl is so liked because it gives the programmer a similar level of freedom than C when coding applications, but removes the tedious dynamic memory allocation and buffer overflow preventation.

The fault is not in perr-review... (1)

Ooblek (544753) | more than 11 years ago | (#5606999)

Actually, the bugs are coming out because use of the software is increasing. The more the software is used, the more the different code paths are traveled in varying ways. When a particular code path or set of input data is invalid, then you can find the bug. You can peer-review all you want, but no one can find 100% of all bugs. You can only fix bugs you know about.

If anyone has ever written a piece of software, they should be able to tell you that they always found bugs while the software was in production. Commercial software houses often try to recreate random environments by having a variety of computers configured in a variety of ways so that these types of unknown issues might get caught. This is fairly random, but it can work to some extent. Does this mean that all in-production software systems should or will be defect free? Not at all.

There will be people out there that will argue that in-depth analysis of all algorithms and code paths should be done before software is written. This is not very practical since much of a problem domain is unknown when the software to solve the problem is written. Like if you ever interview for Microsoft, they always throw that proof question at you as if it is going to reflect in any way on your skills. I've thought that this is why they have so many problems. They hire the people who can solve a problem when the entire domain of the problem is known, as when the information in these proof questions is presented. The problem here, however, is that the problem domain for software changes as the software is being implemented. You also miss out on people who think outside of the problem domain to see if there are certain situations that can invalidate the facts of the given problem domain.

Are he forgetting? (1)

runswithd6s (65165) | more than 11 years ago | (#5607005)

...about the recent paper detailing the cracking of a JVM [slashdot.org] ?

Of course he is, because that would make the article larger in focus than what he wants, which is to push buttons. C may be a riskier language than some, but even the big-dog interpreted languages have their own problems.

Re:[is] he forgetting? (0)

runswithd6s (65165) | more than 11 years ago | (#5607031)

...grammar take two.

Safe != interpreted, and 'cracking' JVM irrelevant (1)

Tom7 (102298) | more than 11 years ago | (#5607178)


OK, chewie, what the hell does that mean?

First, a safe language does NOT have to be interpreted. You can statically compile most of Java to native code -- you'll still have all of the class checking, but there will be no virtual machine, no JIT overhead, and the result will be fairly lean. Java is far from the best though -- SML (see mlton) and O'Caml both produce fast lean native binaries from safe language source.

Second, the JVM "cracking" is totally irrelevant here. The scenario described in that paper is that you have physical access to the machine *and* the ability to supply the program to run. What that translates into here is a hacker saying, "Hey, can I come over to your house, install this Java irc daemon that I wrote, and then shine a lightbulb on your memory?" What we're ACTUALLY talking about is software written by a programmer who intends to make secure code, and a user who doesn't want to corrupt his memory. (In any case, C or C++ or essentially any other language would be just as vulnerable to security holes in a scenario where memory is randomly corrupted.)

So, what are you talking about?

Very little would change (1)

WeaponOfMassDestruct (657948) | more than 11 years ago | (#5607019)

I agree with the author in that choosing C or C++ over Java, PHP, or some other modern language today doesn't make a lot of sense. Not that there aren't legitimate reasons to use C, but I think it's reasonable to take the approach that when starting a new project we'd assume that a modern language is the way to go until we can justify using a lower-level language for performance, or other reasons.

However, I'm not sure that using Java-based apps would decrease the instances of security holes. Building security into applications is still inherently hard to do, no language can completely isolate the programmer from having to think and design for security and there will never be a sudden epiphany by every developer in the world that they have to spend time on security when they have deadlines to meet.

HLL's are NOT a substitute for secure programming (3, Insightful)

lildogie (54998) | more than 11 years ago | (#5607030)

Please, spare me from the armchair drivel of these SecurityFocus columnists! (Okay, I should spare myself, but I'm compelled to comment.)

The thrust of the article is that most programmers are not skilled enough to write secure code, so they should be using HLL's that do the security for them, and leave C/C++ code to the "experts."

Hogwash.

Repeat after me: Security is a process, not a product. HLL's can be misused just as effectively as LLL's.

Back to this columnist's soapbox rant. It ends up reveling in an admittedly fallacious comparison:

> Real programmers manipulate the system at the lowest possible level,
> for the maximum possible effect.

I'll accept that, in the diversity of programmers, there are some that are writing insecure code. But stereotyping of this sort is an act of the columnist. Even if there are some programmers who adopt this stereotype, they do not nearly comprise the entire population. The existence of many professional, responsible programmers is completely discounted by the columnist.

> The fallacy of the comparison should be obvious...(
> I think it's safe to say that programmers spent less time at
> self-criticism than pilots.)...

It's safe to say in the one-way communication of the columnist's world. It's safe to say when your profession is to write sassy, not-too-verifiable copy. It's safe to say if you don't have to have your article vetted by fact-checkers.

> It would be nice if we could expect that our programmers would act
> more like airline pilots than fighter pilots: that they acknowledge,
> and accept, the responsibility that they take for the well-being of
> others. Until they take this step, I doubt that the quality and
> security of the code that we all rely on will improve.

Here the columnist exercises the same comparison he recognized as fallacious. Programmers are not pilots. Not airline pilots, not fighter pilots. While I believe there is a need for the computing industry to move towards more responsibility for security, focusing just on C/C++ programmers will not do the job. There is plenty of improvement to be made by the end users, and the columnists as well!

> There is also a macho streak in programmers:

There's a macho streak in this columnist who disparages professions that he probably hasn't been participating in as of late.

Pfft!

Problems (2, Informative)

evilviper (135110) | more than 11 years ago | (#5607032)

Well, he wants everyone to write everything in perl, except for the fact that he brings up, that perl is just as insecure itself.

So what will everything be written in??? Every part of the OS in java? Nevermind the performance, and the lack of a good, Open Source JVM/JDE.

If you want secure programs, start putting strong-typing, and other security measures into GCC. You can't have a string overflow if GCC checks everywhere data is input, and makes sure the input can be no longer than the string...

A bit different, but it deserves to be mentioned that OpenBSD 3.3 (which will be released VERY soon-already tagged), has numerous protections as described here, by Theo [theaimsgroup.com] . Yes, that's right... OpenBSD has been doing the job before Lasser even lifted a finger to complain.

PORK FAT USED TO LUBRICATE IRAQI WOMEN (-1)

Anonymous Coward | more than 11 years ago | (#5607037)

Copyright 2003 - Al Jew-zeera Newscorp.

KUWAIT CITY -- Pork fat is the number one choice of lubricants for the unit of American soldiers assigned to rape Iraqi women.

"It tastes great, and it helps us slide our cocks right into their quivering assholes" states Lt. John Holmes. "Those hairy smelly bitches are so uptight that we need something that is really heavy duty to drive home the point that Americans really are superior to these rag-head camel jockeys."

Questions about the insertion of the unit of the U.S. Army's Special Forces Rape Battalion raged in the arab world. Haji Mubarak, spokesman for Arabs Supporting Saddam (ASS) stated, "Only we are allowed to treat our women like shit! Now they will have a taste of two forbidden fruits -- long, thick American cock and pork! This is an insult to our culture! Jihad! Jihad against the Americans!"

Gen. Tommy Franks refused to answer questions about the issue at the CENTCOM briefing given yesterday at headquarters in Qatar. "Who gives a fuck about those sand niggers? It can only improve them as a people. I just hope those men who get crabs from those filthy arab whores get the Purple Hearts they deserve. They are really going into harm's way. They should be grateful we haven't stolen the Kaabaa and turned it into a cruise missle."

Amnesty International decried the unit's deployment. Spokeswoman Jennifer Stover stated, "This is clearly a violation of the Geneva Convention. The use of pork fat as a lubricant when raping muslim women is extremely offensive to notions of islamic culture. Besides, ever since I've been involved with Amnesty International, I haven't been able to find a good man anywhere. I want the first shot at those American cocks myself. Jesus, I could use a good fucking right now. These faggoty pacifist lefty men I work with can't get it up unless you go through the whole "dominant Hillary" scene with them. It's such a fucking drag."

Al-Jewzeera Reporter Rocco Genovese will be embedded with the U.S. Army's Special Forces Rape Battalion. His reports will be available from the field on our website and in the upcoming gonzo video series, "Dirty Arab Sluts of Iraq".

Too Busy for Secure Code, Unfortunately (3, Insightful)

grokBoy (582119) | more than 11 years ago | (#5607042)

"Why do we still see these bugs?"

Well, perhaps its because of one of the following reasons:

1) Too many programmers aren't granted adequate debugging time by companies who'd rather get any code to market on time rather than test it thoroughly and miss deadlines.
2) How many programmers do you know who actually know how to audit code for security issues? How many companies are going to invest time and effort (and money) in hiring these people (or training their own?)
3) As people learn new languages, do they learn secure practices too? No, they learn how to write functional code. For some, thats enough to get the job done.

"In an age where processing power is cheap, there's no excuse for a mail client written in C or C++."

How about portability? Or efficiency? Or the fact that the guys writing the code would rather work on the mail client than go and learn a new language first? If they are writing bad code in a language they have been using for years, why move the problem to an area where they have even less expertise?

Writing secure code is a black art to many, and we can only hope that peer review and open source will help to spread the word amongst today's developers.

Bullshit? (1)

Carewolf (581105) | more than 11 years ago | (#5607049)

Another guy that doesnt know what his talking about, because he has a Microsofty point of view.

What does he mean that the speed of an emailprogram is not important? What kind of bullshit is that? Email programs are database like programs that sometimes deal with huge amounts of data. (My email-archive is several times larger than my databases). The problem with email programs is infact that they start small and efficiency is not considered, and then when developers start using them for real they start choking on 3000 messages per day and 600Mbytes archive of linux-kernel in your inbox.

The people who using Linux on desktop(for real), are not the same people that uses Microsoft on the desktop. The workloads are different and in many cases especially mail-programs, every bit of performance matters because it is already horribly slow.

Re:Bullshit? (2, Insightful)

Carewolf (581105) | more than 11 years ago | (#5607109)

Bad style to reply to your own comment, but what the hell.

In my previous comment my arguments for calling the article bullshit was a bit weak. Here are some more:
1. The programs and security-flaws he mentions are stuff like: linux kernel, openssl and mysql.
2. He proposes to solve the problem by using higher level (and he admits: slower) programming languages.
3. So is he suggesting to write the Linux kernel in Java, OpenSSL in Perl and an database in Visual Basic?

What is this guy smoking, and can I have some?

Right idea, wrong solution (1)

vrmlguy (120854) | more than 11 years ago | (#5607075)

You said it yourself: "Neither programmers nor system administrators like diversity in the underlying environment: it makes debugging much more difficult." So, the solution isn't to switch en masse to Java or Perl; the solution is to make it harder to write insecure code in gcc. No one should be using sprintf anymore, so why doesn't its use triggers a warning of some sort? For instance, have libc only export "unsafe_sprintf", and have stdio.h #define sprintf to that *and* emit a #pragma warning each time it's used.

Hmn. (1)

Eudial (590661) | more than 11 years ago | (#5607082)

Nobody is perfect, if you want all that secure code: Write it yourself.

I Concur! (1)

YetAnotherName (168064) | more than 11 years ago | (#5607092)

I routinely get into "discussions" with old coworkers about how I can possibly stand my job, which is largely Java-related. It's plenty fast for my tasks (I'm not streaming video), and pretty darn secure. I just sort of sit back and smirk as they rip what little hair remains from their heads struggling to figure out why the vtable gets corrupted on a certain long-lived object but only after an uncertain number of events.

Moreover, my productivity is three times better than with C/C++. (Measured back when I used to have to do Personal Software Process stuff.)

Yes, it's fun to twiddle bits and trap into kernel space by hand sometimes, but dammit, I've got deadlines. I've got to focus on the application if I want to get paid.

I beg to differ (1)

truth_revealed (593493) | more than 11 years ago | (#5607096)

The article's author states:
For users accessing mail via IMAP or POP, network speed and congestion have a greater influence over performance than anything done on the client side; even for users with local mailboxes, I doubt that we're looking at a huge performance hit.

I beg to differ. I use email a lot - as do most people. I need it to be lightning quick in handling multi-megabyte local mailboxes. Basically, he could not have thought of a worse example of where performance supposedly does not matter since modern email repositories resemble databases these days. I am not willing to give up performance for perceived security in this area. Yes, that's right - performance and ease of use are every bit as important as security. Security for security's sake is simply not good enough. Users expect more - they expect both security and performance. You cannot give them less than what they already have. If the C or C++ code has a flaw - you fix it - it's that simple. OpenBSD has been doing this for years. Yes, it takes extra work - but the results are well worth it. Just don't give me this crap that my critical applications have to written in some interpreted or sandboxed computer language which takes up 4 times the memory and runs at less than half the speed all just for supposed security's sake. Show me this magical machine that can make all interpretted code run lighting fast and I will show you a machine that can run twice as many compiled applications over three times faster.

The problem is... (1)

robbo (4388) | more than 11 years ago | (#5607100)

most of the most serious vulnerabilities (in things like the kernel, tcp stacks, libc, high-traffic web servers, etc), *need* to be written in a low-level language for reasons of efficiency. While I agree that it probably makes sense to re-implement lpd in perl or python or whatever, we will always need core services to be written "close to the metal".

That being said, I think ANSI should revisit printf and find a way to fix it. Any compiler can do a good job at type checking, and it should be possible to print without all the % madness.

Comments on the page . . . (1)

xyrw (609810) | more than 11 years ago | (#5607105)

Anyone else read the comments on the page?

This is the most idiotic text i have ever read. Next time you lack a topic to write about, by all means drop a note to bugtraq, i'm sure that collectivelly we can come up with something more compelling than this mindless rambling of fighter pilots and "coders".

. . . and . . .

Not sure what exactly you are suggesting would be better than C/C++? Java? PHP? PERL? C#?

These comments entirely miss the point: I think Lasser's main point is that programmers need to focus more on security instead of being lulled into a false sense of security, and that it is the quality of code and not the tools used that make a system secure.

A related note on Linux security vs Windows security: yes, Linux is `inherently more secure' than Windows; no, Linux is not inherently secure. (I know most /. readers know this, but there is sometimes the tendency to fall into a `security high ground' trap.)

In short, carefully consider what Lasser has to say-- he's no fool on the subject of security. [bastille-linux.org]

Secure Programming HOWTO (1)

spydir31 (312329) | more than 11 years ago | (#5607112)

Here [tldp.org] 's the Secure Programming for Linux and Unix HOWTO, good reading IMHO,
alternately here [dwheeler.com] .
(Hopefully on-topic :)

Summary (1)

RadioheadKid (461411) | more than 11 years ago | (#5607146)

C sucks, C++ sucks, PHP sucks, Perl sucks, programmers suck (I'm not a programmer, but trust me they suck) and there may be tools to make them not suck, about which I know nothing so I'll just use this lame-ass fighter pilot analogy instead. Vote Quimby.

WHAT THE FUCK? (-1)

Anonymous Coward | more than 11 years ago | (#5607147)

I get errors trying to post to *.slashdot.org, but not slashdot.org.

C is a low level language? (1)

FuzzyBad-Mofo (184327) | more than 11 years ago | (#5607154)

I guess he didn't get the memo. Real programmers use assembler! ;)

ego (1)

BigBir3d (454486) | more than 11 years ago | (#5607163)

I never knew ego was such a problem for humans.

</sarcasm>

java (1)

edyavno (190451) | more than 11 years ago | (#5607168)

While Jon mentions Java once, I think it deserves more praises, especially when you talk about high level languages: java security (both virtual machine and the language) is so tightly implemented that there's no known exploit for a java buffer overflow. The worst that can happen to a java server is JVM can crash. This is solvable by a mere JVM restart, and nowhere close to gaining control of the box it's running on.

it's not really the language that's the problem. (2, Informative)

Kunta Kinte (323399) | more than 11 years ago | (#5607169)

It's bad programming habits and the lack of tools that catch those program time errors.

Static analysis, the use of programs to analysis code that has not been compile completely to machine code, has historically been undeveloped in open source. I use to have a list, was my research focus for a while, but basically we have one decent static analyzer Splint [splint.org] , and it's not that hot compared to commercial offerings.

For instance the HANDS group from stanford has tracked down lots of kernel bugs using their in house analyzer, in lots of obscure places. MS has an in house program I hear they guard closer than the kernel itself! I have a friend that did kernel work for them that agreed with this, they give him the kernel source but not the ananlyzer binaries even. The guy who wrote it, known in pointer analysis circles often goes on about how he's found tons of bugs in open source projects ( bet you he's not filing bug reports )

There are lots of groups working on static analysis, but no one wants to open source their code.

Hind, Michael http://www.research.ibm.com/people/h/hind/ [ibm.com]

Hind has written amongst other things probably the best and most recent introductory papers on pointer analysis at http://www.research.ibm.com/people/h/hind/paste01. ps [ibm.com] .

stanford checker [stanford.edu]

SUIF compiler suif [stanford.edu]

I had a few other links, but the lameness filter is complaining about "too many junk characters". You'd think slashcode would have a better filter by now.

This guy is talking out of his ass (1)

I_redwolf (51890) | more than 11 years ago | (#5607170)

I got maybe halfway into it when he started talking the same old bullshit about higher level languages etc etc. His intro "Until Unix and Linux programmers get over their macho love for low-level programming lanaguages, the security holes will continue to flow freely."

Sure, but ummm the same goes for every other programmer. Just not Unix or Linux programmers. What about your favorite Windows programmers? Is not their system based on a low level language? Even in comparison to high level languages the security holes still flow freely on that platform.

Then the author took the time to point out security holes in popular unix software. I'm glad he did this because you couldn't do the same for other systems. All in all the author is reinforcing the fact that here in nixland we have stronger peer review than anywhere else. We hold each other to as critical standards as possible and are happy to find errors in others code not just for the hell of it but because it makes all of us safer.

Next he talks about the programmer given up his ability to control a system by using higher level languages. That's cute but sadly in this field to become the best you have to understand the low-level stuff and they happen to be techniques and are not language specific. Moving memory around or conserving it is a technique and not a black magic art. Once you learn it you can apply the idea to other low-level languages you encounter. Writing a new algorithim at the lowest level possible isn't some black magic art it's a technique and can be taught to others.

I'm not saying that writing an email client in C is good or bad but the choice is of the programmer and not for you to make Mr. Lasser. That's the whole point of this OpenSource thing and as the particular package becomes more useful and needed in this community it will encounter more peer review than anywhere else. People can learn from others mistakes and hopefully we end up with better, more featureful and more secure code. Surely this has been happening for quite sometime now. In comparison to other closed systems where the amount of security holes are theoretically infinitely higher than the community we work within. The answer is clear; your take on it? Instead of writing an email client in C write it in perl? It doesn't matter.

Linux Unsecure? (-1)

Anonymous Coward | more than 11 years ago | (#5607189)

That's unpossible!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?