Slashdot Mirror
Too Cool For Secure Code?
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."
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. Yes, that's right... OpenBSD has been doing the job before Lasser even lifted a finger to complain.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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, 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/
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.
stanford checker
SUIF compiler suif
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.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Try Aleph1's excellent article from phrack.org:1 4
http://www.phrack.org/phrack/49/P49-
Use source analyzers to find common mistakes, here are a few
Flawfinder
RATS
ITS4
Splint
also look at Splint's Links page for more on the topic
chrooted services don't prevent break-ins. They prevent/reduce damage done after the break-in.
With some security holes, a chrooted daemon can't be cracked where a non-chrooted daemon can, because the exploit does something like invoke /bin/sh, but that just means that the exploit needs to be altered somewhat to do something other than just invoke /bin/sh.
Don't get me wrong -- chrooted daemons are more secure than non-chrooted ones if done properly -- but their purpose is not to prevent break-ins, but to reduce their damage.
If everything is done right, when you exploit a chrooted named daemon, you've got access to a few files that named needs, and nothing else. Yes, your system has been broken into, but all they can do is muck with your named.
If they break into a non-chrooted named daemon, they've got full access to the system. Depending on how things are set up and how they got in, they may be root, or may be another account. But either way, they're in and can now poke around and look for other things to do.
The basic problem was that file i/o is slow in Emacs Lisp.
This is like saying that a particular implementation of the C++ STL is slow, therefore C++ is slow. You can't blame the high level language for a particularly crappy implementation. Emacs Lisp is so famously bad that even Lisp programmers won't touch it.
That said, I still stand by using high level languages for these kind of applications. These days you can write a well-designed program in Python that appears lightning fast and a poorly designed application in C that's several times slower, despite being compiled to native code.
This is a bunch of hogwash. This guy sounds more like a MS rep than a security-focus programmer. Because RAM and CPU is so cheap now and so powerful, it doesn't matter if we write crappy bloated code? That's such bullshit. Consider that writing crappy bloated slow code in fact reduces system stability, by adding to CPU and RAM strain. Just as a security breach can result in data-loss, so can a system or program crash.
And, if this author not know, not everyone is buying the latest 2GHz CPUs. For most people's needs, a 100MHz PC is still fine and dandy -- that is, unless fuckwits like him and the genius' at MS continue to make ever-more bloated and slow code.
And why is RAM-usage so important, even with typical PC's having 256MB of RAM? Well, apparently this guy is still stuck in the good old one-program-at-a-time days. People run many programs concurrently -- the more resources each one takes up, the less happy the user is, because that means everything is slower overall, and may even mean the system has to switch over to virtual memory.
And why is it that we always get complacent jackasses like this always assuming that speed, memory-usage, stability, and security are always inversely related to one-another? They aren't. For the most part, writing smaller faster code isn't necessarily going to make the program less secure, nor is writing more secure stable code going to make it perform worse. There a *few* specific cases where there are trade-offs: in those cases, it's up to the programmer to decide what's best based on his target audience. If he's targetting home-users, a little bit of security can be sacraficed for increased performance. If he's targetting business users, a little bit of performance can be sacraficed for security. Stability is always a priority.
Alas, I'm sick of hearing "this programming language (C) is faster than that one (Perl), and assembly is faster than them all". Programming languages aren't "fast". Assembly allows a programmer to produce very highly optimized, fast, code. However, poor assembly will run much worse than C compiled with GCC. Comparing C to other languages, C programs tend to be faster because C allows for more direct control and compilers have had more time to be optimized. I doubt other languages will ever catch up to C in that regard, but a crappily written C program will still be beaten by a well-written Perl programmer (personally, I suggest Objective-C, because it provides OO with only a few additions to C).
social sciences can never use experience to verify their statemen