|
Interesting Security Article
It looks like C sucks. The OS holes go hand in hand with the use of C
http://www.theinquirer.net/?article=13420
Mike
Tuesday, January 13, 2004
I disagree that C sucks.
Security is a design issue. The fact that root has ultimate power on an operating system is a design issue. With Linux, there are kernel based role enforcement policies where you can limit the amount of power users have, including the all-powerful root. (And of course, I claim both Windows, and most popular unix implementations have a pretty poor design with regards to security in their default distribution states.)
Common issues, such as buffer overruns, can be mitigated. Compilers can reorganize data blocks to prevent these attacks, run-time kernel agents can detect these attacks, and Athlon has even introduced processor mechanisms to prevent such attacks. It would be nice if a standards group came out and said, "all ANSI blahblah C compilers shall do this to mitigate the problem of buffer overflows..."
The numbers in that article are also suspect. I only recall a few major security issues in 2003 with regards to FreeBSD 4.x at the kernel level. At the application level -- well that's a different story.
SG
Tuesday, January 13, 2004
SG is correct, it is a design issue and the numbers are suspect. While they total correctly, that a product in a distribution results in an Cert entry, the same is not true for windows. If your copy of ZGAFFAXXS for Windows causes security problems, they are not associated with windows.
That being said, the conclusions are somewhat tired. Yes, if everyone did a better job the world would be a better place. The same can be said for just about any aspect of life. Until the cost overruns the benefit and there are alternates to be found, we get what we pay for. Few of us would be willing to pay for MS to rewrite a secure operating system. Who could afford it at $1000 a copy and we would slam MS for doing it as a poor use of corporate resources.
We have met the enemy and it is us.
MSHack
Tuesday, January 13, 2004
What other language are you going to write an OS kernel, file systems, network stack, iptables/firewall, etc. in?
hoser
Tuesday, January 13, 2004
"What other language are you going to write an OS kernel, file systems, network stack, iptables/firewall, etc. in?"
It looks like Assembly and Pascal work. I believe VMS is a smattering of Assebly, C, and some others. I don't think C is a bad language. It does look like C makes it easier for programmers to make security mistakes than the other languages. If you can fix C compilers to watch for overruns etc, then great, but if not isn't it smarter to use a language less prone to it?
Mike
Tuesday, January 13, 2004
What language are you going to write a C compiler in ... assuming you don't have a C compiler to start off with?
Assembly had to bootstrap C. C now bootstraps other languages. But for the majority of modern-day coding, C is the wrong tool for the job. It's just too low-level.
Alyosha`
Tuesday, January 13, 2004
If you're developing a system where you are concerned about security, the goal is to limit the scope of damage caused by a faulty component. Programmers will make mistakes, it is inevitable. This element of secure systems design has been around almost as long as I've been alive, and was the basis for the NSA's "Orange Book" criteria.
OpenSSH had a classic example where this proved effective. Recently, they implemented privilege separation between the parent and child processes. The child process changed its uid/gid to an unused user, and put itself inside a chroot()
jail, and would be the only entity handling user-data. The interface between the parent-child was then well established, and the behavior of the parent was then made relatively predictable. Needless to say, when the latest OpenSSH bug was found -- one of the solutions was to turn this feature on.
http://www.citi.umich.edu/u/provos/papers/privsep.pdf
There are lots of language independent security issues that come up, and are just as bad as a buffer overflow: race conditions, faulty trust metrics -- leading to issues with cross site scripting, badly designed cryptographic frameworks (bad use of certificates, poorly implemented key exchange policies, etc), remote code execution, etc... Most Windows e-mail viruses aren't taking advantage of buffer-overflows in code -- they're taking advantage of trust relationships between you and your email, and your email client and the vbscript it contains.
You can go ahead and rewrite Win2K's TCP implementation in whatever language you feel like -- but I still know of a way to hijack any session based upon a statistical weakness in their ISN generator.
SG
Tuesday, January 13, 2004
Well, since nobody mentioned this yet, take a look at http://www.research.att.com/projects/cyclone/
"Cyclone is a programming language based on C that is safe, meaning that it rules out programs that have buffer overflows, dangling pointers, format string attacks, and so on."
fw
Wednesday, January 14, 2004
This lame article really had very little to do with C, or anything else really, and most of the conclusions that the author makes are completely unsupported. Personally I consider a large portion of the article nothing more than a troll to inspire hits. It truly isn't even worth dissecting such a turd of an article.
Dennis Forbes
Wednesday, January 14, 2004
 Recent Topics
Fog Creek Home
|
