5,198 Software Flaws Found in 2005

An anonymous reader writes "Security researchers uncovered nearly 5,200 software vulnerabilities in 2005, almost 40 percent more than the number discovered in 2004, according to Washingtonpost.com. From the article: 'According to US-CERT...researchers found 812 flaws in the Windows operating system, 2,328 problems in various versions of the Unix/Linux operating systems (Mac included). An additional 2,058 flaws affected multiple operating systems.'"

Comments

Axe Grinding

[alanw]

Brian Krebs is clearly either extremely stupid, or has an axe to grind. If you look at the Cert Cyber Security Bulletin 2005 Summary, you can see that many of the lines in it end in "(Updated)" A simple count of lines gives the results that Brian quotes, however there are far more "(Updated)" entries in the Unix/ Linux Operating Systems section. Removing these lines gives the following results:
including excluding
"(Updated)" "(Updated)"
Windows 813 671
U/L 2328 891
Multiple 2057 1512

(sorry about the spacing - can't find any way of doing it)

greatly reducing the proportion of Unix/Linux vulnerabilities

Re:Axe Grinding

[ginotech]

That is messed up. You're right, simply updating a vulnerability doesn't make it a new one. You know why Linux and co. have more updated ones, though? Because people can actually see the bugs in the code!

Re:Axe Grinding

[someone300]

Also, isn't this more of a survey of the security flaws of the software running on the operating systems, rather than the operating systems themselves anyway? The summary linked article seems to imply that it's an OS flaw.

7-Zip isn't an OS vulnerability, nor is 4d web star.

Couldn't this be tilted against linux/unix/whatever due to the larger amount of crappy server/networking software available for it?

Re:Axe Grinding

[TrappedByMyself]

Please describe your emotions as
1) You saw the initial numbers
"It can't be true, it just can't be true"
2) You realized there were many redundancies on the *nix side
"YES YES, I knew it!"
3) You started filtering, and the *nix number was dropping alot
"Ha Ha, Woooo!!!"
4) *nix, in the end, still had a higher number than Windows.
"NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!! !!!!!

Re:Axe Grinding

[camcorder]

Also from security perspective I would like to know ratio of remote vulnerabilities on these platforms and how much of them DoS vulnerabilities and more critical compromise vulnerabilites.

It's correct that a DoS vulnerability might be actually more critical as it was thought (as in recent IE bug). I think numbers as such very deceptive. From an user perspective I can say this year brought me lots of stupid worm mails which mostly targeted from Windows platforms.

Re:Axe Grinding

[click2005]

Where is the mention of seriousness of the flaws? How many allow root access or something else serious/critical instead of "clicking this button makes the tool tab disappear" or something.

They also fail to mention that a lot of these flaws are not in the OS itself (or essential components) but in 3rd party software.

A lot of the software isnt even included in a standard installation.

Re:Axe Grinding

[twiddlingbits]

As someone pointed out some of these "flaws" are not OS flaws but issues with application software, and the Severity level are not indicated. So, until the list is sorted accurately it's hard to tell if Win of *NIX was better.

The way I read the results, *NIX list cover the whole set of OSes of this type. There are at least three major versions of UNIX (Solaris, AIX, HP-UX) and multiple releases/versions of each in production. I know that Solaris 8,9 and 10 are all still supported by Sun in 2005 and that is a very big base of installed servers. There are about a dozen LINUX distros, some with serveral releases/versions in production. The Windows numbers cover XP, Win2K, Win2K server, Win2003server. If you count desktops, the Windows installed base is bigger meaning a flaw may affect more users.

However, until someone publishes a more detailed study,with the methodology described, we are ALL just speculating.

Re:Axe Grinding

[jc42]

Hey, you missed the even bigger method of increasing the unix/linux score: counting each distro separately.

Thus, if you go to distrowatch.com, you find 100 distros for linux alone. So for most actual kernel bugs, you can count each one at least 100 times. And for apps that run on all unix releases, the multiplier can be a lot higher.

Of course, there are several distros of Windows, too. But not nearly as many, and the people adding up the bug counts somehow always seem to miss this trick with Windows.

Anyone else got a favorite way of producing misleading bug scores?

Re:Axe Grinding

[pintomp3]

TFA keeps talking about vulnerabilities and flaws interchangabily. a flaw doesn't mean a vulnerability. although i believe updates should be included in the tally, the tally is trivial. few of the unix/linux flaws make your computer vulnerable compared to the windows ones. that is more a design issue though.

Re:Axe Grinding

[TallMatthew]

Evaluating the security of an operating system based on the number of CERT advisories is assinine, err, unreasonable. There's no debate here.

Windows is more secure than it used to be, and you can absolutely make a Windows box more secure than a Linux box, but come on. Any OS that requires (or at least strongly encourages) all applications to be run with full admin privileges is de facto less secure. All these IE/Outlook exploits wouldn't do squat if Windows was Unix-like in that regard. I don't give my grandma root. Redmond does it by default.

If M$soft could figure out a way to separate privs, the Net would be a better place. Their OS architecture, especially that God-awful anything-goes "read me write me 69 me" registry, is killing them.

Re:Axe Grinding

[paving-slab]

...and you can absolutely make a Windows box more secure than a Linux box...

Hey, this is Jan 1 not April 1.

(maybe not where you are, but it's started)

Re:Axe Grinding

[cbiltcliffe]

Anyone else got a favorite way of producing misleading bug scores?

Not so much a misleading bug score, but misleading about bugs nonetheless:

"All the bad guys know about all the bugs in Linux, because they can see the code. But only Microsoft knows about bugs in Windows, and they fix them before anybody finds out."

Paraphrased, of course, but pretty much what every Microsoftie analyst says on a daily basis.

Re:Axe Grinding

[Anonymous Coward]

I guess you could disconnected it from the internet, or use an old computer with IPCop linux as a firewall...

Re:Axe Grinding

[brouski]

I read that to mean you can lock down a Windows box to the point that it's more secure than a default Linux installation.

Re:Axe Grinding

[CDPatten]

I looked at the "updates" and it looked like the same thing was updated more then once. Does this mean that the "updates" where for the same problem and the previous update for the problem didn't work? Or created new problems? Can anyone clarify?

for example:
Apache 'Mod_SSL SSLVerifyClient' Restriction Bypass (Updated)
Apache 'Mod_SSL SSLVerifyClient' Restriction Bypass (Updated)
Apache 'Mod_SSL SSLVerifyClient' Restriction Bypass (Updated)
Apache 'Mod_SSL SSLVerifyClient' Restriction Bypass (Updated)
Apache 'Mod_SSL SSLVerifyClient' Restriction Bypass (Updated)
Apache 'Mod_SSL SSLVerifyClient' Restriction Bypass (Updated)
Apache 'Mod_SSL SSLVerifyClient' Restriction Bypass (Updated)
Apache 'Mod_SSL SSLVerifyClient' Restriction Bypass (Updated)

Re:Axe Grinding

[Anonymous Coward]

"greatly reducing the proportion of Unix/Linux vulnerabilitiies" - by alanw (1822) * on Saturday December 31, @08:32AM

Uh, that's not the point dumbbell - it was to show what had more flaws period.

If they got fixed (most do from any OS period), great!

(The point was to show what turned them up and where, and the fact it turned up that Linux/Unix had more, even though they are technically the same (Linux IS just a Unix 'knock-off') is just hilarious).

Oh, it's amazing how the Penguins scream if a Windows bug is found, but when the shoe is on the other foot and it turns up your stuff is shoddier than Windows is?

You'll even blind yourselves to the truth & facts.

Hilarious - You penguins... you ALWAYS supply me a good laugh here @ slashdot, especially when you're confronted with FACTS, & even try to spread more "F.U.D." to others regarding Windows.

BOTTOM-LINE - ARGUE WITH THE NUMBERS BUDDY, SEE THE TEST FOR WHAT IT IS & SHOWED VIA FACTS REPORTED ON, & ABOVE ALL?

Quit deluding yourself & attempting to do so to others, ok?

APK

Re:Axe Grinding

[PhreakOfTime]

Anyone else got a favorite way of producing misleading bug scores?

Just the tried and true one...

Let Zonk 'write' the story

Re:Axe Grinding

[abandonment]

how is comparing a 'locked down' operating system even worth mentioning in comparison to a 'default' installation of another OS?

this is ridiculous - apples to oranges if i've ever heard of one.

how about comparing a default installation of one OS to another? or a security enhanced version of one to another?

this would be a realistic comparison - but if this is what the original poster implied, then it's such a non-statement that it's not even worth mentioning.

Re:Axe Grinding

[0-9a-f]

Anyone else got a favorite way of producing misleading bug scores?

My favourites for making U/L look bad:

3. Count the number of page hits on community support forums;
2. Count the number of front-page articles on slashdot on the problems;
1. Count the number of comments moderated "Informative" or "Interesting" in Slashdot, on articles about bugs in Linux.

My favourites to make Windows look bad:

5. Multiply the number of bugs by the number of licenses sold;
4. Multiply the number of bugs by the value of licenses sold;
3. Ignore the number of bugs, and count only the cost of additional software and phone calls;
2. Count the number of identical posts in community support forums;
and my favourite...
1. Count the number of comments moderated "Funny" or "Troll" in Slashdot, on articles about bugs in Windows.

Re:Axe Grinding

[irc.goatse.cx troll]

"As someone pointed out some of these "flaws" are not OS flaws but issues with application software,"

There is no 'third party software' because there is no first party. It's all community, and if the OS ships with it, its the OSs responsibility. What is 'part of the OS'? Linux kernel flaws? I'm sure everyone that gets owned by a firefox buffer overflow is going to be greatly relieved that the attack vector wasn't part of the OS so didn't really count. How many windows flaws are kernel related vs software that came on the cd? how much 'third party software' comes on a debian dvd? Why is it any different if microsoft wrote both or if the community wrote both? Especially with a distro that patches their packages seperately (debian, openbsd, etc)

Re:Axe Grinding

[pjrc]

Anyone else got a favorite way of producing misleading bug scores?

How about claiming the counts massively inflate Linux bugs by duplicating distributions, when in fact the actual list does nothing of the sort. Scroll down to the Linux section, and notice how nearly all have "multiple vendors", when the bug impacts mulitple distributions.

As someone pointed out earlier, the updates were counted though, and which does inflate the linux sum quite a bit.

Re:Axe Grinding

[drsmithy]

Any OS that requires (or at least strongly encourages) all applications to be run with full admin privileges is de facto less secure.

Windows neither requires nor encourages such a thing. Ignorant, incompetent and/or stupid software developers do.

I don't give my grandma root. Redmond does it by default.

"Redmond" isn't managing your grandma's computer, they're selling a piece of general purpose software.

If M$soft could figure out a way to separate privs, the Net would be a better place.

They did that over a decade ago.

Incidentally, the next time you're exercising your inner seven-year-old, the '$' is meant to replace the 's', not supplement it.

Their OS architecture, especially that God-awful anything-goes "read me write me 69 me" registry, is killing them.

Their OS architecture is superior in nearly every way to its contemporaries.

Re:Axe Grinding

[cuerty]

Isn't just that, the straight comparation Windows Linux/Unix it's wrong since Windows it's an operating system and the Linux/Unix "bugs" are all related to the software in Linux.

Ok, so you count Office bugs as Windows ones, perfect, you are in just one software against the diferent options in Unix, there it's a different universe of choices and options that make the number of bugs discovered a stat about how much secure is one or other software.

Re:Axe Grinding

[fuzza]

"... and they fix them before anybody finds out."

If only that were the case...

Re:Axe Grinding

[Anonymous Coward]

And now, for some more Psuedo-Statistic fun, we multiply those numbers in regards to how many people use each OS. /me pops open Excel

Tap-a tap-a tap-a..... Just so those of you at home can follow, I'll be using a simple multiplication formula to divine my numbers (i.e. A1*B1 stylee)

And just so you know, I'll start of at the top of the list.

- A few seconds later: BSOD!!1!1!!!eleventy!!!lolz

Re:Axe Grinding

[TallMatthew]

Their OS architecture is superior in nearly every way to its contemporaries.

Wow. I mean ... wow. Unbelievable what you read on here sometimes. You go with that, dude. My hat is off to you.

Next thing you tell me some dude that died 2,000 years ago is making the world go round.

Re:Axe Grinding

[drsmithy]

Wow. I mean ... wow. Unbelievable what you read on here sometimes. You go with that, dude. My hat is off to you.

Well, if I'm as wrong as you seem to think, it should be pretty easy for you to come up with, say, ten examples of where Linux and/or OS X are architecturally superior.

Re:Axe Grinding

[Mr Europe]

It's stupid and misleading to combine all Windows OS'es in one pile and the rest in the other.
See the http://secunia.com/product/ for clearly categorized advisories.

The amounts "Unpatched" of "Total advisories"
  25 109 Microsoft Windows XP Home Edition
  29 124 Microsoft Windows XP Professional
  14 63 Linux Kernel 2.6.x
  0 2 Ubuntu Linux 5.10
  1 182 Debian GNU/Linux 3.1
  0 84 Fedora Core 4
  0 230 Mandrakelinux 10.1
  0 63 Apple Macintosh OS X
Notice that some OS-versions are older than others. (The total count should be divided with the time.)

Of course the criticality should be counted too.
I checked Linux Kernel 2.6 unpatched vulnerabilities and none of them can be used remotely, 7 (of 14) was DoS and 7 where the local user could potentially escalate privileges or get sensitive information.
Of the Win XP Home Ed I unpatched vulnerabilities 11 out (of 25 total unpatched) could be remotely exploited.

Linux-distribution advisories include advisories of all software not just the OS-specific (as is the case with all Windows-os advisories).

Based on the above I come to the conclusion that Brian Krebs is either spreading FUD intentionally or plain stupidity.

The state of security

[Ckwop]

There's two ways to look at this. I would say that it is quite unlikely that the quality of software with respect to security went down in 2005. Computer Security now has such high profile that software houses across the world are spending many dollars trying to provide better security.

If you accept that security quality has not gone down, then you must conclude our ability to detect vulnerabilites is getting better. This is universally a good thing. Every vulnerability the "good guys" find before the "bad guys" is one we can have fix for before the bad guys take over our system.

Then there's the other side of these figures. That's alot of vulnerabilities. Now, fair enough not all vulnerabilities are created equally but I'd bet at least 10% are serious enough to get your system taken over if you're not careful. That's a lot of ways to break in to my system and it's a lot of work to make sure you're not vulnerable.

We have such a long way to go. For example, in PHP if they'd just follow Microsoft's example and put a SQL injection and XSS attack filter on information passed to web-pages we could close a serious hole in many web-applications. I've not looked at Ruby on Rails but I bet it fails this test too.

For gods sake, if you're not writing an operating system you have no business using C. Read me lips: YOU CAN'T WRITE SECURE C. Not now, not after 20 thousand hours of training, not ever. Sure, it's possible to write secure C in theory but the difference between theory and practice is that in theory they're the same and in practice they are not. In practice, you have deadlines, in practice you have people on the team who have less security training than others, in practice you have developers who have just had children and don't get a lot of sleep. In practice, people make mistakes. Code reviews may help but they wont remove everything. If you write your software in C you're doomed to having silly security bugs. If you want to remove most of the worry about overflows, use a language that rules them out.

Another thing, why should code we execute on our computers run at the maxmium privellege set of the user who's running it? Suppose my program checks a HTTP page against an MD5 hash periodically and sends an SMS through an internet based SMS gateway. Why should that program, if it wants to, be allowed to access the disk? I don't know about Java but C# has got a set of attributes that can control this type of behaviour. Really, we should be forcing declarations at the language level about what permissions each method of the program needs - the default being none of course.

Simon.

Re:The state of security

[Anonymous Coward]

For gods sake, if you're not writing an operating system you have no business using C. Read me lips: YOU CAN'T WRITE SECURE C. Not now, not after 20 thousand hours of training, not ever.

Save it for Dan Bernstein because C and ASM are still the only choices for coding performance sensitive applications. Read my lips: YOU CAN WRITE INSECURE CODE IN ANY LANGUAGE.

Re:The state of security

[Decaff]

because C and ASM are still the only choices for coding performance sensitive applications

No. If you look at an area where performance and reliability is critical, you will find that Ada is the dominant language (with Java having increasing use)

Re:The state of security

[Anonymous Coward]

I was right with you until you mentioned Java, thanks for the laugh.

Re:The state of security

[Fordiman]

Please take, for an example, the well-tested sections of the Linux Kernel as an example.

If you have some issues with the performance, reliability or security of Linux, look sidelong to the Mach kernel.

Now, if you don't mind, please pull your heade from your ass.

Re:The state of security

[canuck57]

For gods sake, if you're not writing an operating system you have no business using C. Read me lips: YOU CAN'T WRITE SECURE C.

I beg to differ, C can be real secure if written that way. The problem comes in that most people do not know how C works inside yet they code something. Then of course to your next point:

Code reviews may help but they wont remove everything.

This would solve alot of issues. How many environments routinely run bounds checking and code reviews for functionality AND security? How many people who really understand C reviewed the code?

And security problems are not just C problems, any language like Java, .NET, PHP, C# can also have their issues. CERT and others concentraight on the operating systems that we all use but generally skirt applications security which can be very bad. Job schedulers written in Java that allow root access, data warehouses that give up encoded (but not encrypted) UIDs/passwords ovr the net, the list is long. And how many people use unencrypted telnet/ftp/imap/pop3 even though secure options exist? I know senior NT and UNIX admins that don't know what a key pair is let alone what a certificate chain is. But they have a half dozen certifications.

But secure code begins with it's priority, in design and takes more time to code no mater what language you use. Having knowledgable coders helps alot. But we are in a day and age where we only want cheap coders. And here is a hint, cheap coders are never good coders or they would not be cheap. There in is the issue, more time is something people do not want to do either in training, coding or review.

Re:The state of security

[fimbulvetr]

DJB writes his software exactly like he wants. No features, no options, etc. Qmail needs special patches that he hasn't blessed to read from ldap. Djbdns won't even listen on a different port unless you edit the code manually.

Calling his code secure is like buying a 1929 Model A and saying the wiring is reliable. There is nothing outside of the coil/spark plugs. The power windows/locks/brakes/steering/fuel pump never fail, because it's impossible for them to.

Plus it's always nice when you get to deny that flaws exist in your software and your rabid fan guild protect you to the death.

A better example of a secure code writer is W. Venema or even Torvalds.

Re:The state of security

[DrSkwid]

secure C is perfectly possible

stop trolling f00l

Re:The state of security

[Decaff]

I was right with you until you mentioned Java, thanks for the laugh.

Enjoy your laugh. Boeing is using Java for real-time aeronautics.

Re:The state of security

[Decaff]

Please take, for an example, the well-tested sections of the Linux Kernel as an example.

If you have some issues with the performance, reliability or security of Linux, look sidelong to the Mach kernel.

I have no issues with the performance or reliability of Linux or Mach. Did I say otherwise?

What I have issues with is someone saying that only C or assembler are suitable for critical high-performance work. Other languages have been used for this for decades. It is just that C has been the traditional language of Unix/Linux for a long time.

Now, if you don't mind, please pull your heade from your ass.

Great way to debate. Perhaps you might want to actually educate yourself about such matters before posting?

Re:The state of security

[Decaff]

I was right with you until you mentioned Java, thanks for the laugh.

http://mae.pennnet.com/Articles/Article_Display.cf m?Section=Articles&ARTICLE_ID=234337&VERSION_NUM=2 &p=32

"Aonix engineers have demonstrated hard-real-time Java that reaches the run-time efficiency of C, which makes it able to meet the needs of command-and-control applications such as network-centric warfare, Future Combat Systems, and low-level telecommunications control-plane software, Aonix officials say."

"The Navy Open Architecture guidelines also state that all new development will be done in Java and C++, he adds. "

Laughing now? Or perhaps feeling a little foolish?

Re:The state of security

[dsanfte]

I've never seen "concentrate" spelled quite like that. +2 points for originality.

Re:The state of security

[Anonymous Coward]

I take exception to this:

If you accept that security quality has not gone down, then you must conclude our ability to detect vulnerabilites is getting better. This is universally a good thing. Every vulnerability the "good guys" find before the "bad guys" is one we can have fix for before the bad guys take over our system.

The very last vulnerability in XP that was touted on /. (http://it.slashdot.org/it/05/12/29/0039242.shtml? tid=201) : The exploit was published by HD Moore after reverse engineering some malware.

Fact of the matter is (and the post cited above amply demonstrates), since malware writers have a vested interest in remaining undetected, we have no idea whether our ability to detect vulnerabilities is getting any better vis a vis the abilities of the malware generators out there!

I watch the logs on my firewall and, with few exceptions, every vulnerability I see posted has activity stretching back days to even weeks or months before the announcement! I do NOT believe white hats are discovering vulnerabilties before black hats in any significant number; I do NOT believe that most vulnerabilties are taken advantage of AFTER the vulnerabilty is published; and I DO believe that most vulnerabilities are discovered in exploits and published long after they have been used to infect user machines.

Re:The state of security

[Decaff]

And security problems are not just C problems, any language like Java, .NET, PHP, C# can also have their issues.

Apart from the fact that .NET isn't a language, I would be interested to know what issues you think Java and C# have. Almost all the problems with C (and almost all problems with security) are due to bounds checking. Java and C# have automatic built-in bounds checking.

PHP can have issues because it is interpreted, and so you can get code injection. Java and C# aren't interpreted.

Re:The state of security

[ceoyoyo]

Privileges for a given piece of code should be set by me and enforced by the OS. Otherwise it's just letting the wolf guard the henhouse.

Re:The state of security

[lancejjj]

What? C? On Linux? Can you say S-L-O-W!? Just wait until you get some load on that server!

The fact is that C -or- Java running on top of ANY operating system is a recipe for a performance disaster. Folks with the need for speed know this already.

The only way to program for speed and performance is to:

  1. snip off any pins on the CPU that could induce interrupts

  2. write your program

  3. Make sure your program only uses the highest performing registers on the CPU

  4. Make sure your program performs no memory I/O once loaded, and performs no loops (a common error!)

  5. Convert your program into opcodes and poke them into memory byte by byte (Opcode mnemonics are for candy-assed wimps.)

  6. Execute your program!

If your program & its data is too big and bloated to fit onto the CPUs internal registers, then your program will be TOO DAMN SLOW. Then it'll be time to build a custom circuit: keep it small, keep it cold, and keep it massively parallel.

Re:The state of security

[svtdragon]

Good point. I do believe it's anatomically impossible to have one's head in one's ass. Bottom line, IMHO, is the efficiency/performance/reliability/security of the software depends more on the skill of the programming team than on anything innate.

Re:The state of security

[Anonymous Coward]

Read me lips: YOU CAN'T WRITE SECURE C

I dont doubt that _you_ cant write secure C. Painting the rest of the world with that brush is totally invalid. To write secure C you must have a proper understanding of the language, and how the compiler translates it into actual object code for the processor, which means understanding memory allocation, stack allocation, and in some cases, processor pipelines etc. If your application takes input from humans thru some type of user interface, you need to understand how that's accomplished, or if it's input comes from external hardware, you need to understand that hardware. In all cases, you need to be prepared to find total garbage on the input, and handle the scenario gracefully.

I've been writing code in C for over 20 years, and prior to that, spent a number of years working in environments where using an assembler was the only option. I still do projects today for small embedded processors where realistically, assembler 'raw on the hardware' with no operating system is the norm. To do this kind of work, understanding processors, memory management, stacks etc are a pre-requisite. Hiring somebody to work on this kind of stuff today is almost impossible, I've talked to MANY recent comp-sci grads over the last few years, and in the last couple of years, have found exactly ONE that actually understood what a pointer is, how it relates to physical memory, and how the stack is really used for passing parameters around between functions.

Most of the work I do today has formal security and reliability requirements. The code goes inside embedded systems that ultimately become responsible for controlling equipment on which lives are dependant. Early in the specification process we make the decision as to which language can be used on a given project. C and Assembler are typically the ONLY options available. C++ gets ruled out because there's to much 'magic' inside the libraries, all code which typically is not available for formal security review, or, if available for review, cannot pass validation tests. Managed environments are absolutely unuseable, there's no way to document thier behaviour in abnormal circumstances. The final decision almost inevitably becomes driven by a simple factor, if the target environment uses a host operating system, we use C, and if not, we use Assembler. In some cases it's possible to write some bootstrap stuff in Assembler, then flesh out the majority of the application in C.

Because of the nature of what some of our equipment does, we actually do testing, real testing. Before a firmware build for a device is certified for release, we actually do hook it up to equipment that is 'fixed' to malfunction in various ways, and validate the behavior with bogus input data from external hardware. It's interesting to watch somebody when they see this type of testing done the first time. Reach inside a piece of life support equipment with an exacto knife, and cut a trace on an 8 bit data bus, or on a serial data line, then watch what happens. Did the code detect an error, or, did it just turn a 'life support' device into a 'life ending' device? The look on thier face when you turn and say 'This machine just killed your son' is priceless, and, you'll never again see code from that developer that doesn't gracefully handle every detectable error condition.

The process of writing good reliable code starts off with about 10% of the time spent creating the actual code. After that, 90% of the time is spent validating and testing the code. The testing process inevitably will show corner cases where some code improvements are required. Validation is not complete until every code execution path has been formally demonstrated to work as intended, in all cases. This often includes to the process of isolating a module, then driving it with another module that is producing totally random input data, and verifying that the test module will function and not compromise the system with completely bogus and unexpected inp

Re:The state of security

[Decaff]

Bottom line, IMHO, is the efficiency/performance/reliability/security of the software depends more on the skill of the programming team than on anything innate.

No, I really don't go with this. Developers always make mistakes and are fallible, so it is far better to have a language that has speed and security built in, to avoid mistakes.

Re:The state of security

[Anonymous Coward]

Wasn't the Navy the same group that decided to use Windows NT as the OS on a computer controlled battleship?

That then had to be tugged back to harbor when the OS crashed?

The US Military isn't exactly world reknowned for making the best decisions when it comes to computing.

Re:The state of security

[Master of Transhuman]

"5. Convert your program into opcodes and poke them into memory byte by byte (Opcode mnemonics are for candy-assed wimps.)"

Ah, a gentlemen who remembers the good ol' days of the MITS Altair! Flipping front panel switches to program!

I used to have to do this on an RCA 301, too. The funny part was that the internal encoding on that machine was...character! Yup - you could read characters directly out of the memory...character-oriented machine...weird...

You had to punch octal code into the console to run a program. The program itself could be in COBOL or Fortran on a tape drive. They even had a disk drive that had a platter the size of a car wheel that required a 30HP motor to spin it. We never got that to work (all this was surplus in the 1970's.)

Here's a description of the Bull version called the Gamma 30. http://www.feb-patrimoine.com/Histoire/english/gam ma_30.htm/

Re:The state of security

[Master of Transhuman]

Oops, the link doesn't work, let's try that again.

Ah, I see, /. fucks up again! The word "gamma" is for some reason being split in the middle - "gam ma" - due to the morons who programmed Slashcode apparently. And I'm using "Plain Old Text" to submit this! Morons! "Check those URLs", indeed! Check your fucking code! This URL is perfectly good as I'm looking at it, you idiots! I've even REWRITTEN the fucking thing and you still can't handle it! Stupid, fucking geeks can't do anything right!

Re:The state of security

[Decaff]

The US Military isn't exactly world reknowned for making the best decisions when it comes to computing.

Fine. Let's ignore them then. How about Boeing, who have decided that Java is now their preferred language for all development, replacing Ada?

Re:The state of security

[Anonymous Coward]

Development for what? Their internal accounting systems?

Java's license currently says that it can't be used for certain systems, including nuclear power plants and avionics, so it can't be in airplanes.

No one cares what some web application is written in, and since it can't be used in anything where someone's life might be in danger (Sun's license won't let you), I fail to see that being really all that interesting.

Re:The state of security

[Decaff]

Development for what? Their internal accounting systems?

Er no. All kinds of interesting things... like this:

http://www.boeing.com/defense-space/military/unman ned/scaneagle.html

The software for this is in Java.

Java's license currently says that it can't be used for certain systems, including nuclear power plants and avionics, so it can't be in airplanes.

Wrong. The license on Sun's implementation of Java says this. There is nothing to stop others writing their own compatible implementation which they do certify for this use.

Guess what? They have!

No one cares what some web application is written in, and since it can't be used in anything where someone's life might be in danger (Sun's license won't let you), I fail to see that being really all that interesting.

They don't use Sun's VMs for this, so your point is irrelevant.

Java is a language, not a product. Not all implementations certified as 'Java' come from Sun.

Re:The state of security

[Anonymous Coward]

Uh no, all these are responsibilities of the OS.

"Hey user, program XYZ is trying to access the file system, should we allow this? The program may behave unexpectedly if permissions are not granted. "

Re:The state of security

[pjrc]

Are you saying that Boeing has written their own JVM ?

Re:The state of security

[chris_sawtell]

YOU CAN'T WRITE SECURE C

So 2006 is going to be the year during which assembler code does it's much heralded Lazarus act is it?

Re:The state of security

[Decaff]

Are you saying that Boeing has written their own JVM ?

I have no idea. There is a JCP standard for real-time Java, and TimeSys Corp. have produced the reference implementation, which I believe is used by Boeing, NASA and Siemens.

Re:The state of security

[Akaihiryuu]

There's no rule that says you HAVE to use a JVM to execute Java code. Of course, if you want the whole "write once, run anywhere" philosophy to apply it has to be done through a JVM, but Java itself is just a language. There's no reason you couldn't make a true Java compiler that would create machine code just like a C compiler does (instead of JVM bytecode). In fact, there has been some work on the gcc project to this end (gcj).

Re:The state of security

[swilver]

This reminds of a discussion I had at work once, whether or not we should put Apache in front of a Tomcat Java based webserver. Apache is updated often, while Tomcat doesn't bother much with updates. Which is more secure? I'd lean towards Tomcat simply because the most common security issues all arise from buffer/stack overflow issues.

The only place stack of buffer overflows could result are in the VM itself, but since this is a much smaller piece of code (compared to writing your entire project in C, like Apache) it can be more easily debugged and made secure.

Re:The state of security

[dodobh]

The problem is bad coders. Instead of the application giving root, now it just gives the attacker access to your data.

Root was one step in getting to the data, now you don't need to jump through that hoop.

Re:The state of security

[Decaff]

The problem is bad coders. Instead of the application giving root, now it just gives the attacker access to your data.

This does not explain how Java or C# are supposed to have security issues in themselves as against C or C++.

Re:The state of security

[dodobh]

My point is that it isn't the language per se which is at fault. It is the programmer.

Re:The state of security

[Decaff]

My point is that it isn't the language per se which is at fault. It is the programmer.

My point is that it is the language that is at fault.

Firstly, all programmers make mistakes - they are inevitable. So, a programming language designed for general-purpose use (rather than as a replacement for assembler for low-level work) should be safe enough for general purpose use by fallible programmers. C and C++ never have been.

Secondly, C and C++ have specific features that encourage, or at the very least ignore, mistakes. These include the interchangeability of pointers and arrays. It is easy for a developer to assume that an array in C is a high-level data structure (as it is in other languages), whereas it is simply an index into raw memory.

In most languages the following is an error and can be usually be checked at compile or run time:

int x [100]; x [102] = y;

in C or C++ it is an entirely valid thing to do.

This, in my view, is a fault, and indicates bad language design for general purpose use.

Language choice?

[Anonymous Coward]

I would like to see some data showing the correlation between applications written in unmanaged languages and those with buffer overflow and similar exploits.

Modern unmanaged C++ is fine (STL containers instead of arrays, RAII, etc.), but I often wonder why people still write in C at all, particularly when it comes to Open Source software. We are not the bearded heroes of the 70s - it's time to write in a modern language. If you don't want to sacrifice speed and system level programming for a managed environment, write in modern C++.

Re:Language choice?

[penguin-collective]

Modern unmanaged C++ is fine (STL containers instead of arrays, RAII, etc.),

Modern unmanaged C++ is NOT fine; STL permits many kinds of bugs that are analogous to buffer overflows. Furthermore, modern software systems are composed of many different modules, and just because you happen to be careful in your modules doesn't mean others are careful in theirs. Finally, without full garbage collection, you cannot have full runtime safety.

but I often wonder why people still write in C at all, particularly when it comes to Open Source software.

People prefer C to C++ because for the small increase in safety that C++ gives, it's far too complicated and complex a language. People don't use languages other than C/C++ because those languages interoperate poorly with existing C/C++-based libraries (this is C/C++'s fault), tend to have bloated runtimes, and have only a tiny user community. And, yes, many people don't even realize that there is a problem.

We are not the bearded heroes of the 70s - it's time to write in a modern language.

The bearded heroes of the 70s actually knew better. Back in the 1970's and 1980's, C was of no significance. When people were using HLLs back then, those languages were generally a lot safer than C. The rise of C was a historical accident, related to the rise of BSD UNIX and microcomputers.

But, yes, I share your sentiment: it would be good to see security bugs by language choice. And I'll give you this much: C++ is an improvement over C, but it's not a solution.

Re:Language choice?

[Fordiman]

Really simple, actually: C requires less planning, is easier to learn, and is more likely to be guaranteed cross-platform. If you're writing a simple command-line utility for your own use, it's either C or shell scripting.

Re:Language choice?

[jc42]

I often wonder why people still write in C at all, ...

Well, my last big project was written almost entirely in C for the simple reason that that's what the client wanted. We did a lot of prototyping in perl and python, but that code wasn't acceptable for delivery; we had to rewrite all the production code in C. If not, it wouldn't be accepted.

Much of the explanation was that the client had accepted C++ and java in earlier projects, and they were disasters for all the familiar reasons. They were determined that this wouldn't happen again, so they went with a "proven" language with a track record of use in major successful systems.

Similarly, I have a couple of friends who recently did a project in Cobol. They hated it, but they wanted to get paid, and that's what the client would accept.

In the Real World[TM], the decision about which language to use is very often made by managers who aren't programmers and don't have a clue about the real issues. So they make decisions based on things that they can understand and measure.

Re:Language choice?

[Anonymous Coward]

While using STL certainly makes the code cleaner than plain C, it does not significantly improve security.
There are still myriads of ways to overrun a buffer, use an uninitialized variable or iterator, etc.

For example:
1) Uninitialized iterators pointing to random memory
        vector::iterator it; // using *it or *(it+index) now may lead to system compromise

2) Iterators pointing to random memory due to violation of STL container semantics:
        vector vec;
        vec.push_back(123);
        vector::iterator it = vec.begin();
        vec.push_back(456); // using *it or *(it+index) now may lead to system compromise

3) Buffer overruns
STL copying/transformation algorithms do not provide any protection against buffer overruns.
        vector vec1; // ... fill vec1 with data
        vector vec2;
        vec2.resize(100);
        copy(vec1.begin(), vec1.end(), vec2.begin()); // if vec1 had more than 100 integers, we have a potential for system compromise

4) Using incompatible iterators (mostly due to typos) in algorithms
        vector vec1; // fill vec1
        vector vec2;
        vec2.resize(vec1.size());
        copy(vec1.begin(), vec2.begin(), vec2.end()); // attempt to copy vec1 elements to vec2
Whoa - a typo!
We have copied all the elements in vec1, then a chunk of memory between the end of vec1 and the beginning of vec2, and all this data was copied *past* the end of vec2.
This is almost certainly exploitable.

Re:Language choice?

[jacksonj04]

Perl, Python, Ruby...

Re:Language choice?

[exa]

Most programmers are too lazy/stupid to learn standard C++ or another better language.

Re:Language choice?

[gnuLNX]

For all your examples you use vectors and ierators. Who uses iterators with vectors?

vector aVec;

for (int i=0; i::iterator it = aVec.begin();
for (it; it != aVec.end(); it++) { ..code
}

As for the copy example...why would you say:

copy(vec1.begin(), vec2.begin(), vec2.end());

when you can say:

vec1 = vec2;

Your examples have a place with sets, maps, list, etc. Vectors and the STL eliminate so many common programming bugs that people who programm in C++ and don't use the STL are in my opinion not programming in C++. The STL reduces code time as well because it provides so many nice data structures, Red-black trees in the form of sets and maps, linked lists, deque's, queue's, stacks etc. If you code in C you have to write your own data structures for each of these cases. Sure it isn't that hard, but it provides more places for bugs.

Sure nothing is perfectly safe. All that fancy education we get in school has to be worth something. If all code could be written in Visual Basic by complete morons we would all be out of jobs. Show me a secure language that can do everythig for everyone? It doesn't exsist...never will.

Oh and for the people that complain how hard C++ is to learn. It really isn't. If you understand you algorithms, and data structures from school then the STL is pretty simple to pick up on. the rest of he langauge is almost just like Java, or C, or Python etc. It isn't that hard to learn the basics of any modern programming language. Sure Python is easier, but C++ is way more powerful.

Ok that is the end of my early morning rant. Of course we all know that programming lanuage debates are more emotional than religion or politics!!

Cheers

Re:Language choice?

[Anonymous Brave Guy]

Modern unmanaged C++ is NOT fine; STL permits many kinds of bugs that are analogous to buffer overflows.

Huh? Granted there are some silly design decisions in the C++ standard library, like making the unchecked indexing use operator[] and the safer, checked version use at() on a std::vector. Still, it's much harder to get things like overruns using the STL, where much code is iterator-based, and harder still to do it in a way that won't be obvious to any remotely competent code reviewer (who will ask why you're not using the safer indexing if your loop does count instead). What sort of thing did you have in mind?

Finally, without full garbage collection, you cannot have full runtime safety.

Garbage collection is an answer to one category of programmer error, and it's far from the most serious. As I often mention in these discussions, I haven't caused a memory leak writing in C++ in years, and I've got automated tools running on the projects concerned just in case to prove it. It's actually quite hard to get a memory leak in C++ if you use basic good programming practices.

On the other hand, in a language with GC you still have problems with messing up thread safety to cause race conditions, messing up thread synchronisation to cause deadlocks, greedy acquisition/lazy release of resources crippling the performance of your process (or, more commonly, other processes running on the same machine but not under the same run-time framework), SQL injection, using naive encryption and/or insecure transport protocols. These are all common flaws seen in real programs, and can be just as damaging as any buffer overflow, if not more so.

And I make this case without, until now, mentioning the IME very real problem that a lot of cheaposoft programmers who grow up relying on GC don't have the same appreciation of low level mechanics as those who don't, which causes them to write unnecessarily naff code with problems of its own.

At the end of the day, GC is a useful tool for many programming jobs, but it's only a tool, not a silver bullet. It's no substitute for a good programmer who knows what he's doing.

Re:Language choice?

[aaronl]

And here is the problem with that:

PERL - not installed on some UNIXes
Python - not installed on most UNIXes
Ruby - not installed on any UNIXes

If your app won't run in the default environment of your target platform, you create a lot more work to change the environment. Or you could write the app in a way so that it *will* run in the default environment, which means using C or shell. Usually, PERL will work, but there are several places that it isn't installed by default, even today.

Re:Language choice?

[YU Nicks NE Way]

In the Real World[TM], the decision about which language to use is very often made by managers who aren't programmers and don't have a clue about the real issues.

No. The decision is made be a manager who needs to balance the business issues of long-term supportability and cost within the current infrastructure against other technical benefits. That decision is not as simple as, say, vi versus Emacs, much less C versus Java versus C# versus Python.

Re:Language choice?

[msuarezalvarez]

If you code in C you have to write your own data structures for each of these cases. Sure it isn't that hard, but it provides more places for bugs.

Hmm. And why can't you get your data structures from a well-tested well-designed library? You know, like you do in C++?

Re:Language choice?

[gnuLNX]

Good point. I suspect that good C programmers do this. I am not down on C at all. I still program some things in pure C. I was moer directing my arguments towards the bashers of C/C++ programming in general.

Re:Language choice?

[Antique Geekmeister]

I agree with you, sir. And if you're trying to make an extremely small tool, such as a real-time or critical security tool, relying on the local Perl installation is like using a car's headlight as a flashlight: it's the wrong tool for the job.

The incompatibility of C++ compilers, and Java compilers, also leads me not to use them if at all avoidable. Plain old gcc-compilable C works robustly across a wide variety of platforms in a way those tools never will.

Re:Language choice?

[Anonymous Coward]

The programming language decision is often made by a manager who understands the business issues only moderately well, understands the technical issues poorly, and is unwilling or unable to acquire and trust information from those with technical expertise. Typically, the programmers are about 30 IQ points smarter than the manager, and paid correspondingly less. The "current infrastructure" is often the result of the manager making bad decisions over a long period of time.

So yes, the decision is often very complicated; this is, however, usually an accidental rather than inherent difficulty.

In case you haven't guessed, I think applications should be programmed in Java or C# rather than C by default in 2005. I base this on 20 years of SE and SE management experience, a MS degree with a programming language focus, and business and technical expertise. As it happens, the programming niches I work in most---embedded systems, 2D graphics, and search---are appropriate niches for carefully designed and implemented C code, so I mostly write in C. I would much rather be writing mostly in a modern language, because I make fewer mistakes and they have less damaging consequences.

Re:Language choice?

[Anonymous Coward]

because those languages interoperate poorly with existing C/C++-based libraries (this is C/C++'s fault)

Could you elaborate on this? Why is it C/C++'s fault that other languages can't interoperate with its libraries?

Re:Language choice?

[Decaff]

At the end of the day, GC is a useful tool for many programming jobs, but it's only a tool, not a silver bullet. It's no substitute for a good programmer who knows what he's doing.

You write well on this matter, but I think the evidence really is to the contrary. Hundreds of millions (if not more) lines of code have now been written in languages that use garbage collection. Some of these languages are high-performance and some are used for real-time work, and they all work fine.

Garbage collection is now routinely used even for multi-threaded languages (perhaps the best example is high-performance Java application servers like Tomcat).

So I am afraid I do think it is a silver bullet, and manual memory management will soon look like part of history except for the most specialised uses.

Re:Language choice?

[iluvcapra]

A technical point: Perl, Python and Ruby are all installed on Mac OS X, which though being only one Unix, has the largest installed base of any Unix.

Re:Language choice?

[Halfbaked Plan]

Mac OS X is not a UNIX. Microsoft Windows NT with SFU installed can be just as much a 'UNIX' as Mac OS X. Oh, with one distinction. Microsoft Windows NT with SFU installed is certified as a UNIX(tm).

Re:Language choice?

[Anonymous Brave Guy]

You write well on this matter,

Thank you.

but I think the evidence really is to the contrary. Hundreds of millions (if not more) lines of code have now been written in languages that use garbage collection. Some of these languages are high-performance and some are used for real-time work, and they all work fine.

I think we probably have quite different experiences here. Certainly your world, where a query-driven application like Tomcat is "high performance", is very different to mine, where things like 3D modelling, photorealistic rendering, and large scale simulations are bread and butter. Does anyone write CAD programs or supercomputer-based weather modellers using Java? Not that I know of, and I do and have worked in these fields for several years. That's not to say that no-one ever does, of course, but it's not the norm.

None of this means that I see manual memory management as a good thing. On the contrary, for the vast majority of the time, it's just another implementation detail, and best dealt with automatically. I'm just saying that there are plenty of other nasty categories of programmer that a garbage collector won't help you with.

Re:Language choice?

[Anonymous Coward]

What's the difference between STL iterators again? Consider this:
std::copy(beginIt, EndIt, TargetIt)
and
strcpy(from, to)

Both share the same fatal security flaw when it comes to overruns, they don't recieve the capacity of the target, so they will merrily overrun their target. In both cases the only sentinal is based on the input. Good design doesn't do this. Is the STL better than raw arrays? Yes. Is it still very dangerous? Yes.

Re:Language choice?

[Anonymous Brave Guy]

Your example is often cited, but it's rare in real code. Usually, you'd either copy from one container to another by direct assignment, or populate one from another by using something like a back_inserter. So yes, the weakness is there, but it's not as significant as the existing alternative.

And of course, nothing says iterators can't be access-checked in a safe library implementation.

Re:Language choice?

[Decaff]

is very different to mine, where things like 3D modelling, photorealistic rendering, and large scale simulations are bread and butter. Does anyone write CAD programs or supercomputer-based weather modellers using Java?

Yes, they do.
http://www.ssec.wisc.edu/~billh/cacm2005.html

"Java distributed components for numerical visualization in VisAD"

http://www.brunel.ac.uk/~csstsjt/ssg/ssghome.html
Using JAVA to develop simulation models [Keynote]

"From a simulation perspective, Java may be regarded in one of two lights. The first is as yet another general purpose programming language in which computer simulation models may be developed."

and

"Distributed Simulation with Java"

It took just a few seconds with Google to find these... there must be many, many more.

The reason I mentioned Tomcat is that such application servers are used because the are so effective at running garbage collected applications multi-threaded without one program impacting the other, or locking up the system.

Re:Language choice?

[Anonymous Coward]

Could you elaborate on this? Why is it C/C++'s fault that other languages can't interoperate with its libraries?

Mostly because of C/C++'s unfettered use of pointers and memory allocation; C/C++ APIs and data structures often rely on pointers in a way that no safe language can support and remain safe.

C# has found a reasonable compromise: C# is safe, but it provides an explicitly marked unsafe sublanguage for talking to C/C++ APIs and data structures.

Re:Language choice?

[penguin-collective]

I think we probably have quite different experiences here. Certainly your world, where a query-driven application like Tomcat is "high performance", is very different to mine, where things like 3D modelling, photorealistic rendering, and large scale simulations are bread and butter. Does anyone write CAD programs or supercomputer-based weather modellers using Java

Java is rarely used for numerical applications because Java's support for numerics is poor; some problems with Java are lack of overloading, lack of multidimensional arrays, inefficient generics, and lack of value classes. Those are specific shortcomings of the Java language.

Garbage collection and runtime safety are very valuable for 3D modeling, photorealistic rendering, and large scale simulations and do not cost you anything in terms of performance.

Re:Language choice?

[Anonymous Brave Guy]

Out of interest, did you actually read any of those articles you cited? The first, for example, is using Java to develop a distributed computation network. Sure, if you take 100 computers, of course you can do more with even a moderately efficient programming language than you can do on a single machine, even if your language were several times faster on that machine. I don't see how that supports your argument; on the contrary, it's the classic "hardware is cheap" approach necessarily employed by those using inefficient programming tools.

How about finding some real, production applications (not recent, unfinished developments or academic experiments) that use Java for the same sort of job that things like C++ or FORTRAN are used for at present, without falling back on the word "distributed"? Funnily enough, a quick Google looking for that turned up nada for me.

Re:Language choice?

[Decaff]

Out of interest, did you actually read any of those articles you cited?

Yes.

The first, for example, is using Java to develop a distributed computation network.

Indeed. I have written such stuff myself. There are tools for it in C,C++ and Fortran. I don't believe Java's facilities in this area are not sufficient for a move to the language if it were significantly slower than the alternatives.

I don't see how that supports your argument; on the contrary, it's the classic "hardware is cheap" approach necessarily employed by those using inefficient programming tools.

This is a very condescending attitude to those doing the development - you honestly think that they are deliberately doing work with inefficient programming tools? Do you really think they would use a language for general purpose simulation if there was a significant speed penalty? (Having been through the process myself, I can just imagine the comments from review bodies when the applied for grants if this were true).

How about finding some real, production applications (not recent, unfinished developments or academic experiments) that use Java for the same sort of job that things like C++

Here is a well-known molecule CAD system in Java:

http://willware.net:8080/ncad.html

Here is a high-performance simulation system:

http://jist.ece.cornell.edu/

Here is a Java Numerics Library:

http://www.vni.com/products/imsl/jmsl/jmsl.html

There aren't many of these, because until recently (a few years ago), Java performance was just not good enough for this sort of thing (even the strongest Java supporters will admit this), and the numerics/simulation industry is one of the slowest about accepting new technologies (as shown by the huge amount of Fortran still being written).

However, this may interest you - some numerical benchmarks commonly used with C and Fortran - Java is right there close to the top in many of them:

http://www.vni.com/products/imsl/jmsl/jmsl.html

Re:Language choice?

[iluvcapra]

Mac OS X is not a UNIX

You're right, but then again, big gobs of Unix code can be compiled without modification on Mac OS X, and it provides just about all the services a Unix app or user might want.

Also, by your standard, Linux is not a Unix OS, while Linux also is generally compatible with Unix sources. Software platforms, which is what the conversation is about, are duck typed, not statically typed. If your platform looks like a duck and quacks like a duck, it's a duck, until it isn't, which applies to Unixes, too.

Re:Language choice?

[Anonymous Brave Guy]

Apologies if I came across as condescending; no insult was intended. I was just trying to point out that getting good results by using powerful hardware doesn't really tell us much about the quality of the language itself, since those using less powerful languages would inevitably do the same.

While I am not claiming that those doing this work would deliberately choose an inefficient language, other things being equal, we have to consider that other things are not equal here. For distributed work, Java has a lot of built-in functionality that would make development easier, which languages such as C++ or FORTRAN do not. At the very least, it would be necessary to identify or develop a suitable library in C++ just to get started, and if this is for academic research purposes or an industrial proof of concept, rather than really trying to develop a fast-as-possible application, then that would be wasted effort.

Perhaps we'll just have to agree to disagree here, because we're obviously coming at this from entirely different perspectives, and we've drifted some way off the original topic (where I was simply saying that GC is not the be-all and end-all of programming safely, without regard to performance). FWIW, it looks like your CAD example does some fairly simple mechanical modelling and has a few thousand lines of source code. The kind of CAD applications I work with model planes, or cars, or oil rigs, with thousands of constraints between thousands of geometries, complex interactions between parametric surfaces, somewhat realistic modelling of physics, and so on, and they do it all interactively. Lest I give the wrong impression again, this isn't meant as any sort of slight against the modeller you cited; we're just looking at entirely different scales when we talk about a "CAD program", and thus entirely different performance requirements.

I'd still be curious to see the benchmarks you mentioned, though. I think perhaps you repeated the previous link rather than using the one you wanted in your last post? A lot of things are said about the performance of programming languages based entirely on inappropriate consideration of unrepresentative benchmarks, so it would be good if you've found something that provides a more realistic basis for comparison.

Re:Language choice?

[Decaff]

At the very least, it would be necessary to identify or develop a suitable library in C++ just to get started, and if this is for academic research purposes or an industrial proof of concept, rather than really trying to develop a fast-as-possible application, then that would be wasted effort.

There have been very straightforward libraries for C++ and Fortran that have been around and very well known for years - PVM for example. There is no need to switch to Java to get good distribution of code, so I do think things are equal...

Lest I give the wrong impression again, this isn't meant as any sort of slight against the modeller you cited; we're just looking at entirely different scales when we talk about a "CAD program", and thus entirely different performance requirements.

I know what you mean. I have perhaps a better example below.

A lot of things are said about the performance of programming languages based entirely on inappropriate consideration of unrepresentative benchmarks, so it would be good if you've found something that provides a more realistic basis for comparison.

This is hard, as it is very rare to find exactly the same substantial piece of code written twice in two languages in a way suitable for comparison. The only way I have managed to test speed is by small benchmarks - iterative numerical solutions, text processing algorithms etc. When I have done this I have simply found no difference between Java and C.

Perhaps the best indication I can find that Java really has gained C performance is that it is now being used for commercial games with 3D output - even though much of the rendering is usually done by hardware, much of the work involved a substantial amount of numerical computation, and Java is up to it.

Perhaps a better indication of Java used for engineering work is "Electric VLSI"

http://www.staticfreesoft.com/

- this a substantial package, involving nearly a quarter of a million lines of code. One of the criteria of the port to Java (it used to be in C) was that there would not be a speed penalty as a result. There wasn't. I think this is a good indication that Java is definitely suitable for the kind of things you are doing.

OSOS

[Konster]

812 flaws in the Windows operating system? When did they start counting flaws? December 28th?

Re:OSOS

[Anonymous Coward]

I expected to see 5197 of them in IE alone...

Re:OSOS

[TubeSteak]

I think you're confusing the "Error Report" window with "flaws"

Error Reports are a feature, not a bug.

Explorer vs Firefox

[dynamo52]

Firefox: 1
Explorer: 45
Explorer wins!

Re:Explorer vs Firefox

[Anonymous Coward]

You may want to revise that statement when you'd actually had a look at the article.

Re:Explorer vs Firefox

[dynamo52]

It was a joke.
I was referring to the amount of vulnerabilities listed for each.

Re:Explorer vs Firefox

[Kawahee]

That made me laugh. To the dumbass who didn't get the joke, register a /. account so we can mod down your karma.

Re:Explorer vs Firefox

[Anonymous Brave Guy]

<Menacing overlord voice> Finish him! </Menacing overlord voice>

This count must be wrong!

[corvair2k1]

I've released more than that by myself this year!

Re:This count must be wrong!

[rapidweather]

Me too. Count all the bugs for apps that don't work right the first time around, also.
As far as all of the security bugs goes, I suppose that includes us LiveCD people.
Probably doesn't matter how one gets the OS up and running, HD or CD, it will have bugs, etc.
I do write C++ apps similar to what is found in Knoppix, and use TCL/TK also.
Somehow, though, I feel better running my Knoppix remaster than using XP or (gasp) Windows 98 when going on the internet. I use both Dial Up and Cable Broadband, and sometimes turn the Broadband off if I do not have to connect to the internet at the time. Just to be safe.
I do that all the time when using XP. I did have that OS become unbootable once, and spent
$240 on a new hard drive and security software to get it running again. Looking at the bright side of that, I do have 320 GB of space now, it's just that 120 GB of it is not bootable anymore. Only problems I have had with Knoppix machines is power supply going out from adding too many cards, etc. That has nothing to do with the OS.
I am thinking about doing apt-get install firestarter on my Knoppix remaster, but I hesitate to put something in there that will keep the ordinary user as busy as the XP users updating their security software. Spending time doing that, rather than what they wanted to do in the first place. I have run Firestarter on Debian hard drive installs, and it does a nice job, so I am leaning toward putting it in.

Original Article from us-cert

[Anonymous Coward]

http://www.us-cert.gov/cas/bulletins/SB2005.html

Summary does not even bother to link the original article!

Excellent news!

[Anonymous Coward]

"According to US-CERT...researchers found 812 flaws in the Windows operating system, 2,328 problems in various versions of the Unix/Linux operating systems (Mac included)."

Excellent news! I think it's clear now that Windows OS is about three (3) times more secure than Unix/Linux/Mac!

Oh, wait a minute...

Re:Excellent news!

[canuck57]

Excellent news! I think it's clear now that Windows OS is about three (3) times more secure than Unix/Linux/Mac!

One could also view this differently. MS is closed source, so if that many were found by people who don't have the source how bad would it be if they had the source?

The second issue is with Linux sources, the bugs are being vetted out of the code at a much faster pace making it ulimately more secure.

Statitics lie when taken out of context. We could also look at the tally of "infections" as it may also be an indication of the ease and severity of vulnerabilities - and certainly the impact to society.

Re:Excellent news!

[TubeSteak]

Are the Linux bugs that "are being vetted out of the code at a much faster pace..." new bugs or old ones?

Linux is constantly adding new code while Microsoft is pretty much patching their existing code base. SP2 added new features to WinXP, but it also borked a lot of installations at its launch.

I just wonder how many of the patches are for old code compared to relatively fresh stuff. EX. the wmf exploit is based on code that's been lying around since Win98

Re:Excellent news!

[drsmithy]

One could also view this differently. MS is closed source, so if that many were found by people who don't have the source how bad would it be if they had the source?

One must also consider that Windows has a vastly higher level of exposure than any of the other platforms. How well would the unixes have fared if they had the user demographics and marketshare of Windows ?

The second issue is with Linux sources, the bugs are being vetted out of the code at a much faster pace making it ulimately more secure.

People say this a lot, but it never seems to get supported with anything more than hand-waving.

Statitics lie when taken out of context.

Statistics never lie, the people interpreting them do.

Microsoft...

[zsadiq]

I know Microsoft issued a lot of patches this year that fixed quite a few vulnerabilities ... but 812? My suspicion has always been that Microsoft sometimes fixes multiple flaws with a single patch, even though its advisories may make it appear as though the patch addressed a singular issue.

I'd love to know just what percentage of those reported Windows flaws have been fixed. For that matter, it would be lovely to know that for all of the flaws reported last year.

Anyone?

And is this the first year that these statistics have been gathered on a scale like this?

Re: Microsoft...

[ncurtain]

Which Windows Operating System are they talking about or should IRTFA?

Re: Microsoft...

[zsadiq]

Mostly XP SP2 I believe.

Please don't hold my balls to it though.

Re:Microsoft...

[shis-ka-bob]

When a patch is measured in the tens of MB, you can bet that it addressed multiple issues. It is was only addressing one issue, like an typical patch for an open source project, it would be a diff file that measures no more than a few kB.

Re:Hooray \o/

[spike1]

So, where did you read that windows is more secure all of a sudden?

You didn't take those figures at face value did you?
Those figures said they were for linux AND other univx variants like OSX...

So, 2500 between OSX, openBSD, netBSD, freeBSD, Linux, Solaris, etc... (not to mention all the flaws listed for the dfifferent linux distributions probably got duplicated across several distros)

versus 900 for windows
(I'm rounding up)
Was this 900 split between 95/98/98SE/ME/2000/XP/Vista?
or just for XP?

There're lies, damned lies, and statistics

519,8 pickup-tries

[maggern]

5198 bugs is interestingly excately 10% of the number of times I tried picking up girls a bars in 2005. ...they kept calling med a creep, not a bug, though. *cough* *cough*

Re:519,8 pickup-tries

[Anonymous Coward]

Hell, man, with wit like that, the chicks ought to be throwing themselves at you. Really.

Re:519,8 pickup-tries

[Paradise Pete]

Ya gotta admire his stamina, though. That's 142 attempts per day.

It's da new style

[Lime Green Bowler]

Finding software flaws -ahem- 'exploits' ... is en vogue at the moment. Unfortunately this is also the catalyst for additional needless security, DRM, policies. Instead of putting resources towards development or improvement, the resources are wasted on finding minute problems. Sure this effort could make software better for the future (reliable, secure), but the bureaucracy is putting us farther behind, and is creating more work with less usable results.

shocking numbers

[CDPatten]

"researchers found 812 flaws in the Windows operating system, 2,328 problems in various versions of the Unix/Linux operating systems (Mac included). "

If we listened to just the media you would have thought Windows has thousands and the others only had a few dozen. I promise I'm not trolling, but do those numbers stop and make anyone on the site re-think stances? We all saw the numbers that put Firefox with more holes then IE earlier this year too. Could MS be doing a better job, but just getting hammered in the press (who are mostly Apple users by the way)? MS holes get lots of press while other operating systems get a free pass.

"I know Microsoft issued a lot of patches this year that fixed quite a few vulnerabilities ... but 812? My suspicion has always been that Microsoft sometimes fixes multiple flaws with a single patch, even though its advisories may make it appear as though the patch addressed a singular issue. "

MS always has an attached KB article that details everything their path does. I don't think that statement is denial.

I find myself defending MS allot on this site, and it's nice to have some numbers from a respected neutral organization to debate some of you guys with. I'm sure after this piece they will be re-classified as MS zealots, but what can ya do.

Re:shocking numbers

[penguin-collective]

If we listened to just the media you would have thought Windows has thousands and the others only had a few dozen. I promise I'm not trolling, but do those numbers stop and make anyone on the site re-think stances?

No, it doesn't. First of all, there are a dozen different versions of UNIX and Linux, each with their own set of flaws. MacOS is an almost entirely different system except for a kernel compatibility module and a bunch of command line utilities. Second, the number of bugs discovered or number of bugs fixed tells you little about the security of an operating system. Individual bugs have very different consequences for system security.

I find myself defending MS allot on this site, and it's nice to have some numbers from a respected neutral organization to debate some of you guys with. I'm sure after this piece they will be re-classified as MS zealots, but what can ya do.

If you are using numbers like these to make an argument that MS products are "more secure", the zealot is you. But, then, you already admitted as much.

Re:shocking numbers

[Fordiman]

I'd like to see the numbers for basic core aplications.

For example, on the windows side, problems with the OS and core packages. Things like notepad, control panel, wordpad, etc, and on the linux side, you'd have to do some averaging: Linux 2.4 v 2.6, KDE v. Gnome core apps. Meanwhile a comparison between Openoffice and Office would be in order. It's been a while sice the last good study of how one works next to the other in their 'naitive' environments.

Re:shocking numbers

[Anonymous Coward]

> I'd like to see the numbers for basic core aplications.

I agree. Are we comparing apples with apples when looking at these numbers? Since a windows installation limits what you can avoid installing, while some linux installations install 5 different text editors, and multiple browsers, etc., and these all have some holes, what would just the core show?

Re:shocking numbers

[shaitand]

I'd like to see OS versus OS. For linux you count kernel flaws (everything else is user space and can be swapped out with other apps). For windows you count flaws in the software that remains after you remove everything you can through proper channels (uninstall, not simply delete).

Re:shocking numbers

[jedo]

Did you read the first post?

Re:shocking numbers

[Liam Slider]

"researchers found 812 flaws in the Windows operating system, 2,328 problems in various versions of the Unix/Linux operating systems (Mac included). "

If we listened to just the media you would have thought Windows has thousands and the others only had a few dozen. I promise I'm not trolling, but do those numbers stop and make anyone on the site re-think stances? We all saw the numbers that put Firefox with more holes then IE earlier this year too. Could MS be doing a better job, but just getting hammered in the press (who are mostly Apple users by the way)? MS holes get lots of press while other operating systems get a free pass.

The situation is, as usual, more complicated. As typical, they are lumping together pretty much every flaw in pretty much every little piece of software that actually runs on Linux/Unix/Mac and is typically included in Linux/Unix distributions and/or Apple's software....vs the flaws found in Microsoft Windows, and Microsoft software... Gee, is it any surprise they are finding more flaws outside the Windows camp? Several different operating systems and all their software vs one. Furthermore, it does not address which flaws were critical and which weren't, which were fixed and which weren't, how quickly they were fixed....and which side does better in those regards. Also it doesn't address the fact that it's easier to find bugs to fix in an open source environment than it is in a closed source one.

Re:shocking numbers

[Antique Geekmeister]

Unfortunately, the raw numbers are misleading. Many of the Windows bugs are fundamental to the way they do things: auto-opening and auto-executing downloads is amazingly stupid, and the particular vulnerability used after that point is irrelevant, but those are the defaults for all Microsoft distributions.

Second, the Linux/Mac/UNIX holes tend to be very small: they require a clever programmer to detect the vulnerability, they require skill to exploit, they often require the user to do something additionally stupid such as hand-downloading and opening a file, and they're repaired with an easily installed patch within 48 hours. Many of the Windows holes are gaping, remain unfixed for years, and hundreds if not thousands more are not being published by CERT for years because they have never been resolved by Microsoft.

Third, the open development communities around Linux, UNIX, and Macs tend to publish vulnerabilities and exploits. The Windows community absolutely does not: companies that detect flaws report them to Microsoft only if necessary, but generally keep them internal and refuse to discuss them with outsiders because they think revealing security flaws is asking people to exploit them, so as a matter of secure practices, they refuse to publish what they've found.

Given all those factors, and a lack of scanning for known vulnerabilities that have never been fixed, it's very hard to trust an analysis of an analysis of CERT numbers as really showing relative security of the operating systems.

Re:shocking numbers

[Anonymous Coward]

Well, they tried to compare Apple computers to Windows computers, but then Microsoft didn't look better.

Re:shocking numbers

[drsmithy]

I'd like to see OS versus OS. For linux you count kernel flaws (everything else is user space and can be swapped out with other apps). For windows you count flaws in the software that remains after you remove everything you can through proper channels (uninstall, not simply delete).

That's not even a remotely equitable comparison.

If you want to fairly compare "OS versus OS" pick a Linux distribution with a similar software bundle to Windows. But comparing a kernel to an entire OS bundle is so ridiculously one-sided (not to mention worthless for any sort of real-world conclusions) it's not even worth considering.

Re:shocking numbers

[Halfbaked Plan]

Well, if you're going to split apart all the OSes based on the Linux kernel for bug counting, it will also be necessary to do so for usage statistics.

So what does that mean? It means Microsoft and Mac OS X are the ONLY operating systems with more than .005% of the market share.

Satisfied?

Re:shocking numbers

[penguin-collective]

So what does that mean? It means Microsoft and Mac OS X are the ONLY operating systems with more than .005% of the market share.

That's a popular misconception. At this point, there are probably more Linux users out there than OS X users, and both Linux and OS X have at least several percent market share.

Re:shocking numbers

[Halfbaked Plan]

You missed my point, it seems.

If Linux is just the kernel and/or software-flaw statistics need to be split amongst the many OSes based on the Linux kernel, then there are many tiny OSes based on the Linux kernel, all statistically insignificant.

Solaris has at least several percent market share, if you don't count the 30,000,000 six year old children counted as 'users' in the statistics because so many people have a 'home computer.' (kind of the Trabant of computing)

Does Redmond...

[Anonymous Coward]

...report all the flaws to CERT that they find internally? Is CERT counting all open source project flaws then comparing that number to a limited number of windows-shiped products and ignoring most third party windows apps because they are closed source and those devs aren't in the habit of revealing vulnerabilities if they don't hjave to? I mean, there's a rather glaringly LARGE difference with what you get with a windows XP operating system direct from Redmond or any of the big box vendors compared to any of the major distros and what comes on their disks. What's a "system" then?

      I looked at the CERT link from the blog link in this article, where are all the windows apps? That list is ALL the windows third party apps vulns? Why am I not believing this? Are all the third party windows apps devs actually reporting vulns, or just shipping new and improved and clamming up over anything they find?

    Good thing CERT has a disclaimer at the top saying they have no idea if any of what they have there is complete or not, or even true. At best this CERT list is a really vague guess.

Well, it's how you look at it...

[Anonymous Coward]

Let's compare entries in the vulnerability database.

Linux
Optimistic TCP acknowledgements can cause denial of service
Gaim vulnerable to HTML processing denial of service

Windows
Windows XP
Windows 2000

Yes, I can see where those numbers come from.

Sensational, and meaningless

[Anonymous Coward]

I'm sure all of us on Slashdot can see that these numbers have little meaning, because:

• You find where you look. If people started looking for security flaws in NetBSD and stopped looking everywhere, surprise, we would find thousands of flaws in NetBSD and none anywhere else, telling us... nothing
• More people looking will (generally) mean more holes are found.
• The definition of a security vulnerability changes over time, and depends on the vendor. One man's feature is another man's vulnerability.

One bad thing is that software is getting more complicated and secure design methodologies are lagging behind. We've had secure development environments like Java for a long time now, and we have known for the past decade that large pieces of software developed in unsafe languages (C) can never be safe, and yet... we continue to use these unsafe tools. Until tools and design methodology change, we're going to keep having more holes as software systems get bigger.

Someday that will change. People will (eventually) shift to "safe" languages, where "safe" means no unchecked memory access, bounds checking on arrays, type safety, etc. The more we get to that the fewer vulnerabilities we will be seeing.

---------------
Drag-and-drop file upload in your browser

Do the math...

[Ancient_Hacker]

800-some isnt so bad. Do you remember when part of the Windows source code got out, and a little GREPping showed about 48,000 uses of untamed strcpy, strcat and sprintf?

If you assume only 5% of those calls could overflow a buffer, Windows is doing 4x better than expected!

UnixWindows

[harris s newman]

Well, which were more serious?

These numbers are meaningless.

[master_p]

Ok, I've made a 'hello world' program in C++...I had 0 bugs in it, do I win?

Seriously now, these numbers are useless without mentioning lines of code and programming languages. Suse Linux 9.3, for example, has over 7,000 RPMs, which is an enormous amount of software.

Absolute bug numbers are meaningless.

Re:These numbers are meaningless.

[Anonymous Coward]

----Pick your comment------

1. A feature is a bug with seniority
2. My software never has bugs. It just develops random features.
3. Bugs come in through open Windows

I choose 3.

Re:These numbers are meaningless.

[TubeSteak]

There are lies, damn lies and statistics.

This is why absolute numbers are meaningful.

This isn't necessarily directed at your statement (because you're asking for more hard numbers in the form of programming languages and lines of code) but it's worth saying.

Yes, we can weight the various bugs to make the comparison more 'accurate', but the second we begin doing that, we've injected someone's opinion of what is and isn't important.

Admittedly, you could extend the superficial analysis the author did without having to start making assumptions, but then we'll criticize that analysis too.

To illustrate my point: Would it be fair to say that (as far as the entire world is concerned) a bug in Mac OSX isn't nearly as important as a bug in Windows, no matter how serious the flaw is?

Don't forget, when /.'ers say "you usually end up with x number of bugs per million lines of code," that's just a avg/best guess

Re:These numbers are meaningless.

[fimbulvetr]

It's also meaningless because it unfairly groups Apple in with Linux/Unix. Solaris might have its share of bugs, and linux surely has exploits more often than we'd like, but if you browse through the Apple vulnerabilites, you'd see that most of them are blatent, stupid oversights that people should be fired for. I wouldn't be suprised if Apple has the majority in the unix/linux group - commonalities aside.

Apple needs to get someone who knows a thing about security, because the false belief "its unix its secure" is about to crumble.

Re:These numbers are meaningless.

[Paradise Pete]

Ok, I've made a 'hello world' program in C++...I had 0 bugs in it, do I win?

Maybe. Go ahead and post it so the judges can see for themselves.

Re:These numbers are meaningless.

[FromWithin]

Ok, I've made a 'hello world' program in C++...I had 0 bugs in it, do I win?

Well that all rather depends on your compiler, doesn't it?

Re:These numbers are meaningless.

[Anonymous Coward]

Perhaps. But considering that the typical "C Hello World" has two bug, you might want to re-examine your code, just in case.

For the curious, the two bugs are:

* no return value -- so your program will return whatever junk is on the stack at the time to your OS. Any shell script using this value to determine the success of hello world would be in for random behaviour

* no check to see if anything is actually written out. It's possible to pipe hello world to a full disk. At the very least, you should check to see if the expected number of characters are printed out, and if not, return an error code from main().

Re:These numbers are meaningless.

[Anonymous Brave Guy]

#include <cstdio>

int main()
{
std::printf("Hello, world!\n");
}

Any questions? :-)

Re:These numbers are meaningless.

[Anonymous Coward]

You forgot to check the return value of printf().

Re:These numbers are meaningless.

[Anonymous Coward]

You are relying on C++'s implied "return 0", but not all
platforms use 0 to indicate success.

A more portable solution would be to include the relevent
C standard library header
    #include <cstdlib>

and explicity return the platforms "success" value
    return EXIT_SUCCESS;

You might want to check the return code of your
printf() call as well, if it fails, you could
    return EXIT_FAILURE;
to indicate an error to the caller

Re:These numbers are meaningless.

[EvanED]

no return value -- so your program will return whatever junk is on the stack at the time to your OS. Any shell script using this value to determine the success of hello world would be in for random behaviour

I can't say for C, but at least in C++ if execution falls off the end of main() the return value is guranteed to be 0 in a compliant compiler, rather than random stack crap.

Re:These numbers are meaningless.

[Anonymous Brave Guy]

Blockquoth the AC:

You are relying on C++'s implied "return 0", but not all platforms use 0 to indicate success.

Perhaps, but returning 0 from main() is guaranteed to return a suitable success indicator to the host environment. From ISO/IEC 14882:1998, 18.3/8:

Finally, control is returned to the host environment. If status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned.

Software Bugs

[Ice Wewe]

If I were you, I'd keep my eyes out for a Windows logo on that web site. *cough*kickbacks*cough* From my experience, if Microsoft doesn't have more bugs, then their software sure is shitty. I mean, FireFox is open source, IE is not. Who is more secure, doesn't crash as much, and has nifty plug-ins? If you said IE, you're living in the past. Sure, Open Source is going to have more bugs, it's hundreds of thousands, if not millions of people contributing code. Of course not all of them are going to get everything perfect. Now compare how many people Microsoft has working on bugs. A few thousand at best. Now you see the reality of this. Linux is going to have more bugs simply because it has more software. Microsoft is going to take longer to patch their bugs because they only have a fraction of the people working on it.

Re:Software Bugs

[LnxAddct]

You shouldn't be modded as a troll.

Re:Software Bugs

[lasindi]

Sure, Open Source is going to have more bugs, it's hundreds of thousands, if not millions of people contributing code. Of course not all of them are going to get everything perfect. Now compare how many people Microsoft has working on bugs. A few thousand at best. Now you see the reality of this. Linux is going to have more bugs simply because it has more software.

I love open source and everything, but, with respect, your argument is rather absurd. Basically, you're saying that there's far more FOSS than Microsoft software out there, and therefore more code will have more bugs. True, many Linux distros bundle far more software than MS does with Windows, but that doesn't mean that Microsoft's software doesn't exist; it just means it's not part of the Windows bundle, which is either because of antitrust reasons or because MS wants to make money from the software separately.

Also, saying "open source projects have hundreds of thousands of developers, while MS projects have only a few thousand" is very, very misleading. Open source projects might have lots of contributors, but the vast majority don't work on it full time. Usually FOSS projects have a "core" of developers that work full-time and coordinate the contributions from all of the many contributors. These core groups of programmers are usually comparable to the size of their proprietary counterparts.

That's not to diminish the contributions of the larger community at all. I think open source works very well as a development model and I much prefer it to proprietary software. But the way you portray it, one might think that open source is light years ahead of Microsoft software because MS developers are hopelessly outnumbered and that the open source world completely dwarfs the Microsoft world. This is simply false.

Plus, the whole premise behind open source, "given enough eyeballs all bugs are shallow," would fall apart if your reasoning were true. You're saying that having more programmers means more bugs; the whole point of open source is that more programmers means *fewer* bugs.

Happy New Year!

Well...

[The Ilia]

What I want to know is how many they didn't find.

Re:Well...

[dotgain]

You must have missed the link at the bottom of the article, where they list all the undiscovered vulnerabilites...

Umm am I stupid or something?

[bogie]

Because I know I just woke up but that CERT page is listing APPLICATIONS FLAWS and NOT OS flaws.

Is a flaw in "Gold FTP explorer" or Photoshop a Windows OS flaw?

Am I the only one seeing this?

Re:Umm am I stupid or something?

[jc42]

Shh! Most of the people here don't understand the difference between an OS and an "app". Many of them will even tell you with a straight face that a runtime library is part of the OS. (Really; look through the /. archive. ;-)

So let's keep quiet on the sidelines, and let the all make fools of themselves in public.

Re:Umm am I stupid or something?

[TubeSteak]

Someone on blogs.washingtonpost.com has a lazy mind.

I know Microsoft issued a lot of patches this year that fixed quite a few vulnerabilities ... but 812? My suspicion has always been that Microsoft sometimes fixes multiple flaws with a single patch, even though its advisories may make it appear as though the patch addressed a singular issue.
...
...so attackers are looking at developing more exploits for applications that run on top of Windows and interact directly with the user (and are freely allowed in and out of software firewall applications).

He's even getting flamed in his comments section.

I want to say that he just squeezed out a quickie article before going on holiday and didn't bother engaging in much thought... but I read his last few posts and they don't have much substance to them.

Does anyone else see the humor if a blog (slashdot) linking to another blog which links to the original source?

Re:Umm am I stupid or something?

[shaitand]

*sighs* I know. It frustrates me to no end that Operating System is being redefined.
It has been changed from the layer of software that operates the hardware and provides the lowest level api for accessing it (kernel, and kernel api); to the layer of software that interacts with the user.

Re:Umm am I stupid or something?

[ceoyoyo]

Well, for the purposes of security, if the runtime library is distributed with the OS then it should be counted as part of the OS. So installed-on-every-copy-of-windows-because-every-p rogram-needs-to-use-me.dll is counted as part of the OS but funky-library-for-doing-bad-stuff-from-Claria.dll isn't.

Re:Umm am I stupid or something?

[ceoyoyo]

When all your software comes from the same company it's hard to tell the difference sometimes.

My computer doesn't work.
What OS are you running?
Microsoft Office.
You mean Windows.
Yeah, I think I have Windows. But I'm running Office.

Re:Umm am I stupid or something?

[jonored]

It's listing both; like "linux kernel ZLib invalid memory access denial of service". It's just that it's a much longer list for every app that's big enough to get bugs submitted to this place rather than just to the developers.

Re:Umm am I stupid or something?

[jc42]

Heh; good examle. I've heard that sort of thing more times than I can count.

Of course, on most hardware, it's trivial to distinguish the OS level from the application level. There's a machine opcode called "system call", usually SC in the assembly language. If you need to invoke SC to do something, you're an application; if not, you're part of the OS. But this isn't visible to most people sitting at the keyboard and looking at the screen, so the confusion is understandable.

Re:Umm am I stupid or something?

[drsmithy]

*sighs* I know. It frustrates me to no end that Operating System is being redefined. It has been changed from the layer of software that operates the hardware and provides the lowest level api for accessing it (kernel, and kernel api); to the layer of software that interacts with the user.

It hasn't changed at all, like many other things, it's simply dependant on context.

When in the context of academia and theory, "Operating System" (basically) means the kernel.

In any other context, it means a bunch of software packaged together to make a computer more useful than a paperweight.

Re:Umm am I stupid or something?

[drsmithy]

Shh! Most of the people here don't understand the difference between an OS and an "app".

Including many of those who say they do...

Uhma ...

[Anonymous Coward]

Actually, it seems that in the linux/unix section it is possible that some bugs have been reported twice or more.

It could be that one bug that effects the linux kernel could be reported as both as a bug in red hat, feodora and under the line of multiple vendors.

I would like them to seperate windows (versionnumber),linux kernel and then for apps.

a nugget of wisdom

[User 956]

If you are using numbers like these to make an argument that MS products are "more secure",

I've got a nugget of wisdom for you: Whichever OS is the most popular is going to end up being the least secure. It doesn't matter who makes it.

Re:a nugget of wisdom

[Anonymous Coward]

The operating system running on the greatest amount of computers in the world at this time is TRON/iTRON. It's not the least secure, as it's very simple.

If security only had a direct correlation with how many were using a piece of software, there would be no need for good design practices at all.

Re:a nugget of wisdom

[wnknisely]

Counter nugget:

Count the number of IIs exploits vs Apache and correlate to the number of installations. If your logic held, there should be many many more exploits out there for Apache.

Re:a nugget of wisdom

[j.bellone]

Yes, but we're talking about Desktop operating systems here. You can't buy Apache at Best Buy.

Re:a nugget of wisdom

[User 956]

Web server != entire operating system. thanks for playing.

Re:a nugget of wisdom

[jerw134]

IIS (2) vs. Apache (29)

Re:a nugget of wisdom

[imroy]

So why don't web servers count when 'entire operating systems' do? Web servers are always connected to some sort of network, if not the Internet. They wouldn't be much use otherwise. They often have all sorts of modules/plugins loaded, some third-party. They often have to run all sorts of interpreted languages (Perl, Python, PHP, ASP, etc) with scripts written by all sorts of people. They can also run other executables on the host system. They often have to access a database, either on the same machine or over the network. They often send email and even receive it (e.g confirmation emails).

Most importantly, they're often very public machines (not including intranets). And they can be holding (or have access to) very valuable data e.g banking details, email addresses, passwords. Web servers may be out-numbered by desktop machines, but they're still very attractive targets.

So, would you like to have another try at explaining why Apache HTTP server has been the most used web server for almost ten years now, but is not the most attacked?

Re:a nugget of wisdom

[YU Nicks NE Way]

Count the number of IIs exploits vs Apache and correlate to the number of installations. If your logic held, there should be many many more exploits out there for Apache.

IID 6 has had all of two vulneratbilities reported in the last two years, neither of which was exploitable -- that means zero exploits for IIS 6. During the same period, Apache 1.3.x has had fourteen, at least one of which was actually exploited by a worm, and Apache 2.0.x has done even better, with twenty-seven.

Re:a nugget of wisdom

[Antique Geekmeister]

Sir, that is because Microsoft does not cooperate with CERT in admitting the existence of IIS flaws. CERT cooperates so extensively with vendors that they have hundreds if not thousands of long-existing, deep security flaws in their files, all of which are pending vendor fixes or vendor permission to publish.

And I'm sorry, but I've seen several IIS flaws discussed in internal security documents, causing the companies to hop to Apache. The flaws in IIS are unfixed, and still show up in testing with exploit tools having been sent to Microsoft engineers although I've seen no public announcement from Microsoft or on CERT whatsoever. From this, I conclude that Microsoft sends no announcements to CERT whatsoever: that Microsoft only reads what's on CERT, rather than admitting anything on its own.

Re:a nugget of wisdom

[YU Nicks NE Way]

Since I didn't go to CERT, but to secunia, I don't see what your post has anything to do with anything except your inability to find a way to wriggle out of the simple fact that IIS is currently much more secure than Apache.

Re:a nugget of wisdom

[Antique Geekmeister]

Secunia? I haven't tried working with them. Are they more responsive than CERT? Do you have any concrete reason to think that the same over-cooperation in concealing known vulnerabilities that the vendor hasn't fixed found at CERT doesn't apply as well to Secuina? It might not be the case there: I'm actually curious.

IIS, based on the actual code and discovered vulnerabilities, may be more secure. But you can't base that conclusion on a mere shortage of published reports, especially with factors such as I described for CERT. And some of them will apply to Secunia, even if they don't engage in the passive concealment of known vulnerabilities to protect their vendor relationship in which CERT engages. Factors such as deliberate under-reporting by victimized sites to avoid revealing vulnerabilities will apply to Secunia, even if they're good.

In fact, to get access to source to write security products such as Secunia sells, they may be under an NDA that would prohibit them ever revealing such security flaws!

Re:a nugget of wisdom

[drsmithy]

So why don't web servers count when 'entire operating systems' do?

Because they have highly biased user demographics and relatively miniscule levels of exposure.

Lies, damned lies...

[Gallech]

and Statistics.

I wouldn't say that the guys compiling the stats had an agenda or something- but how do you count bugs/flaws? If you said Linux was one "thing" and didn't account for the various distros, is that realistic? And if you account for the various distros, you will undoubtedly end up with duplicates. Its very much like the problem faced when trying to figure out popularity of a website- do you count hits, page impressions, stickiness...and if you count things differently than I do, which of us is right?

One thing I can say with certainty: Linux does not have fewer flaws that Windows. I have as many (or more) patches to apply to my Linux servers at work each month as I do to my Windows servers. I think its reasonable, however, to say that the flaws that show up in Linux are more transparent. Knowledgable people can look at the code for certain coding practices and find flaws *before* they are reported in the wild- the availability of source code definitely gives Linux an edge in that regard.

Re:Lies, damned lies...

[ninja_assault_kitten]

Why would you end up with duplicates? If someone finds a vulnerability in the Linux kernel, that's a single vul across any one uses the affected Linux kernel. If someone finds a vulnerability in sudo, you don't count it once for each operating system who uses the affected sudo. Also, why wouldn't you expect this? There are 293847239827 UNIX/Linux-based applications written by clueless newbie programmers and published to Freshmeat. Why wouldn't you expect more vulnerabilities on the OSS side of the house? There are far more OSS software developers who dev for UNIX/Linux than there are for Windows. If "Jeffs Super File Manager for Linux" is discovered to have a format string vulnerability, would it suprise you? Probably not, but it would certainly count as a vulnerability in Linux software. Don't get your panties in a bunch. The results are as expected.

Scope

[vorok]

A quick browse over some of the vulnerabilities listed... I think that the issue of scope is not covered at all in the number-quoting.

Windows: XP,NT,Me,98,95
              note that these are all x86...

Unix/Linux (Oh yeah, and Mac too) : All variants of Linux, with all moderately current kernels, running on all architectures. All variants of Unix. Mac OS X.

On the other hand, there are a few positive sides: it included non-OS programs (web servers and user programs and such), which many studies often overlook, or selectively overlook and count Apache vulnerabilities for Linux and not Windows. It didn't try to pump the numbers TOO much. It was not actually a comparison between the merits of any one operating system over another (unlike most studies talked about, which are almost always funded by MS), but in fact was a compilation of the various vulnerabilities out there for each OS, including things like MusicMatch Jukebox, which very few people would claim is an integral part of the OS and can't be lived without, and thus completely eliminating that vulnerability from the numbers.

In regards to numberpumping, it is generally a lot easier to find a vulnerability in a Linux/Unix/OSX program than a Windows program, for the simple reason that a greater proportion of L/U/O programs are open source. You have two angles to attack from, and if you find some problem in the code, you can most likely find other instances in the code where the exact same mistake is made. Whereas the only way to find a vulnerability in a closed source program (most Windows programs, including the OS itself) is to observe and interact with it from the outside. Even if you do find a buffer overflow in some area, it counts as one vulnerability. You can't go look through the source for the rest of the OS and/or related programs, because you don't have it. Assuming a fairly large code base, any vulnerability (that is, a flaw in the underlying structure of the program, not a mistake) would probably be repeated at least 5 times.

If we use that estimate, and assume that only one such flaw was found in a Windows program and all 5 in a Linux/Unix/OSX program, that brings the numbers to this:
Windows 4060
LUO 2328
(ignore the multi-OS ones)

Now, assuming that Linux, Unix, and OSX collectively run on 5 architectures (QUITE modest), that is 5 times the code for any architecture and hardware related problems to arise in, although I would be willing to bet that it doesn't actually increase numbers that much.

However, all of my rampant assumptions aside, the numbers mean absolutely NOTHING, for ANYONE. This is not a study. It is a summary of the vulnerabilities found in 2005. In order for "vulnerability numbers" to mean ANYTHING, they have to be discovered and explored in an impartial study which clearly defines various levels of "vulnerability" beforehand and equally explores all test OS's/programs, which would most likely require source code for all OS's/programs in question, wihch essentially rules out including any Microsoft products in any such study.

Re:Scope

[vorok]

Oh yeah... one more interesting gem. This item popped out at me:

IBM AIX 'RC.BOOT' Insecure Temporary File Creation

A vulnerability has been reported in the '/SBIN/RC.BOOT' script due to the insecure creation of temporary files, which could let a malicious user corrupt arbitrary files with superuser privileges.

It's just one more reason why the numbers are meaningless: creating temporary files in IBM's boot process is absolutely unrelated and has absolutely no impact whatsoever on OSX, or Linux, or BSD.

Re:Scope

[drsmithy]

Windows: XP,NT,Me,98,95
note that these are all x86...

NT runs on multiple platforms. x86, x86_64 and Itanium, at the very least, must be considered (plus PPC for the Xbox360, but I wouldn't consider that relevant to this discussion).

In regards to numberpumping, it is generally a lot easier to find a vulnerability in a Linux/Unix/OSX program than a Windows program, for the simple reason that a greater proportion of L/U/O programs are open source. You have two angles to attack from, and if you find some problem in the code, you can most likely find other instances in the code where the exact same mistake is made.

On the other hand, you have to take into consideration the _vastly_ higher exposure level Windows has.

Now, assuming that Linux, Unix, and OSX collectively run on 5 architectures (QUITE modest),

Not really. x86, x86_64, P[PC], SPARC, Itanium. There aren't many other platforms out there that are likely to be relevant to these stats.

[...] that is 5 times the code for any architecture and hardware related problems to arise in, although I would be willing to bet that it doesn't actually increase numbers that much.

Somehow I don't think there are completely separate codebases for each platform. The vast majority of code in an OS isn't platform specific.

how about a real count...

[Anonymous Coward]

I have seen numbers like this running around for some time. What I would like to see is *someone* actually define a number of catagories (like OS, UI, Apps, Drivers, etc.) and then place specific *named* apps in those catagories and then give me the numbers. So, how many of those bugs are actually OS/driver specific or are vectored through the UI, Apps, etc?

Not so shocking ...

[lasindi]

"researchers found 812 flaws in the Windows operating system, 2,328 problems in various versions of the Unix/Linux operating systems (Mac included). "

If we listened to just the media you would have thought Windows has thousands and the others only had a few dozen. I promise I'm not trolling, but do those numbers stop and make anyone on the site re-think stances? We all saw the numbers that put Firefox with more holes then IE earlier this year too. Could MS be doing a better job, but just getting hammered in the press (who are mostly Apple users by the way)? MS holes get lots of press while other operating systems get a free pass.

If you look at the first post, you'll see that the real count of vulnerabilities isn't so shocking after all:

Windows 671
UNIX/Linux 891
Multiple 1512

Also, when you consider the fact that "UNIX/Linux" includes many different operating systems (e.g., GNU/Linux, *BSD, OS X, etc.), you can't give any one Unix operating system the blame. Remember that although some code is shared between projects, GNU/Linux and the *BSD are more or less completely different code bases. In any case, the simple counts of vulnerabilities don't take into account the severity of each, so the real winner is even more ambiguous.

I find myself defending MS allot on this site, and it's nice to have some numbers from a respected neutral organization to debate some of you guys with. I'm sure after this piece they will be re-classified as MS zealots, but what can ya do.

While Brian Krebs might be tainted by his misrepresentation (see the post I got the numbers from), I can't imagine anyone here claiming that US-CERT is somehow a bunch of MS zealots. In fairness to Microsoft, they've definitely come a long way with SP2, and I don't feel nearly as vulnerable when using an SP2 machine as I did with previous Windows versions (though the recent WMF hole makes me a bit more worried). without considering the severity of each vulnerability. But they're still no where near the point where I would switch from Linux.

Re:Not so shocking ...

[Anonymous Coward]

Also, when you consider the fact that "UNIX/Linux" includes many different operating systems (e.g., GNU/Linux, *BSD, OS X, etc.), you can't give any one Unix operating system the blame. Remember that although some code is shared between projects, GNU/Linux and the *BSD are more or less completely different code bases. In any case, the simple counts of vulnerabilities don't take into account the severity of each, so the real winner is even more ambiguous.

When it comes to the "Apache has more market share than IIS" response this simple fact is usually ignored. Saying what you just said one cannot use the "Apache has more market share" counter argument.

Re:Not so shocking ...

[Anonymous Coward]

According to Netcraft, US-CERT seems confident enough in Linux to use it as their web server OS.

Re:Not so shocking ...

[Anonymous Coward]

WTF? No, seriously, what point are you trying to make? Be specific as your current post sure isn't.

Mod parent idiot.

[Anonymous Coward]

I should like to note that I would be very impressed with any language which does not allow direct memory access and which doesn't need one that does in order to function.

Also, using Java as an example of a secure development environment is like using OS/2 as an example of a secure OS: Nobody uses it, so you can't prove it's secure.

Slashdot ate my angle brackets

[Anonymous Coward]

vector was meant to be a vector<int>.

Ha

[ninja_assault_kitten]

Look how defensive the Slashdot community gets... So freaking funny.

Your not a troll, just an idiot

[SmallFurryCreature]

Windows is one OS with 800 bugs, unix/linux/os-x/bsd is a whole collection from a whole slew of different companies.

Only a MS-tool would not instantly spot this. Others have already pointed this out but of course they are just Unix and OS-X and BSD and Linux hippies. Oh and wich OS makes it unsafe to simple browse the web right now? Thank you. Bill Gates called, he is about to take a dump and needs you to swallow it all.

All this article shows is how easily statistics can be used to tell a complete lie.

Re:Your not a troll, just an idiot

[Metshrine]

But dont these different versions of linux/unix use the same subset of applications? I.E. tar, ftp, gzip, etc?

Re:Other issues

[symbolic]

I've noticed that on some of the 'nix-based alerts, the initial "discovery" was made in 2004, but not reported by various distros until after the beginning of 2005. I also noticed that with some of them, ALL of the distros listed reported the problem in 2004, but then, someone else chimes in right after the beginning of 2005 (Avaya Security Advisory), basically restating what has already been announced by several other parties prior to 2005.

Another Way Of Looking at This

[Anonymous Coward]

Evil doers devised 812 ways of raping women named Jane, and 2328 ways of raping women named Mary or the pets they own.

What we really want to know is who got fucked.

Hard real-time != fast

[Anonymous Brave Guy]

It's fascinating that there are two replies to the GPP, post mentioning using Java in a real-time context, as if that somehow implies that its performance is equivalent to something like C or C++. "Hard real-time" and "fast" are completely different qualities, and having one does not imply the other either way around.

Re:Hard real-time != fast

[Decaff]

It's fascinating that there are two replies to the GPP, post mentioning using Java in a real-time context, as if that somehow implies that its performance is equivalent to something like C or C++. "Hard real-time" and "fast" are completely different qualities, and having one does not imply the other either way around.

Of course it doesn't, but if you carefully read the replies it states that Java certainly does match C in speed:

"Aonix engineers have demonstrated hard-real-time Java that reaches the run-time efficiency of C and offer true compliance with hard real-time constraints".

This is perfectly clear - speed and real-time capability.

Perhaps you don't believe one source. Here are some more:

http://www.cotsjournalonline.com/home/printthis.ph p?id=100149

"Exemplifying the movement toward Java, Boeing has expressed a clear preference for the technology over other software languages. Winner of the lead system integrator contract for the U.S. Armys Future Combat Systems (FCS) program, Boeing is farming out their FCS requirements and telling suppliers they want to use Java; they dont like C++ and they dont like Ada for any new system development. Many suppliers to FCS are therefore tasked to convert reams of Ada code over to Java."

Boeing use a version of Java that is designed for C performance and real-time work.

Re:Hard real-time != fast

[Anonymous Brave Guy]

I actually cut the second paragraph from my previous comment before posting, but since you bring the subject up: yes, I do challenge the claims in those articles.

Let's ignore issues of running on a JVM, and assume that once Hotspot or the like has done its stuff we're dealing with fully compiled code. Even then, Java has natural inhibitions regarding performance compared to a lower-level language like C or C++. These range from its lack of "value types" to a highly portable but necessarily non-optimal floating point model.

Some of these inhibitions can be overcome with sufficiently smart optimisation techniques. The escape analysis stuff that's starting to filter through (but AFAIK isn't in widespread use among mainstream implementations yet) should help a lot with some things, for example.

However, some of the weaknesses, particularly the floating point model, are inherent. If you want truly portable behaviour, you have to use the portable floating point model, which means you can't take advantage of a lot of hardware-based optimisation available to other languages. If you switch to using those optimisations, as I understand you can in the more recent versions of Java, then you pick up the performance but you give up any pretence of getting the same results on all platforms. (I write highly portable floating point code for a living; trust me, you can't have both complete portability and optimal performance, ever.)

In summary, then, to satisfy the claims about Java performance made in those articles, you need tomorrow's Java optimisation technology today and to give up one of the main advantages to programming in Java. I'll concede that the kind of projects mentioned in the articles might be a in position where those two requirements aren't a problem, but most Java developers sure aren't -- at least, not yet.

I suspect it's far more likely that the management teams believe, rightly or wrongly, that their staff will be more productive using Java than, say, C++ or ADA. I doubt that the concerns are purely for the quality of the final product, even in the miiltary field; remember that the US Navy had one of its ships dead in the water after a bug caused the Windows NT code it was running to crash, leaving the ship stranded. Engineers have warned repeatedly against the use of Windows as a foundation for combat systems on US and UK Navy vessels, but they're more likely to be fired for their trouble than to get any sort of rational reaction from senior management.

Re:Hard real-time != fast

[Decaff]

actually cut the second paragraph from my previous comment before posting, but since you bring the subject up: yes, I do challenge the claims in those articles.

Sorry, but then it is you versus Boeing, Mercedes, and others who are investing millions in this.

as I understand you can in the more recent versions of Java, then you pick up the performance but you give up any pretence of getting the same results on all platforms.

But then in that case it is no worse than any other high-performance language (C or Ada), but with enormous advantages in terms of ease of memory management.

(I write highly portable floating point code for a living; trust me, you can't have both complete portability and optimal performance, ever.)

I believe you.

I suspect it's far more likely that the management teams believe, rightly or wrongly, that their staff will be more productive using Java than, say, C++ or ADA.

This is an outrageous claim - are you seriously suggesting that such highly technical decisions (and they are highly technical) are left to management?

Re:Hard real-time != fast

[Anonymous Coward]

You haven't worked for a defense contractor before, have you? Management is responsible for many bone-headed decisions that are technically flawed and sometimes downright specious. In addition, the DoD is responsible for many other bone-headed decisions that are eventually blamed on the contractor, because god forbid the government made a stupid decision and based their entire contract on specious claims.

Re:Hard real-time != fast

[Darius Jedburgh]

People repeatedly demonstrate that Java is as fast as C. They do this for the same reason that members of religious groups keep having to tell themselves that their prefered creator of the universe is better than anyone else's: because the moment they stop reminding themselves they'll realise it's in direct contradiction to reality. Write some CPU intensive code in C and Java yourself and report back. And don't just write some silly benchmark that tests out a tiny part of the optimizer. Write some well rounded code that does a mixture of different things.

Re:Hard real-time != fast

[Decaff]

You haven't worked for a defense contractor before, have you? Management is responsible for many bone-headed decisions that are technically flawed and sometimes downright specious.

So all of Boeing's avionics are determined by defence contractors? How about automotive systems, like BMW and Mercedes - is their use of Java determined by defence considerations?

Of course not.

Re:Hard real-time != fast

[Decaff]

People repeatedly demonstrate that Java is as fast as C.

Indeed.

They do this for the same reason that members of religious groups keep having to tell themselves that their prefered creator of the universe is better than anyone else's

Er - I thought demonstrating that Java is as fast as C is not a matter of faith... there is evidence.

Write some CPU intensive code in C and Java yourself and report back.

Righto. Here you are:

http://www.shudo.net/jit/perf/

And don't just write some silly benchmark that tests out a tiny part of the optimizer. Write some well rounded code that does a mixture of different things.

This sounds very much like the Intelligent Design debate - you get to define any code that anyone else writes that shows that Java can match C as 'not well rounded enough', so that you never lose the argument.

So when C starts to lose its advantage on the 'processor intensive' benchmarks (like those
above) you move the goalposts....

However, why not look at Hypersonic - it is full-featured SQL-compliant relational database written in Java - should be well-rounded enough, surely.

It is fast.

Re:Hard real-time != fast

[Decaff]

People repeatedly demonstrate that Java is as fast as C. They do this for the same reason that members of religious groups keep having to tell themselves that their prefered creator of the universe is better than anyone else's: because the moment they stop reminding themselves they'll realise it's in direct contradiction to reality.

I think it is the other way around. Some C programmers maintain a stubborn faith that their way of working is essential for high performance in the face of increasing evidence to the contrary.

Bugs != volnerability

[a_greer2005]

This artical summery gives the allusioon that "bugs" and volnerabilities are the same thing. GThey are not, bugs can lead to volnerability, but so do "features" in some cases.

What exactlu do tehy call bugs, one mans "bug" is another mans feature. If a function or dialog in open office for example doesn't have the same capability as MS office, or different capability than the Office equivalent, is that a "Bug" or a feature? depends who you ask...

Re:Bugs != volnerability

[TeknoHog]

Looks like your spell checker has a volnerability...

Without dupes :

[Anonymous Coward]

Just try this :
#!/bin/bash


lynx --dump http://www.us-cert.gov/cas/bulletins/SB2005.html > stats.tmp

{

echo "Windows"

sed -e '/ \* Windows Operating Systems/,/Unix\/ Linux Operating Systems/ !d' \
-re 's/^[ \t]+//' \
-e '/^[\*\+] \[[0-9]+\]/ !d' \
-e 's/\[[0-9]+\]//' stats.tmp | uniq -c \
|awk '{sum ++ ; entries += $1 ; print ; } \
END {print "\n\n Sum :\t\t\t "sum "\n Number of entries :\t " entries "\n Sum/Number of entries : "sum/entries "\n\n" }'

echo "Linux/Unix"

sed -e '/Unix\/ Linux Operating Systems/,/Multiple Operating Systems/ !d' \
-re 's/^[ \t]+//' \
-e '/^[\*\+] \[[0-9]+\]/ !d' \
-e 's/\[[0-9]+\]//' stats.tmp | uniq -c \
|awk '{sum ++ ; entries += $1 ; print ; } \
END {print "\n\n Sum :\t\t\t "sum "\n Number of entries :\t " entries "\n Sum/Number of entries : "sum/entries "\n\n" }'

echo "Any"

sed -e '/Multiple Operating Systems/,$ !d' \
-re 's/^[ \t]+//' \
-e '/^[\*\+] \[[0-9]+\]/ !d' \
-e 's/\[[0-9]+\]//' stats.tmp | uniq -c \
|awk '{sum ++ ; entries += $1 ; print ; } \
END {print " Sum : "sum "\n Number of entries : " entries "\n Sum/Number of entries : "sum/entries }'

} | more

Re:Hooray \o/

[Ninjaesque One]

-Mark Twain Attribute yo' quotes, foo.

Unfair

[Kaelthun]

"The ignorant define themselves" why is there even a discussion going on about the essence of the word "flaw"? Fact is that this research has not been fair because all Linux distro's, UNIX variants (such as BSD) and Mac are counted as one, and MS Windows as another. You cannot compare the multitude of Linux distro's to the one-man platform of MS Windows. If there would have been a tally between, say, Redhat, Ubuntu, FreeBSD, NetBSD, OpenBSD, Mac OS (I dunno what version it is in atm) and MS Windows, and all stats would have been listed seperately ... that would have been fair and clear. Now it's just a mash of all these stats with just one simple query on it SELECT bugs FROM stats WHERE os = Windows. THey just mashed the rest together and called it "the rest".

Re:Unfair

[ComputerizedYoga]

thing is, all of those distros use the same software base. Redhat, Ubuntu, *BSD, they're all host to apache, samba, bind, openssh, php, gcc ... they're all essentially the same, once you get past package management, the kernel and the c libraries.

If you want to count "OS" flaws, you need to remove ALL the third-party apps. That means in linux, you'd JUST be counting the flaws in the kernel and glibc, and in BSD only the core system as well. And those aren't even going to be distro-specific.

While you're right that it's probably not fair to shove os-x vulns in with the unix/linux category (os-x is its own unique animal and has a lot of things that no other *nix has) I think it is fair to mash together the F/OSS nixes. Or at least to mash together their non-os-specific parts.

Of course, these comparisons are inherently unfair, if they're used as a metric for "which OS is more secure". That's become something of a moot point. No matter how someone calculates their metrics, someone or another is going to be displeased with their methodology. What's more interesting, and more to the point, is the sheer number of vulns found across the board, and that's the whole point of the story.

Re:Unfair

[tacocat]

I think it is fair to mash together the F/OSS nixes

You have forgotten that the severity and existence of certain bugs in F/OSS have a tendency to depend upon how the software in question is configured. For example: SSH had a security problem, unless you only allowed public/private key authentication. If you're distribution of choice only allowed that authentication mechanism then the security problem should not count against that distribution.

I do consider OpenBSD to be more secure out of the box than Linspire even though they are both a Unix based OS. That difference merits that they be listed seperately.

Otherwise all Windows distributions in effect on the internet today should be put into one group, from Windows 3.11 to Windows XP inclusive. But I don't think they do that.

Ignorance as usual

[sgt scrub]

As soon as I saw OS's grouped together I expected to see another company purchaged evaluation designed specifically for a press release.

After seeing that someone had simply counted lines on a web page as their "research", I realized it was just another ignorant writer putting together anything possible to get the job done.

I think US-CERT is partly to blame. Their page is misleading in that it lists software for *nix OS's under the heading of "Unix/ Linux Operating Systems". They also lists the mistakes some package manager's make while compiling software for specific distubutions. For example: "Debian Horde Default Administrator Password" or "Gentoo webapp-config Insecure Temporary File".

Re:Hooray \o/

[spike1]

That quote has been used to much it's entered the common vernacular, hardly worth attributing it these days.
(besides, I wasn't sure it was mr Clemmens and couldn't be bothered checking)

Wait a second...

[aconkling]

That's almost the number of dupes on Slashdot this year...
[crunches some numbers]
And the trends from last year match, too!

I'm grabbing my tinfoil hat.

Re:Hooray \o/

[ceoyoyo]

ME and prior have been EOLed and so are no longer supported, aren't they? And Vista hasn't been released. So we're left with only a couple (few -- 2003) OS's that it's reasonable to count vulnerabilities from.

And counting...

[Martindale]

A more accurate portrayal of the bug situation would be run down by a count of patched and unpatched bugs at the end of the year.

Windows Server 2003 - Enterprise Edition vs. Red Hat Enterprise Linux
Who has the most unpatched flaws and the better ratio in that one? I'm really not sure.

Windows XP vs. Fedora Core 4
This one's pretty easy...

Windows ME vs. Red Hat Linux 6
Sorry, I couldn't resist.

Windows (Any version) vs. Mac (any version)
Erm, yeah. I had to. I don't know the answer to this one, though.

Re:And counting...

[Anonymous Coward]

"Windows Server 2003 - Enterprise Edition vs. Red Hat Enterprise Linux
Who has the most unpatched flaws and the better ratio in that one? I'm really not sure."

Lets take a look at this (I'll let someone else do the rest of them):
WS2003
76 advisories issued total.
37 in 2005.
12% unpatched.
3% extremely critical.
http://secunia.com/product/1173/

Red Hat Enterprise Linux ES4
136 advisories issues totoal.
136 in 2005.
0% unpatched.
1% extremely critical.
http://secunia.com/product/4668/

Linux has more advisories (especially per year), although Windows has more unpatched. In fairness to both companies, both do a good job patching the more severe vulnerabilities (the unpatched ones on Windows are of low criticality, except this most recent WMF exploit).

Despite the cries that Linux is more secure than Windows, it's certainly not a slam dunk. Some would have you believe that Linux has only 1 or 2 advisories, while Windows 5789 of them per year. But really they both have advisories, about on par with each other. The WMF exploit is a big issue, but short of that, I'd have most people actually take a look at the unpatched advisories, and look at both products with open eyes. I think you'll leave thinking they're not as far part as some believe, but they both have work to do.

Tight code made simple

[Urusai]

I suggest a new, totally secure and bug-free programming paradigm. Example:

void main()
{
    SuperSecureFunction();
    TotallyNotBuggyFunction();
    ImmaculatelyConceivedOperation();
}

I call it Intelligent Design programming. You just have to link to the right libraries.

Re:Tight code made simple

[svtdragon]

Well hell, if you do that, you don't need to write anything, or even have any files on the system. Heaven will anticipate any method calls or parameters and just do the work before you even call them. It's all been done for you.

Re:Tight code made simple

[Jerry Coffin]

void main()

Stop right there. Far from being "bug free", you've just committed one of the best-known sins of C. In C, main is required to return an int. As-is, this has undefined behavior, so nothing (at all) can be predicted about the security (or lack thereof) in the rest of your code.

The first step toward writing really good code is avoiding the most obvious textbook examples of bad code.

Below the underhand...

[ncurtain]

Evil doers devised, and 2328 ways of raping women named Mary or the pets they own.

I would have said that it was more like: 812 Janes went to dives on saturday nights half naked and unchaperoned whilst 2328 Marys also went dancing.

Who was looking after the Marys?

Most of the people who look after the Janes are unpaid good neighbours. It's a bloody good job there's such a hell of a lot of them.

otuh://www.nsa.gov/kids/

Re: Below the underhand...

[ncurtain]

Damn, meant to add this sort of thing doesn't count does it?

Can't buffer overflows

[mrmeval]

Be taken out of the libraries and such? Why is it so hard to remove such vulnerabilites when I've read that there are replacements for weak or exploitable code?

Re:Axe Grinding -- the math is simple

[Vitriol Angst]

Well, I found my own way to interpret this "mash-up" data.

Take the total # of flaws of the Linux distros; 2,328.
The number of distros including Mac -- by pulling a guess out of my hat; 12
Since, we can assume that most UNIX distros are similiar, and we'll be kind by saying the Mac has the same number of flaws, Just divide the total by the platforms and you get... 194.

And, since we can assume this is an "independent analyst" paid for by Microsoft -- we can safely assume that they buried vulnerabilities from Internet Explorer, Entourage/Outlook, and Microsoft Office as the flaws affected multiple operating systems while just throwing in the app flaws that came with the *NIX boxes. So, you can assume that 80% of all vulnerabilities in applications are from these three Microsoft apps. So 2,058 * .80 gives us 1,646 rounded down.

So any single UNIX has about 194 flaws versus 2,458 flaws attributed to Microsoft products. Of course, I could be wrong, but since we are pulling figures our of our collective butts here -- what the hey, right?

But, if you are purchasing software per flaw (and well call the LINUX distros free except for Mac) so, it is still more expensive for each flaw that you get on all combined *NIX's -- since the author assumes you are buying every NIX to acquire every flaw you possibly can. Windows comes out ahead on less cost per flaw.

I really didn't add in SUN -- that would reduce the number of flaws per NIX and greatly increase the cost per flaw. UNIX really needs to step up here -- a user has to really invest in a lot of platforms to achieve a good allotment of flaws.

less ridiculous counting

[harlows_monkeys]

There are a lot of flaws that are countined multiple times in that count. For example, If a flaw is reported, and then 3 updates giving more details are reported, it is counted as 4 flaws in those counts. Here are the counts after a rough attempt at eliminating this overcounting:

• windows: 681
• unix: 1044
• multiple: 1508

From Bob the Bot

[Tablizer]

The problem is obviously humans. If we kill the humans the problems wouldn't happen.

Pile of rubbish

[Anonymous Coward]

I hate to just dump on this article, but I have to. Its basically a pile of rubbish. I don't mean to just insult the authors of the article, I read it, and came to my conculusion with thought and reflection. The basis for my analysis and conclusion follow. Firstly, they never describe or define exactly what they call 'an operating system'. From my computer science textbook (Silbershatz/Galvin), an operating system is strictly the third program running on a computer after power is applied (the first being bios/post instructions coming from the firmware, the second being the bootloader, and the third being the operating system). The operating system has absolutely 0 interaction with the user. There are applications that are usually loaded after the operating system is running that allow user interaction (programs that allow the user to type at the keyboard, use the mouse, or provide some kind of graphical interface to start programs). None of these things are part of the operating system. They interact (make calls) to the operating system. So are the 'flaws' part of the OS, or are they add-on programs, or what? Second, when developing a system in the open such as Linux, people are working on the software all the time. They might add a new piece to a section of code, and might not finish that day, or might need to modify another piece of software to provide complete interaction as intended. Occasionally the partially built pieces will create problems (which Cert then counts). It's a bit like driving by the partially built house and yelling at the contractor 'there's no roof yet!'. Sure, it hasn't been added yet. Next comes the problem of whether the bugs are serious or nusinces. Are they critical or minor or what? Nothing from the article says anything about that. Next comes the issue of whether any of the 'flaws' were fixed after being mentioned, and how soon after were they fixed? Again, nothing from the article. Sorry for being overly critical, but it's a bit like proclaiming 'overcast day caused kids to catch colds and stay home from school'. There is an assertion of fact, some kind of follow on fact that apparently fits somehow, but no logical path to show how you get from A to B, no clear idea of how they got their information, and spare little supporting evidence. A pile of rubbish.

Re:Other issues

[twiddlingbits]

Good catch!! Several other posters wondered if the results were somehow slanted towards M$. Re-couting *NIX '04 bugs as '05 bugs would sure skew the numbers! Like I said when we get an UNBIASED study with severity levels, OSes and releases of each indicated then we can make a fair comparison of "bugginess".

REMOVE EDITOR

[PhreakOfTime]

Will somebody please remove this guy from having the ability to post stories to slashdot? Yes, I already have his stories blocked, and I wonder how many others are doing the same.

The stories are always slanted FAR away from the reality of what was said, and many times are flat out LIES! I first thought it could have been a mistake, but time has shown that this editor does not represent the community in ANY way whatsoever! This is pathetic! Im not going to waste time digging through all the previous examples of this editor, anyone can search this out in the slashdot archives.

I wonder how many people have simply stopped coming here since he became an editor? I know my own visits have declined greatly for that exact reason. And I can see that the level of posts has also trailed off noticably. Slashdot makes money by advertising, so how long is it going to take before the owners notice that ONE person is causing you to lose MONEY!

Re:REMOVE EDITOR

[Anonymous Coward]

if you blocked the editor, what are you even doing in here posting? Why is your visits declining due to some author who's posts you should clearly not even see if you have him blocked

Re:Other issues

[symbolic]

To make matters worse, as some others may have pointed out, there are security issues that are listed multiple times. The Apache mod_ssl alert, for example, is listed nine separate times, but they all refer to the exact same issue- like that won't skew the results.

I'd be embarrassed if I were the Washington Post, as it appears as though someone didn't do their homework.

From Secunia

[badriram]

Well, the numbers are shocking, when I went to secunia, and compared windows XP (with all the crap that comes with it) and just the Linux kernel 2.6.

Linux kernel itself(no other programs) : 33 advisories
Windows XP(including IIS, libraries, .net etc): 45 advisories

Obviously a simple count of vulnerabilities is a real stupid way to compare things, but i would not claim linux is any more secure than windows or the other way around. You are better of using what OS you know better, and secure better. But MS needs to take one extra step of making people logon by default as regular non-admin users. Because if people were, most of the flaws we see in application will have very low impact.

Re:From Secunia

[Anonymous Coward]

If you went as far as looking up the counts on secunia then why didn't you take it one-click further and look at the number of unpatched vulnerabilities and the criticality of the vulerabilties?

Yes, simply counting vulnerabilities is idiotic, but for you to then claim that linux is not any more secure than windows is disingenous, at best. Take at look at the stats!

http://secunia.com/product/22/?period=2005#statist ics
http://secunia.com/product/16/?period=2005#statist ics

I'd be curious to know...

[TBone]

...how many of the UNIX/Linux vulnerabilities were found (and then subsequently patched) because someone simply found a buffer overflow or the like in a code review.

How many code reviews find and fix bugs for which no exploit exists in the wild for *ix?

How many patched fixed bugs for which there was no exploit in the wild for Windows?

MOD PARENT UP

[Anonymous Coward]

attack on Microsoft... check!
defending open source... check!
"nifty" in post... check!
Yup, he passes: MOD PARENT UP.

Only 5198?

[Flwyd]

My company's Bugzilla database shows 5580 bugs opened in 2005. So I guess if bugs marked as duplicate and invalid are removed, our software accounted for almost all 5,198 software flaws of 2005.

So... what's the secret you guys are hiding from us?

Then I guess I should quit coding in C and ...

[Skapare]

Then I guess I should quit coding in C and go back to assembly.

Most ridiculous stat ever

[Stan Vassilev]

Voting for most ridiculous stat ever posted in an article for Slashdot (sand the **AA losses from 'piracy')

You M$ apologist!!

[MacDork]

Yeah, whatever dude. What I'm hearing is the Linux/Mac crowd fixed 2000+ bugs while Microsoft only squashed about 850. To be unbiased, let's assume that each platform has an equal number of bugs, 3000 for the sake of argument. Anyway you spin that, we're closer to being done than they are!

;-)

Who's more stupid?

[geekee]

"Brian Krebs is clearly either extremely stupid, or has an axe to grind. If you look at the Cert Cyber Security Bulletin 2005 Summary, you can see that many of the lines in it end in "(Updated)" A simple count of lines gives the results that Brian quotes, however there are far more "(Updated)" entries in the Unix/ Linux Operating Systems section."

The author isn't trying to make a security comparison between the two OS's. Not once does he even imply one OS is better than another based on this list. So why are you trying?

Hmm

[Kaelthun]

To be perfectly honest with all of you, we all know what the better operating system is, don't we? This shouldn't even be a discussion as the battle of the operating systems has already been won, the illiterate crowd just has to find out...

Re: YOU CAN'T WRITE SECURE C

[FukYa]

Ever heard of Qmail? All C, used by thousands for years, never been exploited, extremely secure. Just one example. There are many out there. Get a clue.

(hard real-time Java) != Java

[lordcorusa]

I fully agree with you that the Java language is capable of efficient real-time use. However, I think that everyone needs to be perfectly crystal clear that the Java environment to which most Java developers are accustomed is not.

Hard real-time Java programming is vastly different from normal Java programming. Most of the standard Java class libraries are gone. Exception handling is gone. Automatic garbage collection is gone. Almost all third party class libraries are gone. Coding hard real-time apps in Java feels very much like coding C apps from scratch, even if you don't have to manually allocate and deallocate blocks of memory. From the article:

JRTK, a hard-real-time mission-critical subset of the Real-Time Specification for Java (RTSJ) as defined by the Java Community Process, includes many efficiencies over standard Java offerings. No garbage collection is used on objects in the real-time heap. A standard subset of Java libraries is restricted with each library's time and memory resources clearly defined. Partitioning clearly separates soft real-time components from hard-real-time components to ensure hard-real-time schedules as well as program reliability and robustness.

I guess my point is this: hard real-time Java is not the Java with which 99.9% of so-called Java developers are familiar. Choosing Java over C or Ada for a hard real-time system will not enable you to hire lesser programmers, nor will it significantly increase your pool of eligible employees. No matter which language you use, to do hard real-time systems correctly and effiently you must hire only top-tier programmers. Top-tier programmers can make use of any relevant language. Hire any lesser programmers and they will screw up, regardless of language choice.

Re:(hard real-time Java) != Java

[Decaff]

However, I think that everyone needs to be perfectly crystal clear that the Java environment to which most Java developers are accustomed is not.

Sorry, but you are wrong. It certainly can be the standard Java environment:

http://www.esconline.com/boston/workshops/

"10:00-10:50 Introducing the Sun Java Real-Time System - Greg Bollella, Sun Microsystems"

"The Real-Time Specification for Java defines a set of library calls and semantics which, when implemented within a general-purpose Java virtual machine, allow developers to control & predict the temporal behavior of an application."

"The Sun Java Real-Time System (Java RTS) is based on the HotSpot Java Virtual Machine and supports Java Platform Standard Edition on multiprocessor architectures."

The Standard Edition is exactly the same Java environment most developers used. In fact, Sun demonstrated a real-time Java application running alongside non-real-time applications on the same VM.

I guess my point is this: hard real-time Java is not the Java with which 99.9% of so-called Java developers are familiar.

This depends entirely on the implementation. Some real-time Java isn't the familiar Java (especially when cut down for embedded systems), and some is. You can't generalise.

Choosing Java over C or Ada for a hard real-time system will not enable you to hire lesser programmers, nor will it significantly increase your pool of eligible employees. No matter which language you use, to do hard real-time systems correctly and effiently you must hire only top-tier programmers. Top-tier programmers can make use of any relevant language. Hire any lesser programmers and they will screw up, regardless of language choice.

Yes, but using Java will give you definite advantages - a well-known and trusted threading model and effective garbage collection.

Re:(hard real-time Java) != Java

[lordcorusa]

Note: When I refer to language, I mean the syntax and semantics and primitive types. When I refer to environment, I refer to the language plus any standard libraries; I am not refering to a particular VM. I think my definitions may be the source of some of the confusion, as Sun appears to want everyone to think that the java.* and javax.* libraries are part of the language. As far as I am concerned, they are just part of the standard environment. (I bend my own definition a little to include packages under the java.lang library as being part of the language, because they are object-oriented wrappers for the primitive types.)

Your original post mentioned work by Aonix on hard real-time Java. My post referred to Java features that are not able to be used in hard real-time applications. Here is my reference; granted it's a year old, but I haven't found anything newer to contradict it. The author is (or was at the time of writing) in charge of the Aonix real-time JVM.

http://www.stsc.hill.af.mil/crosstalk/2004/12/0412 Nilsen.html

Note the table of differences between traditional Java, soft real-time Java, hard real-time Java, and safety-critical Java. As you can see, hard real-time and safety-critical Java are highly restricted compared to traditional Java. Safety-critical is a subset of hard real-time that is even more strict; it requires formal proofs of safety and therefore throws out most Java features and standard libraries, leaving only the core syntax and single-threaded semantics of the language. (Well technically, safety-critical allows multiple threads but they cannot overlap, so its like single threaded programming for purposes of proofs.) Safety critical requirements are defined by FAA specification DO-178B and several JVM suppliers are working on DO-178B-compliant JVMs.

Soft real-time applications can use all (or almost all) of the Java standard libraries, whereas hard real-time applications can use only a restricted subset of the standard libraries and safety-critical applications are restricted to an even smaller subset of the standard libraries. Therefore, one great advantage of the Java environment (remember my definition of environment), its extensive standard library, is neutralized with respect to hard real-time and safety-critical applications.

Furthermore, almost all third party libraries depend on standard libraries that are forbidden under hard real-time or safety critical constraints. Therefore, these libraries are also forbidden and another great advantage of the Java environment (remember my definition of environment), the extensive field of third-party libraries, is lost to hard real-time and safety-critical applications.

The Real-Time Specification for Java defines a set of library calls and semantics which, when implemented within a general-purpose Java virtual machine.... [snip] In fact, Sun demonstrated a real-time Java application running alongside non-real-time applications on the same VM. > Note the emphasis on the word "within". Applications that implement real-time features get the JVM+RTS. Applications that do not implement real-time features fall through to use the traditional JVM. However, non-real-time applications do not automatically become real-time applications simply by being run on Java RTS. Nothing here contradicts my original assertions.

I'd like to know more about the real-time application they demonstrated. What kind of real-time application was it: soft or hard? Did you see the source code of the real-time application? If so, what libraries did it use? The link you provided didn't provide much concrete information. However, it did provide a link to Sun's official Java RTS page:

http://java.sun.com/j2se/realtime/

I am not sure how they can claim conformance for soft real-time, because they do not yet provide a real-ti

what's your problem?

[penguin-collective]

At the end of the day, GC is a useful tool for many programming jobs, but it's only a tool, not a silver bullet. It's no substitute for a good programmer who knows what he's doing.

Perhaps your problem is that you don't understand what a "safe language" is. A safe language is a language that makes guarantees about type errors, error detection, and fault isolation. A language with dynamic memory allocation needs to have a GC in order to be safe. A safe language does not make guarantees about security or parallelism or race conditions, it doesn't necessarily make programming any easier, and it doesn't necessarily help the programmer avoid errors.

And I make this case without, until now, mentioning the IME very real problem that a lot of cheaposoft programmers who grow up relying on GC don't have the same appreciation of low level mechanics as those who don't,

No, the problem is that there are too many people like you in this industry, people who don't even understand what a basic concept like a "safe language" means.

Obligatory Quote

[Anonymous Coward]

Bender, sleeping: "Hey, sexy mama... Wanna kill all humans?"

What problem?

[Anonymous Brave Guy]

Perhaps your problem is that you don't understand what a "safe language" is.

Oh really? And who exactly are you to tell me, or anyone else reading this, what a safe language is? Your argument is a common logical fallacy -- a weak appeal to your own authority -- and nothing more.

My interpretation of the word "safe", and also the definition given by an English dictionary, would be "not in any danger". Your definition conveniently excludes several common dangers to programmers and focuses only on a single, narrow problem, yet if you are to be completely safe, you cannot exclude anything. Any approach that addresses less than that may be safer, as GC may be most of the time, but it certainly isn't safe.

This is my point: some people focus on GC so much that they forget to address other problems. There are languages that do make guarantees about security, use safe parallelised processing implicitly, make programming much easier, and avoid many other classes of programmer error. Claiming that any language that provides GC but does not do these things as well could possibly be "safe" is irrational, and believing that your code is safe because you use such a language is delusional.

Re:What problem?

[penguin-collective]

Oh really? And who exactly are you to tell me, or anyone else reading this, what a safe language is? Your argument is a common logical fallacy -- a weak appeal to your own authority -- and nothing more.

I'm not telling you anything on my own authority; these terms have specific meanings in computer science. If you don't know what they are, look for "safe language" on Google Scholar.

This is my point: some people focus on GC so much that they forget to address other problems.

There is little point addressing other problems before one addresses runtime safety.

Claiming that any language that provides GC but does not do these things as well could possibly be "safe" is irrational, and believing that your code is safe because you use such a language is delusional.

As I was saying: GC is necessary for safety. The fact that it is not sufficient is so trivial that only someone completely unfamiliar with the subject would find it necessary to point that out.

Re:What problem?

[Anonymous Brave Guy]

I'm not telling you anything on my own authority; these terms have specific meanings in computer science.

Fascinating. I've studied academic CS, and I've heard of thread safety, type safety, exception safety, memory safety and probably others I've forgotten just now. And yet I've never heard anyone refer to a "safe language" as a blanket term, nor seen any formal definition for "safety" without qualifier. I'm guessing you mean memory safety here, but as someone apparently versed in CS, you of all people should be able to see that there are other safety issues to be considered in language design as well. That's all I'm saying here.

There is little point addressing other problems before one addresses runtime safety.

And there are more aspects to runtime safety than memory safety. There is little point discussing the correctness of a program that will never terminate, for example.

As I was saying: GC is necessary for safety.

I never said it wasn't, though your model presupposes the existence of garbage to collect -- not all languages have explicit or manual memory management in the first place -- and "garbage collection" is a rather imprecise term covering a wide range of techniques for ensuring that memory is guaranteed to be released. In any case, you're the person who introduced the term "safety" into the discussion.

The fact that it is not sufficient is so trivial that only someone completely unfamiliar with the subject would find it necessary to point that out.

If it were as trivial as you make out, the world wouldn't be full of evangelists who think GC is some sort of magic solution to all programming's problems.

And please save your ad hominem attacks for someone who doesn't see through them. I do this stuff for a living and spent several years studying it academically too. You'll make a far more convincing case for whatever you're trying to say if you stick to facts and reasoned argument.

Re:What problem?

[Anonymous Coward]

I've studied academic CS, and I've heard of thread safety, type safety, exception safety, memory safety and probably others I've forgotten just now. And yet I've never heard anyone refer to a "safe language" as a blanket term, nor seen any formal definition for "safety" without qualifier.

Well, as I was saying: look on Google scholar and you'll find many instances of the term; it usually refers to languages that guarantee type safety (which comprises memory safety and some aspects of exception and thread safety).

If it were as trivial as you make out, the world wouldn't be full of evangelists who think GC is some sort of magic solution to all programming's problems.

They are generally not saying that it is a "magic solution to all programming's problems", they are saying that it is necessary to address serious real-world software development problems, without claiming that it is sufficient. I'm sorry you are confused about this subtle distinction, but that's not their fault. And, although you use a lot of weasel language, your postings suggest that you even disagree with the necessity of garbage collection.

And please save your ad hominem attacks for someone who doesn't see through them. I do this stuff for a living and spent several years studying it academically too.

You made it "ad hominem" by using yourself as an example and saying that if we all were as brilliant and experienced as you, then software would be much better. That made yourself and your qualifications a legitimate part of this discussion.

Trimming down the list some more...

[sidewinderx2]

I just went to CERT's website and copied down the whole list of flaws, and realized most of them are not OS related... so i then went down the list for the Window OS's flaws and copied down only the ones starting with Microsoft, and went down the list for Unix/Linux and copied down only the entries with Multiple Vendor. Then, i removed the entries with (Updated), and the resulting list was:
Microsoft: 120
Unix/Linux: 192

Then, under the Microsoft list, i just selected the ones starting with Microsoft Windows, and similiarly under Unix/Linux, selected just the ones starting with Multiple Vendor Linux Kernel (not including Linux Kernel 64 bit). Then, the results were:
Microsoft Windows: 43
Unix/Linux: 77

Any thoughts, anyone? That seems suspiciously low for windows problems, but dispite Microsoft's image, i do think that they're doing a lot better security wise than before, and doesnt deserve ALL of the crap that they're getting from a lot of the people here. Seeing all the Updated tags on the Unix/Linux list, it does seem, and i do know, that the community responds a lot faster to any flaws found, but still, Windows i think should really be given fairer treatment for what they're doing to try to fix their problems.