More Info on Debian.org Security Breach

mbanck writes "James Troup (part of the Debian System administration team) has published more information on the recent compromise of four debian.org machines. The attack vector seemed to be a sniffed password of an unprivileged account, from which the attacker somehow managed to gain root and install the suckit rootkit and crack the other machines. As the machines were fairly uptodate with respect to security, an as-of-yet unknown local root exploit might be in the wild, so keep an eye on your boxen.Note that the main ftp archive running on a sparc machine was not compromised, so the exploit might not yet be ported to non-i386 architectures."

Comments

Boxen..

[WeblionX]

Here come the comments about the word "boxen..."

Re:Boxen..

[Chuck Chunder]

Someone needs their ears boxen.

Re:Boxen..

[Anonymous Coward]

Server: Did you get the dick?

Re:Boxen..

[core plexus]

Zero Cool and Duke Nukem from the 90's called, they want their boxen back.

-cp-

President Bush to Liberate Alaska

Re:Boxen..

[Stormie]

If you call your computers "boxen", I hope they get cracked and rootkitted.

Re:Boxen..

[Anonymous Coward]

Yeah, the correct plural is "Debia".

Re:Boxen..

[Anonymous Coward]

no, that would be Debii

Re:Boxen..

[AndroidCat]

It's a perfectly good middle-english plural. Perhaps they just have rather olde boxen to develop on?

Re:Boxen..

[inode_buddha]

Damn... I was just recovering from all those 20-year-old "virii"...

Re:Boxen..

[Qrlx]

I thought Debian was the plural. In singular form it's Debius.

Re:Boxen..

[Anonymous Coward]

Hell yea. Nothing is more stupid than people who call their boxes "boxen". But then again I frikking HATE the word "Spam" for junk email. So I guess that's just me.

Re:Boxen..

[Anonymous Coward]

When the finishing moment of the face winds round
When life flows out upon the ground
I'll be the only sliding sound
That turns your brain's remains around.

Re:Boxen..

[nyctopterus]

It's a perfectly cromulent word. A noble linux emboxens the smallest geek.

Re:Boxen..

[Li0n]

Debian = Debra + Ian Murdock

Re:Boxen..

[Basehart]

pswd: b0x3n

Re:Boxen..

[Anonymous Coward]

This might help.

Re: Boxen..

[Black Parrot]

> Here come the comments about the word "boxen..."

Shouldn't it be "bokii"?

Re:Boxen..

[EventHorizon]

Call Tyson.

Re:Boxen..

[Frymaster]

while we're at it... it's a little known fact that "suse" is a german anagram for "sue us" - a direct jab at sco.

and now that i'm on a "roll" - why the hell aren't the santa cruz organization and stanford university networks actually in santa cruz or stanford university? at least ibm is international...

Re:Boxen..

[Mattcelt]

No kidding? I had just assumed that someone had taken up on Brian Regan's pluralizations, like boxen and moosen.

Another of my favorites:
"I before E except after C
and when sounding like A as in neighbor and weigh
or on weekends or holidays or all throughout May
and you'll always be wrong no matter what you say!"

He's a very funny comic. There's a fan site that's worth checking out too.

Re:Boxen..

[Anonymous Coward]

suse is an anagram for "verklagt uns"? interesting...

Re:Boxen..

[Anonymous Coward]

see, now this is funny

Re:Boxen..

[NattyDread]

"I before E except after C and when sounding like A as in neighbor and weigh..."

... since we're using (middle) English ... that should be "neighbour" there neighbour ;)

Re:Boxen..

[Xilman]

Another of my favorites: "I before E except after C and when sounding like A as in neighbor and weigh or on weekends or holidays or all throughout May and you'll always be wrong no matter what you say!"

Seize weird Keith?

Paul

Re:Boxen..

[AndroidCat]

No, there's still a few hold-overs left that use the en illegular plural like oxen or brethren. I could find more examples in paper documentation, or I could go have my first cup of coffee this morning. Tough call. A quick google .. Go slashdot Stephanie's student paper.

Re:Boxen..

[aulendil]

First, it's irregular, not illegular ;-).

Second, ox is a noun of the old weak declension, or a n-stem, whereas the noun brother with the arcaic plural brethren is a noun of the root-declension.

Third, neither of these declensions are very productive, and neither of them have been for a very long time. Therefore it's all the better if you decline box/boxes than any old plural of which you have no idea how to use properly.

Fourth, boxen doesn't sound cool, it just shows your lack of knowledge of linguistics.

Fifth and last, this is funny, how come that people who knows, and correctly so, that language is a constantly evolving system use that knowledge to defend a plural like boxen, when some mechanism of language they doesn't know of contradict that statement?

This really isn't grammar-nazism

Re:Boxen..

[VernonNemitz]

Folks, "Boxen" could be just a simple typo for "Boxes", PROVIDED that the typist was using a Dvorak keyboard layout (where N is adjacent to S).

Re:Boxen..

[tiger99]

Cromulent? Bill's evil spellchecker, which is all I have at work, suggests "corpulent" or "crapulent". Please enlighten us.

Re:Boxen..

[AndroidCat]

Of course my spelling is illegular. I did mention the coffee right? ("they doesn't know"? :^)

Off to caffievolve to the next level, and the language can continue to evolve/mutate as it wants to.

Re:Boxen..

[Anonymous Coward]

No no no! You're not saying it right! You have to say "I wish your 'boxen' would get cracked and rootkitted, right now!" Is that so hard, eh?!

Re:Boxen..

[Anonymous Coward]

boxen: /boksn/, pl.n.

[very common; by analogy with VAXen] Fanciful plural of box often encountered in the phrase 'Unix boxen', used to describe commodity Unix hardware. The connotation is that any two Unix boxen are interchangeable.

Which part of this is hard to understand?

Re:Boxen..

[nyctopterus]

Err, it's a Simpsons reference. "Cromulent" isn't a word - that's the joke (hence the +4, funny).

Re:Boxen..

[dDrum]

It's not Boxem It's boxii from the latin... ;)

Re:Boxen..

[Anonymous Coward]

It's easy to understand, just stupid. Also, citing Eric Raymond as an authority means you are idiot.

Re:Boxen..

[jrohr]

It's a perfectly good middle-english plural. ... as well as present-day standard German. (probably Dutch, too. And possibly even Scandinavian Norwegian, Danish, Icelandic, Swedish.)

Re:Boxen..

[jrohr]

It's not Boxem It's boxii from the latin... ;)

You couldn't be more wrong. "-ii" only occurs if the stem of the respective noun already contains an "i", e.g. sagitari-us -> sagitari-i. If it ends in "x" it anyway belongs to a different class which usually has its nominative plural ending in "es", whereby the "x", which is just a concatenation of the stem's last consonant and the case ending "s" is replaced by "c". I.e. "boces" would be correct, (the "c" is historically pronounced as "k".) Like "pater -> patres" or "dux" -> "duces"

Re:Boxen..

[elemental23]

That would be bitten, not boxen.

Re:Boxen..

[Anonymous Coward]

Please, don't ruin the typo as an honest excuse by using these bullshit made-up excuses.

Re: Boxen..

[Anonymous Coward]

How about "boces"

Re:Boxen..

[Anonymous Coward]

Next up: the amazing 1337 haxx0r ESR will teach you more nonsense words to use at the next party you don't get invited to because you're a pathetic (wannabe) "hacker" and no one can stand you because all you do is talk about shallow bugs and firearms and how stupid everyone who isn't a "hacker" is.

Re:Boxen..

[Tony-A]

Methinks boxen is a legitimate term with a meaning distinct from boxes.
Derivation is a parallel to vaxen as the plural of vax, probably paralleling vixen as the plural of fox since vaxes sounds rather ugly. It's not Anglo-Saxon, but comes from the '70s if I remember correctly.
If it's just the plural of box, boxes is correct. Boxen implies some sort of cohesion so that the assemblage functions as one loosely coordinated entity.

Re:Boxen..

[aulendil]

probably paralleling vixen as the plural of fox since vaxes sounds rather ugly.

Vixen is singular of a noun 'female fox', not an old plural for fox. Vixen is derived from the same root as fox though.

I did it!

[Anonymous Coward]

Yep. All me. Cause i'm FP on slashdot.

Debian//?

[Anonymous Coward]

Thats what you get for using debian :P

If security is paramount.

[Anonymous Coward]

Be glad you're not a turkey or a piece of my pie in my house.
Happy Thanksgiving.

Re:If security is paramount.

[Anonymous Coward]

Should I be glad I'm not a turkey, or just a turkey in your house?

It's turkey time, gobble gobble! *laff*

Uhm anywa happy thanksgiving everybody, even you furrners who don't celebrate "real" holidays (i.e., any of our made-up american holiday where we pretend it has some religious significance but it's just an excuse to stuff our obese faces with yet more food).

KIRK!

[Anonymous Coward]

Captain's Log: My Anus is too Fucking Tight

One day Captain Kirk was maiming his cock with a horseshoe when suddenly Mr. Spock ran up to him and shoved his pointy ear up his butt. "What is this for!" the fag captain said. "FAGS FOR YOU AALL!L!!!" the ancient alien howled as suddenly he farted and Captain Kirk twirled around in a daze and his foreskin twisted and his kidney stones turned into wooden beads. He pulled out his pistol and shot lasers at his chastity belt and suddenly he hurdled his dick into Captain Kirk"s bellybutton and it tore his flesh while Spock fucked his stomach. Kirk hollered out loud and Mr. Spock threw his shoes to the floor and wrinkled his penis until Kirk bellowed out to make it stop. A maelstom of shit whizzed around the ship and suddenly a giant fag appeared out side and the U.S.S. Enterprise went up his butt. "Oh what the hell have you gotten us into NOW!" Captain Kirk said as he oozed a condom back on his dick and put his panties back on. "OOH!H!!!!!!" Mr. Spock started fucking him again and shoved his phazer up his butt. He dissolved his glands and exploded his turds and finally a queer klingon hurdled through the door and smashed Kirk with his butt hairs. A maniac sucked his dick and suddenly Mr. Spock fagged Kirk so hard that his intestines burst open and he died.

*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*
g_______________________________________________g
o_/_____\_____________\____________/____\_______o
a|_______|_____________\__________|______|______a
t|_______`._____________|_________|_______:_____t
s`________|_____________|________\|_______|_____s
e_\_______|_/_______/__\\\___--___\\_______:____e
x__\______\/____--~~__________~--__|_\_____|____x
*___\______\_-~____________________~-_\____|____*
g____\______\_________.--------.______\|___|____g
o______\_____\______//_________(_(__>_\___|_____o
a_______\___.__C____)_________(_(____>_|__/_____a
t_______/\_|___C_____)/______\_(_____>_|_/______t
s______/_/\|___C_____)_KIRK!_|_(___>_/__\_______s
e_____|___(____C_____)\______/__//__/_/_____\___e
x_____|____\__|_____\\_________//_(__/_______|__x
*____|_\____\____)___`----___--'_____________|__*
g____|__\______________\_______/____________/_|_g
o___|______________/____|_____|__\____________|_o
a___|_____________|____/_______\__\___________|_a
t___|__________/_/____|_________|__\___________|t
s___|_________/_/______\__/\___/____|__________|s
e__|_________/_/________|____|_______|_________|e
x__|__________|_________|____|_______|_________|x
*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*


I hate you, I hate your niggers, and I hate your niggers.

KIRK REIGNS SUPREME!

Brought to you by: KIRK TROLL

Fuck GNAA, TROLLKORE, AND CLIT. You all massivly fail it, you gay homofags.

Re:KIRK!

[Anonymous Coward]

This is a pathetic troll attempt, and I hope you remain modded OT as you really don't deserve to be modded Troll. Ooze a condom? Smashed with butt hairs? Dude you're in the junior league, try perfecting your trolling somewhere else before you come here and fight it out with the pros, from the likes of above you haven't even made it in the ring.

at which point

[gearheadsmp]

After finding out the suckit rootkit was used, Bill Clinton spontaneously appeared and began saying, "Suck it! Suck on it! Suck it! .."

Re:at which point

[Anonymous Coward]

He's not working for the Chinese again, so he has to do something.

Re:at which point

[t0ny]

So that means Monica Lewinski wrote the Suckit rootkit?

Ask Slashdot

[iamatv]

Ask Slashdot: Television you would hate kids to watch

This is a revision of the earlier poll: Are Americans and Europeans really like we expect?

State your country, and put in order the things you would most hate your child (or other children) to watch on television.

1. Man being shot (acted)
2. Man being shot (real)
3. Somebody saying "God damn it!"
4. Somebody saying "The fucker's fuckin' fucked."
5. Women's breasts
6. People having sex (not weird porno sex, but not hidden behind sheets either)

Current Results
---------------
America, 2 1 6 4 5 3
America, 6 1 4 2 5 3
America, 1 6 2 5 4 3
America, 6 5 3 4 1 2
Australia, 2 1 4 6 5 3
Australia, 2 1 6 4 5 3
Canada, 2 4 3 1 6 5
New Zealand, 2 1 3 5 6 4

Re:Ask Slashdot

[Anonymous Coward]

US of A

2,6,5,4,1,3

Re:Ask Slashdot

[HarryCallahan]

America 3,5,6,4,2,1

Re:Ask Slashdot

[Anonymous Coward]

2 6 1 4 3 5

from the UK.

Nice concept, btw.

Re:Ask Slashdot

[Anonymous Coward]

The Sovereign State of Nyambi.
I don't care what my kids watch. They've been preconceptively aborted, however, so they ain't watchin much.

Re:Ask Slashdot

[Anonymous Coward]

Australia, 2 6 1 5 4 3

Re:Ask Slashdot

[Anonymous Coward]

USA 2 4 3 1 6 5

Re:Ask Slashdot

[hdparm]

Soviet Russia, 6 5 4 3 2 1

Re:Ask Slashdot

[Anonymous Coward]

New Zealand, 2,6,1,4,5,3

Re:Ask Slashdot

[Anonymous Coward]

Canada, 2 1 4 6 5 3

Re:Ask Slashdot

[Anonymous Coward]

canada, 2 4 a 6 5 3

Re:Ask Slashdot

[Anonymous Coward]

I wouldn't be pleased with my children viewing [1] if the context of the acted shooting was to glamourize violence / murder.
[2] could also be dodgy, but as it is a real thing that has happened, that would probably be okay, as long as some moral framework was implied too.
I have no problem with them viewing [3] or [4] .. you hear worse in the playground these days.
[5] is okay too, it's on page 3 of the Sun newspaper every day. I'm quite content for them to be desensitised to the 'naughty' view of breasts.
Not sure about [6]. I'd only like them to see this if it was after having the 'birds and bees' talk with them. In fact I may even show them such videos myself to give an idea about what sex can be, provided I thought they were mature enough to handle it.

So my order would probably be ... 1 2 6 (3 4 5)
(The ones in brackets are at the same level)

From the UK, by the way.

Re:Ask Slashdot

[Anonymous Coward]

Canada, 2 1 4 6 3 5

I have my erect penis in my hand.

[Anonymous Coward]

What should I do now?

Please help!

Re:I have my erect penis in my hand.

[Anonymous Coward]

get your hand off it and apologize to the audience!

Re:I have my erect penis in my hand.

[Fecal Troll Matter]

Try this on for size.

Re:I have my erect penis in my hand.

[Anonymous Coward]

Close your eyes and twist.

Re:I have my erect penis in my hand.

[Anonymous Coward]

WANK IT

WANK IT HARD

Human Error

[jefbed]

This incident reminds us of the importance of password security. It is sad to see one weak password responsible for such a breach. I think that it would be a good idea for the future to move away from the traditional unix password. An appropriate replacement would be something similar to RSA passphrase mechanism used by secure shell. A random passphrase with a minimum lenght would be idea. The user is the greatest security hole.

Re:Human Error

[Tyler Eaves]

Random passphrase?

Repeat after me: The best password is the one that isn't stikie'd to the monitor and/or keyboard.

Re:Human Error

[SugoiMonkey]

I say we cut out the user.

Re:Human Error

[ctr2sprt]

Clearly we need some way to move away from traditional passwords, but RSA keys isn't the way to go. They're impossible to remember, which means you need to store them on a computer. That makes them vulnerable to copying. You can password-protect them, of course, but then you're in the same situation as before (actually worse, for the same reason /etc/passwd is less secure than /etc/shadow).

That's not to say that RSA or some similar system won't be part of a good solution... but there definitely needs to be some other component. (For example, the private key might be encrypted by a biometric signature or keycard or similar. While that still leaves the system vulnerable to physical attacks, it more or less eliminates network-based ones as long as you use secure protocols.)

Re:Human Error

[Anonymous Coward]

Uhh, I dunno if you noticed, but it wasn't a password alone that did this much damage. The account broken into was unprivellaged, meaning it was just a simple user account.

In theory, a secured system can have this happen to it and the attacker will have fun deleting a single home directory before they run out of damage to do.

In practice, a single local privelage escalation attack is all it takes. Maybe this will end up being a good thing in the end, we get to find a previously unknown local root exploit, fix it and improve the Debian security practices, all in one move.

Re: Human Error

[Black Parrot]

> This incident reminds us of the importance of password security. It is sad to see one weak password responsible for such a breach.

I'm apologize - I never imagined that they would guess 'mydebian'.

Re:Human Error

[buffer-overflowed]

Yea, if it weren't for those users, my network would be perfect. No complaints = no problems. That's how I know my network is perfect, during vacations, no one complains about anything, so it must be perfect.

Re:Human Error

[nertz_oi]

There really is nothing that can protect against breaches. If person A is able to access computer X, person B will be able to fool X into thinking they're A. There is no way around it.

But if person A isn't able to access computer X, neither will B. So the only way to stop crackers is to get rid of users altogether ;)

Re:Human Error

[jkrise]

It is sadder to see that most of us think a 'safe' password means a secure system.

-

Re:Human Error

[jkrise]

Will you cut off your head if you got a headache?

-

Re:Human Error

[jkrise]

While that still leaves the system vulnerable to physical attacks, it more or less eliminates network-based ones as long as you use secure protocols.

In other words, you've achieved nothing. The issue here is the protocols, NOT passwords. Since these are not unnder the control of users, we should assume that any netwroked resource is insecure by design.

-

Re:Human Error

[Vincent Bernat]

Why a password-protected RSA key would be worse than the actual situation ? The private key is encrypted by some password, it is more secure than encryption scheme used in password and shadow and the private key (encrypted) is set to be only readable by the user owning it, so what's the point ?

Re: Human Error

[Black Parrot]

> Random passphrase? Repeat after me: The best password is the one that isn't stikie'd to the monitor and/or keyboard.

When it comes to internet-based attacks, my yellow stickies are the securest files on my system!

Re:Human Error

[Anonymous Coward]

In practice, a single local privelage escalation attack is all it takes. Maybe this will end up being a good thing in the end, we get to find a previously unknown local root exploit, fix it and improve the Debian security practices, all in one move.

So when an exploit is found in Windows, it is considered a bad thing that shows how lame of an OS it is.. but when it is found (or not?) in Linux it is a good thing?

Ooooook. I know I know, I must be new here.

Re:Human Error

[Anonymous Coward]

Even funnier is when the lunix gayrus talk about the vast number of Windows holes that spring up all the time, while I've seen like 7 lunix security hole warnings in my inbox in the last couple weeks alone.

Go lienux! Shadow your passwd! Damn the luser and jump off a cliff! All together now (all together now!)

Re: Human Error

[Copid]

My God! That's the combination to the lock on my luggage...

Re:Human Error

[blanks]

It wasn't a weak password, it was from a sniffed password. But then again no matter how good your password is, if your not encrypted (and in some cases even if) your password is weak.

Re:Human Error

[pkaral]

Where information security work really breaks down is when password theory meets the average user. Personally, I had to try approx. 15 times to come up with a password that would be accepted by the system at my university, and by then it was so complex that I had to write it down to remember it. (As usual, there had to be 3 types of characters, but in addition, there where heaps of rules saying such things as "caps at the start or end of the word don't count".

We must find a systemic solution that includes the users as part of the system. The main requirement for a new password regime is therefore that it must work within the bounds of users' bad habits and limited capacity for recalling a gazillion passwords which change regularly.

Re:Human Error

[God! Awful 2]

(For example, the private key might be encrypted by a biometric signature or keycard or similar.

I have yet to see a biometric signature that would solve this problem. Generally speaking, in biometric identification, information about the fingerprint/retina is stored on the disk and then compared against the data that is read in. The biometric information is not used *AS* the encryption key. So a biometric signature is just like a really big password, except that if someone cracks your password you can change it, but you can't (easily) change your fingerprints.

-a

Re:Human Error

[BJH]

Dunno, but I might cut off your head if I had a headache.

Re:Human Error

[dasunt]

Er, the problem with biometric identification is that (1) its not testing who you are, just that the digital input matches some value and (2) you can't change what its testing.

You can't change who you are. Thus, once the key is compromised, it stays compromised.

Re:Human Error

[wirde]

In other words, you've achieved nothing. The issue here is the protocols, NOT passwords. Since these are not unnder the control of users, we should assume that any netwroked resource is insecure by design.
The protocols are not insecure by design... The issue is primarily key management.

Re:Human Error

[Yottabyte84]

For some bizzare reason, I'm able to memorize longish random strings (8 to 12 characters usualy) after a few uses. I've got about 10 such passwords memorized.

Re:Human Error

[Anonymous Coward]

So when an exploit is found in Windows, it is considered a bad thing that shows how lame of an OS it is.. but when it is found (or not?) in Linux it is a good thing?

Yes. In the past, Windows exploits get found one of two ways. The first way is when a virus is found in the wild. The virus is deconstructed, then Microsoft does a cost analysis to determine if it's worth patching the vulnerability that enables the virus. If so, then a binary only patch will be issued. The first you'll hear of it is when you're able to download the patch. The second way is when a white hat hacker or security analysis team at some college find an exploit. If they go public with it, they're criticised for not giving time for Microsoft to develop a patch. If they go to Microsoft with it first, then the cost analysis process starts, only because the public at large doesn't know a problem exists, there's a much smaller chance a patch will be issued. In either case, the patch may or may not work, and it may or may not break your system. Caveat emptor.

When an exploit is found in Linux, it gets fixed. The cause of the exploit gets scrutinized world over, and other developers privately consider whether their software might have the capacity to be exploited in the same way.

Re:Human Error

[Ckwop]

A Smart card and password system would be much better..

Combine something you know, with something you have.. It given us (okay) security with cash machines for a long time and the bank cards are considerably cheaper :)

I think Bruce Schneier's got it right. We *need* break-in insurance for computer systems. If your premium is lower if you use smartcards, for example, then it gives a market force to improve security. Insurance would definately move the industry along.

Simon.

Re:Human Error

[Anonymous Coward]

Man, shoving SDRAM into you brain is BAD FOR YOU! ;-)

Re:Human Error

[hdw]

It is sad to see one weak password responsible for such a breach.

Eh? Why is everyone talking about a weak password?
The article says sniffed password.

I assume that they're not using cleartext password authentication which means that it wasn't sniffed on the wire, it's was sniffed on a (compromised) box the some user used to log in.
And if the clientbox is compromised it doesn't matter if you use password or a passphrased key.
Even keeping your key on something removable (like an USB keychain) doesn't help you, the cracker can easily snarf both key and passphrase :(

The only way to bypass that would be an external pinpad style device.

//hdw

Re:Human Error

[cpghost]

but RSA keys isn't the way to go. They're impossible to remember, which means you need to store them on a computer.

They can also be stored on a smart card, memory stick, etc... Once all keyboards come with integrated card readers, the situation will improve a lot.

Re: Human Error

[cperciva]

When it comes to internet-based attacks, my yellow stickies are the securest files on my system!

Well, you'd want to make sure they weren't stuck somewhere visible to random passers-by.

But you always have to keep in mind that any form of security is only as strong as its user interface; if someone can access a password stickied to the bottom of your keyboard, they can probably attach a keylogger as well.

Re:Human Error

[Xerithane]

A good method: Easy mental ciphers.

You pick a passphrase that you use for all of your systems. You then pick a unique seed for each system. Then, you do some quick mental math on it (pick an algo of your choice, just make it simple) and then you have the effective security of two passwords + unknown algorithm. It will make all of your passwords invulnerable to dictionary attacks (unless a rare circumstance has your resulting password being "password" or something)

For example, if you have a pass phrase of "MYBOXISSECURE" then you can use the box name as a seed, lets call the box "DEBIAN" and have the algorithm block the seed and then subtract, modulo 26.

MYBOXISSECURE
DEBIANDEBIAND
-------------
I'm too tired to do this and I'm on my windows sytem without perl.

Then reverse it or something. Walla! Pseudo-random passwords. Works great, and after a few times you will memorize the keystrokes and you won't need to do it by hand. You can even have a standard system for the passphrases amongst an entire group for the root password, so each system can have a different root password that everybody can just figure out as long as they know the passphrase. In addition, if you want to remove someone from the loop, just change the passphrases and redistribute to the trusted source.

It's a hack solution for the weak-password problem.

Re:Human Error

[Anonymous Coward]

So a biometric signature is just like a really big password

It isn't really. The entropy in a fingerprint is about as good as a 4-digit passcode. It's just more difficult to give away or leave lying around on a Post-It.

OTOH, you can't steal my ATM PIN code with a gummi bear...

Re:Human Error

[Anonymous Coward]

Memorize passwords in "vector" format. E.g., a simple visual pattern on the keyboard that produces insanely complex passwords.

Re:Human Error

[Prowl]

similarly i use an md5 of my master password, and the web site/hostname etc.

bit stuck without an md5 generator though...

Re:Human Error

[Anonymous Coward]

So there is an exploit in the wild that you weenies can't patch. D'aww...

Has this one been fixed yet ?

And since when does a 15 y/o shit know the ins and outs of microsoft security procedure?

fuckhead.

Re:Human Error

[MaGGuN]

Besides, if you loose both your hands, what then ?

Re:Human Error

[BoysDontCry]

"On Wednesday 19th November (2003), at approximately 5pm GMT, a sniffed password was used to access an (unprivileged) account on klecker.debian.org." That doesn't say anything about a weak password. Where did you get the idea that it was a weak password? Just because a password was sniffed, doesn't mean that it was a weak password.

Re:Human Error

[clickety6]

Why not have a changig password. The machine is set up with a set fo say 10 questions to which the suer knows the answers- what is your Mum's maiden name, your first dog's name, etc, the usual stuff. And he has to enter the correct answer corresponding to the passowrd question being asked. Ok - it's not all that more secure, but it does give another step of complexity without making it to inconvenient for the user...

Re:Human Error

[TheAncientHacker]

So when an exploit is found in Windows, it is considered a bad thing that shows how lame of an OS it is.. but when it is found (or not?) in Linux it is a good thing?

Nah, what you see here on /. is:

So when an exploit is found in Windows, it is considered a bad thing that shows how lame of an OS it is.. but when it is found (or not?) in Linux it must be user error!

Notice how many people are discussing how the bozo got a user account password but very, very few are discussing an unknown privilege escalation to root since a bug like that would dispute the religious mantra of "open source is inherently secure and any security bugs that do exist get fixed immediately".

Re:Human Error

[Anonymous Coward]

"This incident reminds us of the importance of password security."

The password was sniffed from the network, which should be a warning to people who think that sourceforge is paranoid for not allowing you to login without SSH.

Or anybody who checks their email by POP. I'd best hassle my webhosts again to upgrade that.

Re: Human Error

[Anonymous Coward]

Unless you're running a webcam. :)

Re:Human Error

[gnu-generation-one]

"Eh? Why is everyone talking about a weak password? The article says sniffed password."

Why talk about passwords at all? The article says there's a local root compromise in GNU, and that nobody knows what it is. It mentions that it's serious enough for them to leave debian servers switched off, for fear that the compromise could be used again.

If their suspicions are correct, then it's very worrying for anyone who runs a multi-user gnu/linux system; ISPs, development boxes, commercial servers. And yes, it would be as serious as one of the Windows bugs.

It's probably not about patch levels either. Although some of the debian boxes were said to have older versions of some software, unless a root compromise can be found in those software, then we have to assume that a fully up-to-date and professionally-secured system is vulnerable. So whatever it is needs to be found.

Again, this is all an interpretation of an article, which in turn is someone's interpretation of the forensics, which itself can be fuzzy. But it sounds like there's stuff needs to be audited, and quickly.

Re:Human Error

[vericgar]

Except you are wrong.

It is "open source is inherently secure and any security bugs that do exist get fixed immediately ONCE FOUND".

With closed-source systems, the company does a cost-analysis on whether it's cheaper to fix and distribute a binary patch vs. any cost to them leaving the hole in.

Re:Human Error

[Cthefuture]

Use a smartcard. Then you can keep your RSA (or whatever; like a really long shared key/password) keys on it.

All you have to remember is a short PIN or passphrase to unlock the keys or other data on the card.

If someone steals your card you don't have to worry too much about them using a brute force attack on your card because the PIN will automatically lock after a certain number of attempts (usually 3 tries and the card is toast).

Re:Human Error

[swillden]

The biometric information is not used *AS* the encryption key.

And there's a good reason for that: It wouldn't work. Every time a biometric is scanned, the result is different. Biometric matching is hard because it's a process of evaluating the "closeness" of the livescan to the stored template and then deciding whether the two are close enough to be considered the same.

This means that trying to extract a set of bits from the scan which you could be sure would be the same every time is very difficult, and likely wouldn't net you many bits to use as a key. A set of bits that changes a little every time doesn't make a useful key.

Given some sort of a secure processor, you can store the key and the biometric template in there, and program it to refuse to use the key until it has been presented with a biometric scan which it considers to be close enough to the template. That gets you about half way to security, now you just need to find a way for the secure processor to verify that the livescan it receives is fresh, and not replayed. Oh, and it would be good if you could also be sure the livescan is a *live* scan. And don't forget to secure that template database well.

Making biometrics secure is hard. In practice, this means biometrics are only useful in two situations. The first is very low security, where the biometric is being used to raise the level of security from very, very low to very low. The second is very high security, where the biometric is to augment some other authentication methods, or when verification is only done in a very controlled environment, i.e. where you're watched closely by a human guard who knows how to ensure you're not trying to fool the scanner.

Re:Human Error

[Yggdrasil42]

You're saying having a RSA key locked with a password is not better security than having only a password? Not quite true. There's a rule in the authentication business that there are three parts to a good authentication system. Those are:

• What you are (for example biometrics, a fingerprint)
• What you have (a regular key or a crypto key on a usbstick)
• What you know (a passphrase that you've memorized)

It's considered good policy to have at least two of those covered. In your example, needing to provide both an RSA key and a password to unlock the key is definitely better then only needing to show a password. Of course storing the RSA key on the system would negate that advantage, in which case the usbstick I mentioned comes in handy. Create a physical barrier.

but then you're in the same situation as before

If 'they' get your key then yes. But getting that key is an extra hurdle, worth building. More info? Search Google for "two factor authentication"

Re:Human Error

[Jellybob]

How about combining the user's password with an RSA key saved on a USB memory stick?

Since computers bought today will almost always have a USB port on the front, user's can be required to put a memory stick provided to them by their employer (for example... you just need to know where the key is saved), and then enter their password for that as well.

Re:Human Error

[TheAncientHacker]

I'm guessing the person who broke in found it quite a while ago.

Or did you mean they're fixed when they're found by the right person who happens to have the desire to debate it and convince whoever owns that piece that it's really broken, debate the patch, discuss when to release it, see if anybody's willing to include it, publicize the fix, get it included in enough releases that the unfixed version isn't being distributed for the next two years, get people to actually rebuild or reinstall that piece, etc...

Re:Human Error

[Anonymous Coward]

Oh wow "jkrise", you really went for break on this one, didn't you? How many posts just to this little jewel of an article? It really got to you, didn't it? Bwahahahaha. Pathetic little Linux fanboy.

Re:Human Error

[John Hasler]

> It is sad to see one weak password responsible for
> such a breach.

There is no evidence that the password was weak. James seems to think that it was sniffed.

Re:Human Error

[frehe]

Even if you find the passphrase for my private RSA-key, you still need to get the file the key is stored in. This may not be so simple if I don't store it in publicly available places. For example, the private RSA-key for my account on my home network is only stored on my laptop, my workstation at work (own business) and two accounts at my university. This helps security a lot compared to just using a password, since you need to break the security at one of these places in order to get the private RSA-key, in addition to getting my passphrase for it.

You can store your private RSA-key on a removable storage media like an USB-dongle. When this is combined with prudent use of the USB-dongle (don't have it plugged in when it doesn't need to be plugged in), the time window for keygrabbing attacks is less than when storing the private RSA-key on a regular harddrive.

How many times have you used SSH to access host A and entered the password for host B? I have done it several times in stressed situations. The use of RSA-keys prevents the administrator on host A from getting your password for host B.

Re:Human Error

[Ben Hutchings]

Not if they looked over your shoulder, or pointed a camera at the keypad. Hidden cameras can be very small these days and this attack is commonly used to get the PINs for ATM cards (usually combined with the "Lebanese loop" to read a magstripe rather than physical theft of the card).

Re:Human Error

[DoraLives]

if you loose both your hands, what then ?

Can't type anyway. Fuckit.

Re:Human Error

[Stinking Pig]

Um... what are you talking about? According to the posting, the password was sniffed -- whether from the wire or the keyboard is unclear. If it's been sniffed from the wire, password length and strength are irrelevant. RSA keys with a timestamp element would help in that case, but if the passphrase were sniffed from the keyboard, its strength is again irrelevant.

Re:Human Error

[orcrist]

For some bizzare reason, I haven't found it necessary to be able to do that. All you need to do is learn how to make hard-to-guess, easy-to-remember passwords:
Choose a quote or sentence, take the first (or second if you really want it to be hard) letter of each word, use numbers instead of letters for words like 'to', and alternate capitalization for the rest:

"To be or not to be, that is the question" becomes
"2bOn2BtItQ" which should defeat any dictionary based attacks, and is incredibly easy to remember. Of course I also choose somewhat more obscure quotes or make up an interesting sentence.

-Chris

Re:Human Error

[Cthefuture]

Meh, nothing is perfect. There's no point in arguing that. There's always a way to get into a system.

I can't remember the last time somebody on the Internet teleported beside me to look over my shoulder.

Instead you need to worry about what level of expense and trouble you want to go through for your particular needs. A smartcard is fairly simple, cheap, and provides decent security. If you go with one of the newer USB cards then you don't even need a reader, the card plugs right into your USB port. It's perfect for storing SSH keys and using that for authentication.

Re:Human Error

[pileated]

Half way through my Level 4 threshold filtering of this thread and I think this is the first serious response to the thread.

Humor's fine but you do have to wonder when over 90% of the highly rated responses in a thread are comic or flip.

Thanks for some serious responses to the topic.

Maybe it's time for me to stop reading as I find I spend more time commenting on the comments than anything else!!

Re:Human Error

[Anonymous Coward]

> loose both your hands

Could you please explain how your hands would not be tight? Is that slang for being gay or something like that? I've heard the term "loose wrists" to describe a gay guy, but never "loose hands." Also, what does that have to do with biometrics?

Re:Human Error

[RisingSon]

I spend much of my time writing software to do just this.

Re: Human Error

[Anonymous Coward]

They are a security hazzard even on internet... depends what you are doing with your web cam while chatting ;)

Re:Human Error

[Anonymous Coward]

If by bizarre, you mean perfectly normal, then yes, that's pretty bizarre.

Re:Human Error

[Jungle guy]

I am not a Sun suporter, but apparently Solaris 10 should have this kind of implementation, according to this article. It will have "military grade" security as default, and the root user will be eliminated in favor of "specific roles" (I don't know what this means, the article is very thin). Something to keep an eye on.

Re:Human Error

[mvpll]

We are talking about remote exploits here right?

How do I pass my smartcard through my modem to the internet???

Re:Human Error

[God! Awful 2]

Yeah, that's pretty much what I was saying.

-a

Re:Human Error

[swillden]

Yes it was. I just thought I'd say it a little more thoroughly and try to explain some of the reasoning behind it.

Re:Human Error

[Luyseyal]

Don't forget punctuation: 2B|!2bTit?
-l

Re:Human Error

[alien_blueprint]

A good method: Easy mental ciphers

"Your philosophy intrigues me, and I wish to subscribe to your newsletter!" - H. J. Simpson.

However, I don't think it stands up. In the spirit of "more eyes makes it better", here's the problems I can see. I assume that someone is actually making an effort, first. That is, someone is specifically targeting you or your organization.

You pick a passphrase that you use for all of your systems. You then pick a unique seed for each system. Then, you do some quick mental math on it (pick an algo of your choice, just make it simple) and then you have the effective security of two passwords + unknown algorithm.

The problem is, an unknown algorithm isn't considered particularly effective. What if an employee leaves, or lets it slip somehow? What if the algorithm can be determined from analysis of sufficient samples? Given the (by definition) simple nature of the cipher, this appears to be a significant risk.

It will make all of your passwords invulnerable to dictionary attacks (unless a rare circumstance has your resulting password being "password" or something)

Given that all but the most casual of attackers will likely know the machine name and the algorithm, this might well make you *more* susceptible to dictionary attacks. It's a psychological problem - the user thinks "this password is encrypted, therefore I can just make it an English word", whereas under normal circumstances they wouldn't have done that.

For example, if you have a pass phrase of "MYBOXISSECURE" then you can use the box name as a seed, lets call the box "DEBIAN" and have the algorithm block the seed and then subtract, modulo 26

This is the biggest danger that I can see: the use of the machine name as the key. If by that you mean "DNS name" or part thereof, this appears to be pretty dangerous. Chances are an attacker would know that, right? Or that it's some easily guessed word itself. So now the attacker just runs every permutation of dictionary words, in addition to popular passwords and machine names through your algorithm.

It would probably be safer to pick something *not* available through the network. My employer has a serial number they attach to the side of the machine for tracking purposes. Using that would eliminate everyone without physical access to the machine for enough time to copy down this number.

It's a hack solution for the weak-password problem

Yes, I think it is ;) I suspect it will defeat only the casual attacker. It might also lead, as I mentioned, to weaker security through a *false* sense of security. I've seen this recently - people thinking that converting an application-level password to base-64 when stored in the database and transmitted over the network was "better than nothing". I had to explain how this was completely ridiculous very, very patiently. And how it makes the problem worse, as other people now assume it's perfectly safe for anyone to see that base-64 password when implementing anything that involves the password.

This idea has got me thinking though ... what if everyone in the organization had access to enough mobile computing power to do a better job on this (I'm thinking PDA here, but it could be a specialized device). You don't put the password in the device (as that make the device the vulnerable point), but instead it implements an algorithm that's strong enough that it doesn't matter if the attackers know what the algorithm is. That just leaves the password and the key, which still must be selected according to the rules of what makes a "good password". So DNS names are still right out, I think. I'm going to tentatively suggest that the key be derived from an skey-like system that runs on both the PDA and the machine. This way neither the human nor the PDA are useful on their own.

Unfortunately, if someone gets the PDA only the password is keeping them out, and that had better not be somethin

Re:Human Error

[Xerithane]

Yes, I think it is ;) I suspect it will defeat only the casual attacker. It might also lead, as I mentioned, to weaker security through a *false* sense of security.

One thing you are missing is the ease of changing the passphrases. Also, if the algo was hash(passphrase + hash(password)) knowing the password (dns hostname) wouldn't reveal anything unless you knew the passphrase as well. You could try to bruteforce passphrases, but considering how long those could be, you would most likely not succeed. However, hashing something like that doesn't actually "work" for mental-math.

As for the PDA/Cell stuff, they have them. Devices that maintain a private/public key generation sequence based on time (I'm not sure what algo they use) and display the random numbers for you on an LCD.

I think what you missed in my initial design that it does result in stronger passwords because you can share passwords amongst multiple people and if one of those people is no longer trusted a simple passphrase change will lock them out. If you do the algo right, having the seed won't be particularly effective. It still is a crib, but it's hard to have people who used to work for you not have one. I was just using that as an example though, I doubt I would actually do that in practice.

It took me a few seconds to decode this. I think you mean "voila!" :)

What started out as a joke, turned into a nasty habit. I didn't even catch that I did that...

Re:Human Error

[alien_blueprint]

One thing you are missing is the ease of changing the passphrases

I have to admit, I don't quite see that. Just having one password shared by all, and changing it when someone leaves is just as effective, isn't it? Given that they know the algorithm and all the keys (in this case, the machine names) this is in effect exactly what the method we're discussing reduces to, I think.

You could try to bruteforce passphrases, but considering how long those could be, you would most likely not succeed

The point I'm dancing around is that once the algorithm is known you're back to relying on the "unguessability" of the individual password and key.

I think this definitely would increase the difficulty of a dictionary attack for an individual who doesn't tell anyone what she's doing, but I suspect that once you try to make everyone in the organization do the same thing, you've got to expect that the algorithm and the key selection details will be leaked, and so you can't let the password be an easily guessed one. Which is right back to where we started - you need hard to guess passwords.

Sure, by adding another element (the key) you've increased the number of combinations that must be attempted, but if people are now selecting easy to guess passwords and keys, you might well be in a worse position.

As for the PDA/Cell stuff, they have them. Devices that maintain a private/public key generation sequence based on time (I'm not sure what algo they use) and display the random numbers for you on an LCD

Time? I hadn't thought of that. However, once the device is lost, you had better hope that the user selected a hard to guess password :) I'll have to have a look at these devices, though.

I think what you missed in my initial design that it does result in stronger passwords because you can share passwords amongst multiple people and if one of those people is no longer trusted a simple passphrase change will lock them out

Okay, I am definitely missing something here. Here's my reasoning: I can already set a common password to the same (hard to guess) string and just change it when someone leaves. If the person who left knows the algorithm and the key selection method (eg. machine names) I think this is effectively what you are doing anyhow.

Perhaps if you were to change change the algorithm as well when someone left ...

I was just using that as an example though, I doubt I would actually do that in practice

It's an interesting idea. Then tension between "easy to remember" and "hard to guess" is what makes passwords such a weak point. If people could generate hard to guess passwords from easy to remember ones, it would be a useful process to get people to perform when faced with the eternal "select a new password" problem.

Re:Human Error

[Xerithane]

Just having one password shared by all, and changing it when someone leaves is just as effective, isn't it? Given that they know the algorithm and all the keys (in this case, the machine names) this is in effect exactly what the method we're discussing reduces to, I think.

This system ensures that one password is unique amongst machines. Instead of having one password for many machines, you have one generator which generates one password unique to each machine.

Time? I hadn't thought of that. However, once the device is lost, you had better hope that the user selected a hard to guess password :) I'll have to have a look at these devices, though.

Enigma and Shark (ww2) both used time-generated seeds. Just feeding a pseudorandom number generator with time can be enough for password security.

If the person who left knows the algorithm and the key selection method (eg. machine names) I think this is effectively what you are doing anyhow.

The key would be a pass phrase, the seed (salt) would be machine name. Think of unix passwords, the first two bytes are the salt. The rest is crypt() of the password using the salt. You can't guess the original password. Same type of thing, except you use the machine name as salt. Read the man page for crypt() for more info on it.

If people could generate hard to guess passwords from easy to remember ones, it would be a useful process to get people to perform when faced with the eternal "select a new password" problem.

It really is all about keeping the passphrase secret. Muscle response could allow repitition after just a few times. Write it down on a post-it note, login and logout till you can do it via memory, then burn the post-it note. People selecting easy passwords should be shot. Er, I guess I got to go give myself a good talking to.

Re:Human Error

[alien_blueprint]

This system ensures that one password is unique amongst machines. Instead of having one password for many machines, you have one generator which generates one password unique to each machine

I think I understand now. This would at least protect you against password sniffing by a attacker with no "inside" information. They would only get the password for that one machine.

Enigma and Shark (ww2) both used time-generated seeds. Just feeding a pseudorandom number generator with time can be enough for password security

I'm not familiar with Enigma (apart from having heard of it). My expertise in such things extends to having implemented SSL on top of a colleague's C library of cryptographic primitives. I am reading "Handbook of Applied Cryptography" (Menezes, van Oorschot, Vanstone) ... I'm just not up to the section on classical cyphers. I read almost all of "Applied Cryptography" by Schneier of couple of years ago, but found it fairly shallow, especially the coverage of RSA.

But yes, time is a useful seed - yet you can't store the resulting seed in the device if you're worried about losing the device itself.

It really is all about keeping the passphrase secret

Yes, I think that's the case. At least when dealing with attackers that may know the algorithm and the seed/key/machine name - as the passphrase is now the weak point again and it just can't be guessable.

Muscle response could allow repitition after just a few times. Write it down on a post-it note, login and logout till you can do it via memory, then burn the post-it note. People selecting easy passwords should be shot. Er, I guess I got to go give myself a good talking to

Yes, this is my prefered methodology too. A purely random password that uses uppercase, lowercase and digits to keep the search space large. And not written down anywhere.

However, my current emplyer has the policy of forcing password changes every month for almost every machine or server I have to access. If I did it properly, I would be going through this twice a week. Yet another case where "harsher" security rules can actually lessen security ... I would bet that most people where I work just have English words concatenated in order to cope with this - or just write them down. If the password lasted longer we could encourage them to select good ones as the effort would be worth it. I just use a numerical suffix with my "good" password, but I'm always forgetting where I'm up to in the sequence.

I think I'll write something for my Palm that accepts my "good" password that I've memorized, and combines it with the date of the last forced change for a given machine or server, and runs both through a hash algorithm to produce the "real" password. And it'll be a good excuse to finally use Python on the Palm for something :)

Re:Human Error

[TiggsPanther]

It's not even just the "average user" that has problems with passwords.

I'm a techie. I fully understand the need for secure, regularly-changed, unique-per-account passwords.
I also have a hideously short memory retention span. If a password is sufficiently hard to crack, I'll forget it next login.

Of course, these days I do log out/in a couple times when I've changed a password, so I can commit it to memory that way. But I used to get caught out quite a few times, changing a password and forgetting it later the same day.

I guess the real problem is that there's no easy way to secure a system.

• Passwords:
  Easy to change. Easy to crack. People with short memory spans (Whether Joe Average or Jim Geek) will either forget them, make them too simple, or write them down.
• Enforced regularly-changed complex passwords:
  Theoretically a damn site more secure. In practice, the number of "I've forgotten my new password" calls will increase. People with problems remember passwords are more likely to write them down.
• Biometrics:
  A lot harder to crack/duplicate. But, as many others have already pointed out, you can't change them. One compromised, it stayscompromised.
  Also, these are more useful for physical-location security, but perhaps not so useful for remote security.

I guess what it all boils down to is that there's no such thing as 100% security.[*] As soon as you let anyone in, there's the chance that someone else will be able to do so unauthorised.
If anything, this Debian episode has served as a good reminder about this. Also showing that even if you can't prevent such exploits, closely monitoring your servers can at least allow you to notice when something has been compromised.

[*]Not a reason for complaceny. Just because you can never acheive eliminate vulnerabilities entirely doesn't mean you can't/shouldn't do as much as you can to reduce the likelihood of them occurring.

Tiggs

This isn't surprising..

[Anonymous Coward]

This kind of exploitation isn't rare at all. It's what the folks at the Debian project get for not running Windows. If they'd been using Microsoft Windows, they'd be much more secure and something like this couldn't possibly happen.

KIRK!!! GOD DAMN, I SAID KIRK!

[Anonymous Coward]

Captain's Log: My Anus is too Fucking Tight

One day Captain Kirk was maiming his cock with a horseshoe when suddenly Mr. Spock ran up to him and shoved his pointy ear up his butt. "What is this for!" the fag captain said. "FAGS FOR YOU AALL!L!!!" the ancient alien howled as suddenly he farted and Captain Kirk twirled around in a daze and his foreskin twisted and his kidney stones turned into wooden beads. He pulled out his pistol and shot lasers at his chastity belt and suddenly he hurdled his dick into Captain Kirk"s bellybutton and it tore his flesh while Spock fucked his stomach. Kirk hollered out loud and Mr. Spock threw his shoes to the floor and wrinkled his penis until Kirk bellowed out to make it stop. A maelstom of shit whizzed around the ship and suddenly a giant fag appeared out side and the U.S.S. Enterprise went up his butt. "Oh what the hell have you gotten us into NOW!" Captain Kirk said as he oozed a condom back on his dick and put his panties back on. "OOH!H!!!!!!" Mr. Spock started fucking him again and shoved his phazer up his butt. He dissolved his glands and exploded his turds and finally a queer klingon hurdled through the door and smashed Kirk with his butt hairs. A maniac sucked his dick and suddenly Mr. Spock fagged Kirk so hard that his intestines burst open and he died.

*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*
g_______________________________________________g
o_/_____\_____________\____________/____\_______o
a|_______|_____________\__________|______|______a
t|_______`._____________|_________|_______:_____t
s`________|_____________|________\|_______|_____s
e_\_______|_/_______/__\\\___--___\\_______:____e
x__\______\/____--~~__________~--__|_\_____|____x
*___\______\_-~____________________~-_\____|____*
g____\______\_________.--------.______\|___|____g
o______\_____\______//_________(_(__>_\___|_____o
a_______\___.__C____)_________(_(____>_|__/_____a
t_______/\_|___C_____)/______\_(_____>_|_/______t
s______/_/\|___C_____)_KIRK!_|_(___>_/__\_______s
e_____|___(____C_____)\______/__//__/_/_____\___e
x_____|____\__|_____\\_________//_(__/_______|__x
*____|_\____\____)___`----___--'_____________|__*
g____|__\______________\_______/____________/_|_g
o___|______________/____|_____|__\____________|_o
a___|_____________|____/_______\__\___________|_a
t___|__________/_/____|_________|__\___________|t
s___|_________/_/______\__/\___/____|__________|s
e__|_________/_/________|____|_______|_________|e
x__|__________|_________|____|_______|_________|x
*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*


I hate you, I hate your niggers, and I hate your niggers.

KIRK REIGNS SUPREME!

Brought to you by: KIRK TROLL

Fuck GNAA, TROLLKORE, AND CLIT. You all massivly fail it, you gay homofags.

Michael, The Viagra Bitch

[Anonymous Coward]

Hello. My name is Michael. You might know me as the censor at a Geek news site where we pretend to offer news that matters. Or perhaps you remember me as the guy who hijacked an anti-censorship website. Whatever.

Now is your chance to really know me. I'm going to let you in on my personal life, and the secret of how Timothy, Rob, Jeff, and I all "came" together.

I remember that autumn day so well. It was in our dorm room at Hope College, in Holland, Michigan. Timothy stood there by the bathroom sink, totally naked and shaving his face. He didn't recoil when I went into the bathroom which we also shared with Rob and Jeff--the guys next door.

Timothy and I had been roommates for almost three months now and gotten used to seeing each other strip down, dress, and even "hard".

"Hey, Michael" he said.

I had gotten the chance to look Timothy over a few times. But for some reason that evening I just stood there looking at his scraggly unkempt hair, his bare back, his flabby back muscles flowing down into the lumpy mounds of cellulite which composed his saggy buttocks and thick thighs.

Despite his flab, the sexy swastika tattoo on Timothy's right butt cheek gave him an air of hunky manliness.

"Oh I'm sorry, Timothy" I said without him saying anything despite the fact I had been standing there looking at him.

"I was just ..." he turned and smiled through the shaving cream. "it's OK ... I look at you too, Michael" he said.

I didn't know what to say then. I just moved next to him at the sink and stripped off my shirt to wash.

"Got a hot night tonight, Michael?" he asked.

"Naw just thought I'd go for a swim and pizza later. How 'bout you, Timothy?"

"You keep swimming, Michael, and that hot ass of yours will be the talk of the dorm" he said as he patted my butt. He left his hand there and stroked one ass-cheek a bit.

"You keep doing that and you won't be going anywhere, Timothy" I said half joking. My cock had already began to turn my boxer shorts into a small tent.

He didn't move his hand at all. In fact his fingers moved under the boxers and he stroked bare skin.

Timothy said, "Shit, Michael, I'm getting you hard".

"Yea you get it too hard and you'll have to find a way to get it down again" I said spreading the shaving cream on my face.

His fingers moved between my ass-cheeks and stroked. It felt good ... and then he suddenly stopped.

"Can't now ... maybe when I get back. Will you still be up then, Mikey?"

His hand had moved to my tented crotch and he gently felt my boner when he asked.

"Not if you keep doing that, Timothy"

We joked around like that often of course. But that evening his attention was more then the usual goosing or ass grabbing.

I swam hard laps so my effort and the water would make my cock shrink. But my head was full of the memories of his petting as well as his naked body.

I knew that after my pizza and maybe a beer, I'd be in my bed jacking off as many times as I could before he got back to the room.

I was mid-way through my second go round when the door opened. He looked at me and smiled.

"I hoped you'd be waiting, Michael" he said as he stripped off his shirt and jeans. We didn't speak. Timothy moved to my bed and pulled my covers off.

Timothy pushed my hands over my head and to the bed pipe. I held them as he lifted my legs and curled my body over so his fingers, lips and tongue could take total control of my body.

I closed my eyes and swooned as the sensations I had only fantasized about made me shiver and shake. Timothy's fingers stroked the lips of my ass then moved inside to find my prostate and stroked that bringing me to the point of orgasm. The sperm splattered on my face, chest, and stomach.

But he wasn't through and his cock moved into my ass before it could recover and close tight after the orgasm. It hurt and made me beg him to stop. "Shut up Michael. Y

barf

[Anonymous Coward]

T h e G l o b a l Ne t w o rkof Ar a b Ac t i vi s t s ( G N A A ) isa d e m o c r a t i c f o r u m f o r a l l a c t i v i s t s wh o s t r i v e t o pro m o t e A r a bc u l t u r e and a dva n c e t he c i v i l a n d huma n r i g ht s o f a l l Ar a b p e o ple s . U n l es s i ndic a t e d o t h e r w i se , a ll s t a t e m e n t s p u b l i s h e d o n t hi s f o r u m re p r e s e n t t h e v i e w s o f t h e i r a u th o r s a n d n o t n e c e s s a r i l y tho s eo f G N A A.S u b s c r i ptio n a n dre l a t e d i

In a nutshell - somehow

[evil_roy]

Quote from the article:

"Somehow they got root on klecker and installed
suckit."

What follows is an interesting read - but the guts are in that 'somehow'.

Re:In a nutshell - somehow

[Kulic]

You're absolutely right. For some reason, everyone else seems to be overlooking the fact that there is (or appears to be) an unknown root exploit out there.

Yes, you can probably guess/crack/social engineer a password if you try hard enough. That's why security is about layers, compartmentalisation and multiple types of protection, not just a single password.

If this was your box, would you be more worried that someone had managed to sniff an (unprivileged) password? Or that any one of your users can now root your box? I know which one I would lose sleep over.

Here's to hoping that the root exploit is found and patched nice and quick. Even better if it something else that's been missed and is fixed in the latest patch.

Re:In a nutshell - somehow

[Anonymous Coward]

In a nutshell? Seems pretty short for an O'Reilly book. What animal is going to be on the cover?

Re:In a nutshell - somehow

[Anonymous Coward]

A penguin with its head blown off.

Re:In a nutshell - somehow

[placeclicker]

I was under the impression that there are always undisclosed root exploits for every major OS used, you just don't know about them.

I mean, this is a big crack, i don't expect it to be a well publicized exploit.

Re:In a nutshell - somehow

[jkrise]

If you lose sleep over these so-callled 'Security Vulns' you can never sleep at all - unless you're running a box that's not hooked onto the net. Do you know how many 'root-attacks' are possible with Windows? 95,98,NT,2K,ME, XP - whichever version you're on? Can you even bet that after applying the latest fix from Microsoft, your system is free of vulns?

The best way to enjoy 8 hrs of sleep every night is to backup all files onto CDs / disks before going to the net. No matter what, you can get back live in about 30 mins next morning. With Windows, it could be 6 hours PLUS $600 for softtware.

Most of us choose the 30 mins option.

-

Re:In a nutshell - somehow

[Anonymous Coward]

For some reason, everyone else seems to be overlooking the fact that there is (or appears to be) an unknown root exploit out there.

Uhm, did you read James' post? Here's a quote:

Unfortunately due to the fact there is (I believe) an unknown local root exploit in the wild, we can't yet unlock the Debian accounts.

Surely this constitues something else than "overlooking" the root exploit? Deciding to keep the Debian accounts disables effectively stops the entire developement of Debian. Nobody has been able to upload packages in the last week, and lots of services are down.

James could have unlocked the accounts to make the developement pick up again rapidly (which would probably would be the only option in a corporate setting -- there's a release schedule that must be kept at all costs), but the admins are being thorough on this one.

In summary: James (and the other admins) are keeping the entire Debian Project in suspense for the purpose of tracking down this local root compromise and preventing it from being exploited again. You might want to think about that for a second, and see if "overlooking [the] unknown root exploit" is applicable here.

Re:In a nutshell - somehow

[mp83709]

cat ~root/.rhosts + hmm..how did that get there :-)

Re:In a nutshell - somehow

[mp83709]

oops - that'll teach me not to preview, meant to look like this:

cat ~root/.rhosts
+

Re:In a nutshell - somehow

[unixbob]

It's worth bearing in mind tho that this may not necessarily be a bug in the OS. The wrong permissions on a sudoer's file for example could have caused this. The assumption going around here is that there is an unknown root exploit going around which involves buffer over runs, kernel exploits, etc. It's just as likely that someone has made a mistake with their config and mistakenly left their server wide open

Re:In a nutshell - somehow

[Basje]

Your conclusions are absolutely right. In a corporate setting, this may be more of a hazard than it is now, because Debian can afford the downtime.

Yet you may have overlooked detail: development has not stopped. People keep working on updated packages, they just cannot submit them. If the problem can be solved, the productivity lost won't be that great.

This is actually one of the great benefits that open source offers, at least for succesful OS projects. It is not just a benefit of the excellent project management in this case.

Re:In a nutshell - somehow

[Anonymous Coward]

apples and oranges bloatman

Re:In a nutshell - somehow

[Anonymous Coward]

I wouldn't agree - actually this is a total disaster. Imagine there's a big security exploit of OpenSSL or some other package and Deb like others needed to release an update.

This is a confidence blow to many who hoped Debian could replace Red Hat in non-mission critical enterprise Linux servers.

Re:In a nutshell - somehow

[cjjjer]

I wouldn't be surprised if there were dozens of exploits out there for alot of OS's that most people in the security biz don't know about. This is the difference between and average hacker and an exceptional hacker. Most often have undisclosed exploits that they may have found and keep in their toolboxes. Exceptional hackers are not bound by ego and blabbing to friends about their endeavors and how they do it.

Re:In a nutshell - somehow

[swillden]

I wouldn't agree - actually this is a total disaster. Imagine there's a big security exploit of OpenSSL or some other package and Deb like others needed to release an update.

You're trolling, and the moderators have taken note, but I want to explain why this statement makes no sense.

If there were a big security patch that needed to be distributed, the Debian team would find a way to get the packages into the archive. The normal, streamlined package upload process is currently blocked, but that doesn't mean there is no way any of the administrators could get access to the FTP server to load a new package. The FTP server was not compromised, and is up and running.

Re:In a nutshell - somehow

[John Hasler]

> Deciding to keep the Debian accounts disables
> effectively stops the entire developement of
> Debian.

It does no such thing.

> Nobody has been able to upload packages in the
> last week, and lots of services are down.

It is not necessary to have an account on a Debian machine to upload packages. Packages are authenticated by the developer's GPG signature.

Re:In a nutshell - somehow

[SpaceLifeForm]

Another possibilty - Physical access to the machine.

Re:In a nutshell - somehow

[Anonymous Coward]

1) this does not stop development; it just disrupts the flow to the users.

2) locking your system(s) down while analysing after a compromise is the only sane thing to do

3) securing something against local exploits is non-trivial

4) he did, what he thought best; that is why there is probably more trust in people like him doing this job than in all m$ people together.

Re:In a nutshell - somehow

[ManxStef]

What I'm interested in is was it possible to do forensics before the box was switched off, and was there an IDS (such as Snort) installed and positioned in such a place as to be useful? If so then hopefully the attacker may have been logged by the IDS which may leave some vital clues as to the methodology the hacker used, and may even have logged the root exploit's raw packets.

For anyone that's curious I'd recommend a look at the Honeynet Project's Challenges page, esp. the Scan of the Month sample incident and submitted answers from the community - very good for learning how to perform an analysis.

Diebold, take note

[RealProgrammer]

All vendors and site administrators should take note of the openness with which the problem was dealt.

When I go to buy a car, a computer, or a stereo, and the saleslizard is cagey about any problems that come up, my trust level goes down. If they tell me all about all the problems with the thing they're selling before I even notice them, my trust level goes up. It's like a cool drink on a hot summer day.

Contrasting with Debian, how long did it take to find out that Diebold ATMs had been hit by the Nachi worm?

I'm now more inclined to trust Debian, and less inclined to trust Diebold.

Re:Diebold, take note

[Anonymous Coward]

So you'll get rooted by someone you trust..what's the difference?

Re:Diebold, take note

[Anonymous Coward]

I don't buy new cars that have problems. Perhaps you should stop shopping domestic (or worse, German).

Re:Diebold, take note

[Anonymous Coward]

All cars have problems. You choose the ones you can deal with.

Re:Diebold, take note

[Anonymous Coward]

I pity you.

Re:Diebold, take note

[jkrise]

More importantly, the openness of Debian is a much more important factor here. When I read these lines in the article:
The attack vector seemed to be a sniffed password of an unprivileged account, from which the attacker somehow managed to gain root and install the suckit rootkit and crack the other machines. As the machines were fairly uptodate with respect to security, an as-of-yet unknown local root exploit might be in the wild, so keep an eye on your boxen.
I got the distinct impression that Slashdot is transformig into a FUD channel for unsuspecting readers.

The fact that a 'clean' Linux system can be backed up and restored from any media, is of more relevance and importance to users. EVERY system connected to the internet has potential unknown vulns, those running Windows are often unpatched and have no disaster control system as well.

Viewed from this perspective, I don't think we need to keep an eye on our boxen just the backup tapes / disks/ CDs.

-

Re:Diebold, take note

[Anonymous Coward]

How plaintive.

Re:Diebold, take note

[oo_waratah]

"Viewed from this perspective, I don't think we need to keep an eye on our boxen just the backup tapes / disks/ CDs."

But how will you know unless you monitor it? Being able to recover a problem is a long way from identification.

Re:Diebold, take note

[agurkan]

yeah, but in this case, it looks like someone knows about a particular vulnerability. it is quite different from the situation of there might be a vulnerability but bad guys and good guys have equal chance to figure it out.
i don't think this qualifies as FUD.

Re:Diebold, take note

[holy zarquon's singi]

Root (noun): Australian vernacular for "to have sex". So yes, getting rooted by someone you trust /is/ important.

Re:Diebold, take note

[satanami69]

It was funny when Russell Crowe was singing "Take me out to the Ballgame" at the Cubs game. When he got to the "Root, root, root, for the home team" part, he and his friends all did pelvics thrusts.

Americans didn't know why until he told us on Leno.

I knew it.

[Anonymous Coward]

I know you weenies like to bash M$, but if you think for one moment UNIX or Linux is more secure then you're all dumber than a cage of monkeys in orbit, which I'm not sure but I think must be very dumb. NOTHING in the history of networked computing has been more insecure than UNIX.

Re:I knew it.

[Canadian_Daemon]

Do you have any info/statistics to back that up? or are you just another monkey? defending your pituful OS like a religion. Show us the facts that UNIX is insecure, and I'll show you the facts that show MS to be insecure

Re:I knew it.

[Anonymous Coward]

I meant "more insecure than WINDOWS." Sorry, typo.

Re:I knew it.

[Anonymous Coward]

UNIX is the most secure operating system created, followed by Linux then every other os then Windows.

I am quite biased about operating systems and i go on what the stats say and they are tell me that Windows is the most insecure OS, even though Mircosoft does all these so called "security checks"

Sexy James

[Anonymous Coward]

Why is it always young people find these vulnerabilities? Would this story even be on here if an old bearded professor had found it?

On the other hand, I'd do him. I'm definitely switching to Debian if hot dudes like him are working on it. That is, after I've moved to Sweden to be with the math chick.

Linux hacked? Nah it can't be!!!

[Anonymous Coward]

I thought Linux was perfect, unhackable. After all that's what we hear EVERY...FUCKING...DAY...here.

So either 1) the Zealots are wrong, or 2) the above article is a lie, a fantasy.

Re:Linux hacked? Nah it can't be!!!

[Anonymous Coward]

Nothing is unhackable.
There is always a way.

Its just that Linux and UNIX are a lot more secure than a certain common operating system.

This attack has obviosly shocked the comunity.

[GNUALMAFUERTE]

Since Debian (even for those smart ones out there using slackware, like i do) is really considered one of the real distros, if we hear that redhat has been atacked, we would just say that they diserve it and go on, it would be delivered in the respective mail list, and that was it.
But this attack has a psicological impact. Debian itself has been attacked, and it seems to be a bug exploited just in part, on the other side, there are updates that the compromised machines never got aplied, and other big mistakes like a non-tared backup lying arround, with the original owner / permissions mask. This is really more that enough to get any netadmin running Debian to get paranoid.

Re:This attack has obviosly shocked the comunity.

[Anonymous Coward]

even for those smart ones out there using slackware, like i do

omg u r a smarty man d00d ^__^
asl??

Re:This attack has obviosly shocked the comunity.

[phiwum]

Since Debian (even for those smart ones out there using slackware, like i do) is really considered one of the real distros, if we hear that redhat has been atacked, we would just say that they diserve it and go on, it would be delivered in the respective mail list, and that was it.

This brings up an important point. How do we know it wasn't Red Hat that rooted the Debian server? They have motive and they know Linux and its vulnerabilities and everyone says they're no good.

Where was Red Hat on the night of the attack? I didn't see them.

Re:This attack has obviosly shocked the comunity.

[Anonymous Coward]

As a FreeBSD user I am completely shocked.

Wait, no I'm not.

Re:This attack has obviosly shocked the comunity.

[GNUALMAFUERTE]

I completely agree with you, and we should open an investigation about the subject, you have only made one mistake in your theory: the "and they know Linux and its vulnerabilities", if they do, they would be making a better distro : )

Re:This attack has obviosly shocked the comunity.

[GNUALMAFUERTE]

jajaja, always the same ...
I use BSD too ... in fact, the hosting company that i work had Propietary BSD/OS hosting VPSs until 2000, Now our servers run GNU/Linux but our DNS server is running FreeBSD, at home i have an old mac running NetBSD, what i mean is that i like and i know *BSD; and is because of that, that i consider really stupid this GNU/Linux Vs. *BSD thing. For many tasks, such as desktop use (besides darwin off course), Free/Net/Open BSD are not ready, while GNU/Linux is. For others, like research or hobby programming, i think FreeBSD for example gives you a more interesting, less conservative plataform. And if you talk about Philosofy, i think we are on the same boat (except for some Linux Kernel Hackers that seems to be more money-making maniacs that bill itself.)
About Security, you should remember that FreeBSD and GNU/Linux differ on the Kernel, but 90% of BSD software is GNU Software, so, the vulnerabilities are the same in both plataforms, besides kernel ones, and some other that are especific.

Re:This attack has obviosly shocked the comunity.

[Anonymous Coward]

Yeah, let's all make fun of an Argentinian man's English ...

pendejo.

Re:This attack has obviosly shocked the comunity.

[Anonymous Coward]

About Security, you should remember that FreeBSD and GNU/Linux differ on the Kernel, but 90% of BSD software is GNU Software

This is not true. Basically, the only part of BSD that is GNU are GCC and binutils. There could be others.

But most components are not GNU at all. One reason why BSD is so refreshing compared to Linux is that the BSD style is so much different from the GNU style.

For any BSD box, it is almost essential that you install a lot of GNU tools. However, these tools are not an official part of the system, and not installed by default.

Re:This attack has obviosly shocked the comunity.

[GNUALMAFUERTE]

Let me correct your sintax:

For any GNU box,it's esencial to install a kernel, it can be HURD, Linux, FreeBSD, NetBSD, OpenBSD, etc,etc,etc.

But, besides this, i agree with you, but the fact is that without all that extra software just a kernel is useless.

Re:This attack has obviosly shocked the comunity.

[Anonymous Coward]

But BSD is more than a kernel !! It has its own user programs which are not GNU. It has its own version of everything. BSD is not a GNU operating system!

• It does not use GLIBC. It has its own, BSD libc.
  
• It does not use the same boot scripts or /sbin and /usr/sbin utilities as your typical Linux distributor.
  
• It does not use GNU ls, cp, mv, etc... It has its own BSD version of these.
  
• It does not use BASH. It has its own shell.
  
• It does not use GNU ncurses. It has a different version of curses.
  
• It does not use GNU Make. It has a BSD version of make which is not even compatible with GNU's.
  
• Many more examples ...
  

Etc. The point I was trying to make is that BSD and GNU/Linux are very different. With Linux, everything is developed in different packages, by different people. You have kernel, glibc, boot scripts, support utilities, etc., etc., all downloaded from different places.

With BSD, everything is developed together, by the same people. Some of them are taken from different places (like GCC, XFree86) but they are mostly original. AFAIK, the only GNU packages that are in BSD by default are GCC and binutils. You can install more, but those are extras, and not part of the BSD operating system.

BSD has a lot of code that predates GNU, and comes directly from Berkeley Unix. It also has a lot of code that was developed specifically for BSD. BSD is not a GNU operating system! Many people prefer to keep it that way.

One recommendation

[heironymouscoward]

Off-site logging of all accesses.

One of the first things that get wiped in an intrusion are the logs. All access logs should be copied in as near real-time as possible to a remote server that is not accessible from the machine being logged, i.e. a drop-box.

Re:One recommendation

[Anonymous Coward]

or a printer.

Re:One recommendation

[Anonymous Coward]

or a tape with no rewind button.

Re:One recommendation

[Anonymous Coward]

Yeah. I'd just love to be the person that has to pay for this.

Even then, real haxx0rs used the line printers to print over the old print so it was unreadable.

An electronic drop-box is the obvious best method.

Re:One recommendation

[jerryasher]

packet writing or multi-session cd-rom?

Re:One recommendation

[Malcontent]

Why not run something like LIDS. You can lock access to your logfiles so that only certain processes can run them.

It looks like a bit of work to set up and administer but you'd think that an organization like Debian would make sure all their computers would be running it.

Re:One recommendation

[Anonymous Coward]

If its not accesible how can the logs make it to this drop box? The only 100% way of making sure your logs don't get whipped is to send them to lpt. dot matrix printers are great for this.

Re:One recommendation

[Tyler Eaves]

Uh, as soon as you're r00ted any sort of local access controls are null and void.

Re:One recommendation

[SuperQ]

that's the whole point of LIDS.. LIDS provides kernel hooks to add extra level of access restrictions to the root UID. read up on LIDS before you speak.

Re:One recommendation

[suss]

One of the first things that get wiped in an intrusion are the logs

Try wiping logs printed out on a matrix printer...

Re:One recommendation

[BiggerIsBetter]

You can do remote logging via syslog, and there are interfaces to redirect to remote databases via ssh tunnel and so on - maybe to a dedicated logging box running OpenBSD and Postgres or something...

Re:One recommendation

[Malcontent]

Not with LIDS. You should look into it, it's pretty powerful stuff.

Re:One recommendation

[Feztaa]

Try wiping logs printed out on a matrix printer...

Any moron can buy white-out, I don't think a skilled intruder would have any difficulty hiding his tracks, given physical access. :P

Re:One recommendation

[Tyler Eaves]

Does it lock it down to the point of not being able to install a new kernel? I can't find the information on the site. In any case, with root, something like LIDS may make life harder, but I still don't think it'd be THAT hard.

Re:One recommendation

[gmby]

Cut the return transmit wires on the ethernet cable so data only goes one way. No way around that. think you can root a system that's not talking back! ;)

Re:One recommendation

[Tyler Eaves]

I actually don't have a linux system...

FreeBSD on the desktop and OS X on the iBook

Re:One recommendation

[Anonymous Coward]

War is necrophilia.

You're doing it wrong.

Re:One recommendation

[Anonymous Coward]

LIDS provides kernel hooks to add extra level of access restrictions to the root UID

How about you give me root access to a box that you have your precious LIDS installed on, I ftp over a fresh new kernel of my very own, argue with myself for a little while over whether I should use vi or emacs to edit lilo.conf, then give a happy ol' shutdown -r now.

So what was that about LIDS again?

Re:One recommendation

[Malcontent]

Is there something similar on the freebsd side? I think something like LIDS will come standard with kernel 2.6. I know freebsd has append only filesystems which are great for logs but it would be nice if they something like LIDS too.

Re:One recommendation

[Yottabyte84]

We do this at my work place. All our linux boxes send their logs on to a logging server, which saves the logs localy, and saves them to a mysql database on a another machine, using an account that only is allowed to insert.

Re:One recommendation

[Celvin]

To make sure my logs are secure, they are automaticly:

• posted to several usenetgroups
• posted as random comments to /.-stories (Along with some random anti-SCO/Microsoft propaganda so I don't get modded down and don't lose karma :)
• uploaded to the linux kernel CVS
• sent as email to all my friends

This way they are mirrored as many places as possible and hopefully cached by Google. Wipe that out!

Re:One recommendation

[Anonymous Coward]

yeah right, like i see one of my box shutdown on its own and don't suspect anything. Lamer.

Re:One recommendation

[Anonymous Coward]

Try wiping logs printed out on a matrix printer...

What if the attacker makes the system log a ton of bogus data, and the printer can't keep up? At some point a buffer will start to pile up in the computer's memory - if the attacker can root your box and clear out that buffer before it hits the printer (e.g. reboot immediately after installing their rootkit), you could lose several seconds/minutes of logs.

Re:One recommendation

[larien]

With physical access, all bets are off at the best of times.

Printing logs is a good idea in some circumstances; you will have a record of all actions and a remote intruder has no method of editing those logs. The main downside is the amount of paper it could use, plus it has to be kept supplied with paper & ink.

Re:One recommendation

[warrax_666]

Yes. You can lock the system down so that not even root can do anything. The concept is called Mandatory Access Control. Try googling and reading a bit about it, it's what (almost) all the big boys use for truly secure operating systems.

Re:One recommendation

[stefanb]

Try wiping logs printed out on a matrix printer...

Try logging in with random usernames from a class C 66*2000 times. Then start your attack.

Re:One recommendation

[Tyler Eaves]

But wouldn't that result in a machine that would be very hard to A: Do anything really useful with and B: Be hard as hell to fix if it breaks?

Re:One recommendation

[unixbob]

Installing a printer is something which is more likely to get your server rooted. lpd and X are notorious as security weaknesses because you are providing network access to your hardware.

A syslog server would be a much better solution

Re:One recommendation

[TiggsPanther]

One of the first things that get wiped in an intrusion are the logs.

This, in itself, can be a giveaway. If the logs are either missing, or have gaps in them, then you know that something is up, and you can keep a close eye on what's going on. (Or just restore from a recent known-good backup, just in case)

Tiggs

Re:One recommendation

[warrax_666]

Not really. LIDS has a super-super-user mode which you can only enter through a particular executable (which no one can tamper with if LIDS is set up properly) where you can fix things if they break. However, initial setup is highly non-trivial, mainly because some important unix programs just assume that they can create/modify files in e.g. /etc (passwd and mount have particularly annoying behavior in this regard). But once you're done setting everything up, you basically never need to touch the machine again.

Re:One recommendation

[Anonymous Coward]

Maybe you shouldn't advertise the printer around town then. Idiot.

Re:One recommendation

[Anonymous Coward]

I was going to say that wouldn't work, but I think with some static ARP it actually could.

The sending machine, (or last hop router) needs to know the MAC address corresponding to the IP address, in order to construct the ethernet frame to send. ARP is the protocol that does this and involves the destination machine *responding* to a (MAC level-) broadcast. But if that last router had a static ARP entry then it's a goer I think.

Of course, you are still wide open to exploits that don't need a return path.. ping-of-death type stuff, etc.

Re:One recommendation

[Odin's Raven]

Try wiping logs printed out on a matrix printer...

I used to print my logs on one of those matrix printers, but it was so difficult, having to read everything encoded. (As we all know, the translators work for the construct program. ;-)

Re:One recommendation

[QuMa]

Quite doable, nearly all dotmatrix printers are chainfeed and support running the paper back the other way. So you just roll the paper back a few pages and print all black (or dense random dots) over it a few times. Good luck getting your logs out from under that.

Re:One recommendation

[Clover_Kicker]

I took a quick look at lids.org, I don't know of a direct BSD equivilant.

FreeBSD has sandbox infrastructure called "jail". The idea is to sandbox all services so that an exploits can't escalate itself into root.

Jail chroots an environment and sets certain restrictions on processes which are forked from within. For example, a jailed process cannot affect processes outside of the jail, utilize certain system calls, or inflict any damage on the main computer

Jail is included with recent FreeBSD releases, but I'm told it is available for Linux.

Systrace takes a different approach, i.e.

With systrace, a system administrator can say which system calls can be made by which programs and how those calls can be made. Proper use of systrace can greatly reduce the risks inherent in running poorly-written or exploitable programs. systrace policies can confine users in a manner completely independent of Unix permissions. You can even define the errors that the system calls return when access is denied, to allow programs to fail in a more proper manner. (source)

Systrace is integrated into OpenBSD and NetBSD, and is also available for Linux.

Re:One recommendation

[tiger99]

Not to mention the noise......

Nonetheless, a good idea. It was quite common to see logging to a 132 column printer with something like A3 size fanfold, with the green stripes, many years ago. The problem now it that inexpensive printers are inkjet, and are pageprinters, they don't want to print a line at a time, unlike the old dinosaurs. I don't even know if it is possible to buy dot matrix, inky ribbon printers any more, or even electric typewriters with an interface. If someone knows how to get line by line printout using modern, inexpensive equipment, please let us know.

Re:One recommendation

[chowells]

Marking important files as immutable 'chflags schg' and raising the secure level of the kernel to 1 or so (so that the immutable flag can't be removed), is also a favourite of mine. High enough secure levels will also prevent kernel modules from being loaded.

Great stuff.

Re:One recommendation

[tiger99]

The delay usually built in to the login program, which in some cases doubles at every failed attempt, would take care of this. Don't know what it is called in a network environment, in the old days of simple dial up modems or direct RS232 connection, it was done by a daemon called "getty" which was replaceable, if it did not have that feature already. Maybe it is done by pppd or something nowadays, or in a different place if you connect via ethernet instead of point to point, the same delaying tactic could still be applied, the extra code surely can't be difficult if it is not there already.

You would want to consider the netmask in addition to the address as the id to control the algorithm, so a hacker who was using random addresses would still get clobbered.

I don't have a Linux machine in front of me right now so I can't check, but I strongly suspect that all of this will have been done years ago, to deter brute force attacks. If not, why not? Maybe everyone thought someone else would do it? Maybe someone should do it pronto!

Re:One recommendation

[tiger99]

But they have to know it is there first, and there is no requirement to use either lpd or X for a simple lineprinter, and you can obfuscate things by making a device file with a weird name which simply accesses the serial or parallel port.

Re:One recommendation

[tiger99]

Why not alter the logging programs? Surely we are only talking about turning a few numbers into human-readable values? With sed, awk, perl....... it can't be all that difficult, if that is what you need to do.

Re:One recommendation

[the_bard17]

It's still possible... Dot Matrix Printers At Staples.com. They've got the ribbon, too. Not that I'm preferential towards Staples, but they do supply a lot of businesses. There are businesses out there that still use carbon copy paper (for receipts, invoices, and the like). Inkjets don't do carbon copy ;o). Whenever I get around to setting up my home network, I'd like to have any "critical" machines have a "logger" machine hooked up to the critical machine via a serial cable only. Send the logs through the serial cable, and there's nothing that I know of that the cracker can do to erase that log.

Re:One recommendation

[unixbob]

I didn't say you need X to run a printer, I said that daemons and processes that communicate with hardware over the network are notorious for being vulnerable to attack and X and lpd were among the most common culprits.The only way you are going to find a vulnerability on a server is by looking. To break a machine you don't think "what do I know about this server which will might be vulnerable", you have a dig around to see what you can find.

My point was more to with not over complicating the issue. The best way to ensure you server never gets compromised is to run the bare minimum of services on it, and then ensure that you stay on top of the system at all times. The more simple your system is, the easier it is to keep secure. the more functionality you provide, the more likely it is that you will be compromised. Especially when you run a farm of 100's of servers

Re:One recommendation

[Tyler Eaves]

interesting stuff. Must admit, I run at secure level zero, and haven't really dug into the security stuff. I figure I've got a reasonably secure system (NATed, firewalled, only ports 22 and 80 allowed through, no remote root logins), which frankly is all I need. I make regular backups, so even if I got rooted, worst case I just grap my install CD, wipe the drives, and I'm back up and running inside an hour. Never happened, thankfully, but I am prepared just in case.

Re:One recommendation

[ThePeices]

How about using a computer emulating a simple line printer, and storing the "printed" data onto its HDD. being connected via the parallel port as an output only device, its pretty much secure. No paper/ink issues.

Re:One recommendation

[HiThere]

My first thought was CDs, but they also want to write in huge chunks. There are cash register style printers, I guess. Or a paper tape punch would be a good answer. Maybe the best answer is a serial connect to another computer that is dedicated to doing nothing but buffering data to a CDR. The serial connect should be relatively invulnerable, at least unless you allow backspacing to overwrite the buffer. And it could be a really underpowered machine. Even an elevator controller would have enough juice, but finding one that could write to a CD might be a bit difficult.

Re:One recommendation

[Anonymous Coward]

sent as email to all my friends

You have friends? How'd you manage that one?

Re:One recommendation

[HiThere]

Who said anything about "over the network"? The comments I saw were talking about serial cable connections. You know, RS232C 5 pin connections, though perhaps the printers only used four of them. (The cable had 25 pins...but you don't use most of them to talk to printers or modems.) Old stuff. No network knowledge or capability, and frequenly requiring custom cable wiring.

Personally, I think that printouts are the wrong answer because you can't search them, but pseudo printouts to a computer that's emulating an Epson MX 80, only spooling it to a CDR seems like a good idea. You can't reach it because you can't reach it (the printer cable can send "Here I am" and "OK, I'm ready to receive", to the computer it's attached to and that's it [well... there's also a ground and a chasis ground...but that's not very informative]). But it can accumulate bytes that you send it, pack them up, and write them to a CD for later analysis. And you can use the oldest computer around that will write to a CD, it doesn't even really need an OS, because you're using it as a dedicated machine, but a super-stripped down version of Linux would make it easier to configure. But there's no daemon listening to the port in the normal sense. It's a custom program that buffers the port to a ram-disk and periodically writes it to CD (probably via a normal system command).

Actually, you could use normal system commands for that, since the danger is miniscule. But I think the programs for monitoring the serial ports are already written, so why not use them. The only question in my mind is "does this system need to have a hard disk?" But it would probably be easier to build it with one than without.

Re:One recommendation

[unixbob]

The OP just said Try wiping logs printed out on a matrix printer...

Never said anything about it being serial or on the network. i just said that running lpd was a bad idea and that running more than you absolutely need is a bad idea.

Re:One recommendation

[Ice_Balrog]

Once I got physical access, I won't bother cracking thet system. I'll just pop out your HD and bring it home. >:]

Unless, of course, I need you to not notice that I did anything... Then I could boot from a CD to KNOPPIX or something. If the BIOS is password protected, then I would have to reset it it (just pop out the battery and wait a few minutes). And now I have once again complete control of your system.

Preventing a local exploit is next to impossible if the person has access to the machine itself. Unless someone else is around, that it.

Re:One recommendation

[schon]

The main downside is the amount of paper it could use

No, the main downside is that it's a bitch to run grep on a printout. :o)

Re:One recommendation

[Anonymous Coward]

just said that running lpd was a bad idea and that running more than you absolutely need is a bad idea.

Yet the thread is all about people ruminating on hard-copy logs being something they need. Did you miss that part? From the sound of it, hardcopy logs is a foreign concept since you pooh-pooh with boilerplate security blather without alternate suggestions. We all know complexity creates security difficulties, buddy, now maybe you can move on to the "helpful" part of your personality (if you have one).

Re:One recommendation

[__past__]

In addition the the mechanisms mentioned before like securelevels, jails and fs flags, FreeBSD 5 has the MAC framework from the TrustedBSD project that can do some funky stuff, similar to what LIDS or SELinux do (in fact, some MAC modules are derived from SELinux code). It's an extensible modular framework with default modules that implement the usual Mandatory Access Control policies, like being able to specify which processes may do what with which files etc. It is documented in the Handbook and on the TrustedBSD site. FBSD 5 also has extended filesystem ACLs (POSIX.1e style), like LIDS.

One thing still missing are full POSIX.1e capabilities, but they are being worked on.

Re:One recommendation

[Odin's Raven]

Sorry, tiger99 -- I wasn't being serious.

Something about the phrase "matrix printer" sent my brain off on a Matrix movie tangent. (Don't worry -- I grew up with dot matrix printers...I know what the parent poster was truly talking about.) Anyways, what I was shooting for was a light parody of a scene in "The Matrix". The one where Neo is looking at the operator station's displays, and asks Cypher "Do you always look at it encoded?", to which Cypher replies "Well, you have to. The image translators work for the construct program".

Figured since a "matrix display" was always encoded, a "matrix printer" would be similarly difficult to read -- columns of odd characters running down the page, that sort of thing. And someone like Cypher reading through it, saying "You get used to it. I don't even see the code. All I see is Slammer, SubSeven, Code Red..."

It made a lot more sense to me back before I'd finished my first pot of coffee this morning. ;-)

Re:One recommendation

[unixbob]

Are you seriously telling me that you are going to run a printer on every single server in yout datacentre? wow. I'd like to see your UPS and cooling bill. Never mind your costs for increased space. "err, yes boss. we need to expand the datacentre by 300 feet and buy an additional generator becuase I thought that it'd be a good idea to put a printer on the back of each server instead of using the space for actual servers. By the way, whilst you've got the cheque book out, can you sign of this purchase order for more printer paper . . . "

Good for you if you have the time to spend reading printouts from every single server that you have on the off chance that you spot something. Excellent if your company has money to burn paying the staff in your remote site to fill the printer with new paper. And whilst the rest of us in the real world are browsing the logs on our syslog server, spotting when the server behaviour went awry, and how many other servers are exhibiting the same behaviour, we'll leave you to read your printouts. Ever tried runing grep on a piece of paper?

Anonymous Coward, move along please.

Re:One recommendation

[gmby]

It's easy..

Just setup a syslog server and client that run normal and then setup a box with the wire cut that just watches for syslog packets and logs them.

Script punk goes for the box he can see and never knows about the other. The box hes sees would'nt even need much storage because it's just to answer the log packets.

He may be able to stop further logging but not get to the previous logs on the real logging server.

No doubt this will require some code written. But Me No Know. New project anyone?

But wait....

[Anonymous Coward]

When has windowsupdate ever been compromised? What's that? Never. SUCK IT, fanboys, you make me fucking SICK. Looks like open-sores isn't going to save the world after all...

Re:But wait....

[Aussie]

When has windowsupdate ever been compromised?

Windows Update is served by Akamai ie Linux.
Now what was your point ?

Re:But wait....

[Anonymous Coward]

That is but one of the sites that serves windows update. How typically dishonest for a Linux zealot to assert that they are the sole provider of Windows Update.

Re:But wait....

[Anonymous Coward]

Windows Update was rooted by Code Red, for one.

Re:But wait....

[Anonymous Coward]

Do you think Microsoft would make a breach like that public? How typically doublethinkful of a Windows lackey.

Re:But wait....

[Anonymous Coward]

windowsupdate was compromised by the ramen worm, and it is not served by akamia, they merely offer proxy/caching services to microsoft in front of the real servers.

Re:But wait....

[Aussie]

they merely offer proxy/caching services to microsoft

True, I should have made my point better.
There are many OS's involved in the windowsupdate chain.
I read somewhere Akamia uses quite a variety including BSDs, Linux etc. Who knows what MS actually uses.
So compromising windows update might be achieved without cracking a Windows box.

Re:But wait....

[placeclicker]

That Windows can't fill in for Linux on extremly high-bandwidth servers? ( those patches aren't small )

Re:But wait....

[Anonymous Coward]

Not only isn't Akamai just a proxy/cache server, they just hold signed files. If someone managed to hijack/compromise those, the downloaded updates would not verify on the user's machine, so it's pretty much a void argument.

Re:But wait....

[Anonymous Coward]

Yup.

Re:But wait....

[Anonymous Coward]

I believe back then ( actually it was codered or nimda, not ramen! my mistake ) that the windowsupdate service was running on windows boxes, which is still the case, the difference was back then that akamai was not involved.

Re:But wait....

[Anonymous Coward]

the Debian mess is actually more like Microsoft's Windowsupdate, Officeupdate, and MSDN servers all getting rooted at once. Akamai uses Window servers too, as a heterogeneous network is more resistant to this kind of attack. If the root attack that was used is portable across architectures (and there's only circumstantial evidence that it's not) then Debian is doing users a disservice by not running a heterogeneous network.
Given the resources, the Debian admins should run OpenBSD and Windows 2003 machines alongside the (evidently insecure) Debian servers.

Re:But wait....

[Anonymous Coward]

Mod parent down: -1 believes anything bad he hears about Microsoft.

Or Debium?

[Anonymous Coward]

The

Great

[headbulb]

Right as I am downloading Debian.
I will check the md5sum.

Anyways Something to be said about passwords.. I am getting sick of passwords.. I have looked at the RSA keychains, But they cost too much.

So I ask are there any good one time password systems out there. That are opensource.. I have looked at going with smart cards but again with the money. (not to mention overkill for me)

I have found a few but none with a keychain.. I don't mind paying for a keychain, but I want the software to be opensource.

Re:Great

[Anonymous Coward]

Hope they didn't fuxx0r the MD5 on the server.

Check it with a known-good sum from many servers and sources.

Re:Great

[Anonymous Coward]

S/KEY is a one time password Open Source system.

Re:Great

[Qzukk]

Probably the closest you'll get to a "good" system would be something like S/Key or Opie (debian packages: opie-server, opie-client, libpam-opie - Use OTP's for PAM authentication) for generating and using a one-time-pad of password systems. The issue in this is that you must generate the pad in some secure fashion, if someone sniffs your pad because you downloaded it over the network, you've lost.

You could easily keep a pre-generated giant pad itself on a usb drive or something similar.

Re:Great

[Anonymous Coward]

Is this or this something like what you were looking for? It's all open source. Just get a cheap USB flash drive and you should be set.

Re:Great

[Anonymous Coward]

Smartcards are way cool, and aren't all that expensive. You can get a complete setup for $50ish.

Re:Great

[warrax_666]

SRP looks very interesting too. It's a zero-knowledge based system and does not even require encryption when authenticating to be secure from capture/replay and brute forcing. It does not require a key to be stored locally at the client (you simply use a passphrase), and the server does not have enough knowledge to reconstruct the password. Furthermore, the password is never transmitted to the server.

One caveat though: You need to generate/transmit the password in some secure way (as is the case with all systems).

Re:Great

[Avian visitor]

One of the remote root exploits for ssh that came out this september only worked, if ssh wasn't using privilege separation. Unfortunately libpam-opie doesn't work with this setting enabled.

So if I would stick with my old password and privilege separation (that is enabled by default) my box wouldn't get rooted. Sometimes OPIE can make more problems than it solves.

Password was *sniffed*

[enosys]

Apparently the password was sniffed . This generally implies that it was obtained through monitoring network traffic and seeing it trasmitted in cleartext. A strong password wouldn't help here; only a good protocol would.

This was both user and admin stupidity I guess. Admins who care about security shouldn't permit access through cleartext passwords and users shouldn't send their password in cleartext if they care about their account. Unfortunately many users don't know about this risk.

Re:Password was *sniffed*

[TheRedHorse]

Why assume it was a cleartext password? It could of been encrypted, captured and crack via brute force or some other method.

Re:Password was *sniffed*

[Anonymous Coward]

The password was sniffed by the trojaned sshd on an unrelated machine.

Re:Password was *sniffed*

[DA-MAN]

It said sniffed, not sniffed and cracked via brute force

Re:Password was *sniffed*

[Xzzy]

"cleartext" implies a situation where the letters a user is typing in on his keyboard are being sent unencrypted over the network, like over a normal telnet connection.

The state of the password being sent really isn't what's being discussed, since once the connection is unencrypted, it doesn't matter.

Re:Password was *sniffed*

[gl4ss]

one use passwords could have helped.

yeh they're a bitch but anyways....

Re:Password was *sniffed*

[radargeek]

Ah, but the SucKIT rootkit is particularly useful as it captures all tty i/o at the kernel level: all interaction with sshd is captured in a "sniffer" file. No decryption or packet sniffing needed- the attacker owns the system completely if they have installed SucKIT. If you don't trust a computer that you have ssh'd into, never ssh or scp from the untrusted computer back into your trusted systems. If the untrusted computer has been compromised, any login sessions that you have from the untrusted computer will expose the passwords if a SucKIT rootkit has been installed.

Re:Password was *sniffed*

[Anonymous Coward]

That'd be "could have", not could of. Get with the fucking program.

Re:Password was *sniffed*

[TheDarkener]

Thank you. I was reading parent posts going, "Umm, I don't remember hearing anything about any pw cracking being possible since it was an encrypted connection or whatever, so if it was sniffed it obviously was done in clear-text. The people who did the foresnics on those boxes (and who wrote the paper) simply would have stated that. I have the utmost faith in said Debian.org sysadmins. And I applaud their open-source approach to the attack. You really wouldn't ever see something like that coming anyone else.

That's a lot, coming from me... I'm usually pretty pessimistic .. ;)

Re:Password was *sniffed*

[Anonymous Coward]

Now you know the importance of bathing your password regularly and making sure it has been properly deoderized. Stinky passwords will certainly be sniffed!

Re:Password was *sniffed*

[Anonymous Coward]

Well thank you, Captain Obvious.

Unencrypted connection? Ooh that's rich. Better tighten that right up. Encrypt the keyboard while your at it.

Re:Password was *sniffed*

[Wyzard]

That's a good reason to use public-key authentication with SSH, rather than password authentication. That way, the attacker looking at SucKIT's logfile only sees a challenge-response exchange, which can't be replayed thanks to timestamping.

Re:Password was *sniffed*

[Anonymous Coward]

HAVE!!! That is 'could HAVE'. Stupid fucking American start learning your own fucking language.

Re:Password was *sniffed*

[26199]

The solution to logging in from untrusted computers is to use one-time passwords... and keep a sheet of a few hundred in your wallet.

Re:Password was *sniffed*

[26199]

(well, I say 'solution'... obviously it's more complicated than that)

Re:Password was *sniffed*

[wobblie]

No, the password was obtained somehow, not neccessarily sniffed over the network. It could have been "sniffed" looking over someone's shoulder.
How would they know how the password was obtained?

Re:Password was *sniffed*

[Anonymous Coward]

Eat another fucking banana you stupid fucking tree nigger.

Re:Password was *sniffed*

[ansak]

It would seem, then, that someone who was accessing debian's servers legitimately might have been doing so from a SucKIT-infested host. Do all the relevant people know what the state is of all relevant machines they might have used to get into Debian?

Re:Password was *sniffed*

[swillden]

Why assume it was a cleartext password? It could of been encrypted, captured and crack via brute force or some other method.

Using weak encryption is still an admin problem.

An attacker capable of breaking good encryption would have much better things to do than attacking the Debian servers. Like writing a paper that would guarantee him a cushy professorship, or selling his services to a government.

Re:Password was *sniffed*

[pileated]

My god! Two informative responses in a row, by someone who actually read the article. I was wondering if I'd misread it myself since I recalled it saying that password was sniffed and then everyone went on about what type of password it was and how to come up with good passwords. If they're sniffed I don't see that it makes any difference.

This reminds me of an article, perhaps first read here, about someone saying that the age of IT departments was about over. The problem of security and general ignorance about security seems to indicate that that really is untrue. It's sort of like people having their first gas stoves and no one warning them that it's not safe to just leave the gas turned on all day, or having their first car and not being told about the brakes. When computer users use their computers with the same intelligence that they use appliances like stoves and cars (and I do realize it's probably a minority of population that DOES use them with intelligence) then I think it will be safe to say IT departments are no longer necessary.

Re:Password was *sniffed*

[stile]

If a protocol was used in which a hashed or encrypted password was sent to verify credentials, then this is as bad as sending a cleartext password due to replay attacks. Only something like SSH can save you from sniffing.

Re:Password was *sniffed*

[Abcd1234]

As if any decent protocol would send your password over the wire in any form during the authentication phase. Why would they? It's an obvious protocol flaw, and since both parties share a secret, so it's fairly straight forward to authenticate each other using some other mechanism (eg, challenge-response).

Re:Password was *sniffed*

[NtroP]

OK, I'll bite.

How do you set that up? We run a bunch of RH servers and it would be great to generate a series of one-time passwords that we could hand out to our remote admins. Is there a mod_pam plugin that does this? How do the passwords get generated and stored?

I've heard of this system in conjunction with a smart card, but it is proprietary and expensive.

Is there an open source implementation for this?

Re:Password was *sniffed*

[Anonymous Coward]

A five second Google search turns up a lot of information on this topic.

Here's a solution for FreeBSD. A little time spent searching and you can probably find a similar solution for RH.

Re:Password was *sniffed*

[Anonymous Coward]

Try: strace sshd

Re:Password was *sniffed*

[mvpll]

Err, how does this help in the parents case?

He was talking about connecting from the comprised machine back to your own machine. If the key is already on the comprimised machine and not password protected, the attacker is home and hosed.

Re:Password was *sniffed*

[ManxStef]

For admins that'd like a way to check for rootkits I'd recommend looking at chkrootkit. While it's not a 100% reliable method (and there may be restrictions: for instance, compiling it on a compromised remote box from uploaded source isn't secure*), it's good as a quick 'n' dirty check. Worth a look at the links at the bottom of the above site too for more info on rootkits, there're some excellent articles listed.

Also of interest would be Nessus - a vulnerability scanner which uses NMAP and other tools that may identify potential points of ingress on a suspect box.

*In this case you'd be best off running pre-compiled trusted binaries off a read-only source such as a CD, or mounting the suspect drive on another machine - though this depends on whether you can get physical access to the box to do either, or if you have truly awesome datacenter techs that can help!

Re:Password was *sniffed*

[Anonymous Coward]

Decrypting SSL packets with openSSL

Re:Password was *sniffed*

[26199]

S/Key is also available on Linux...

Re:Password was *sniffed*

[Wyzard]

Sorry, I should've clarified. If you use ssh-agent (or Accession in Windows), you can "forward" the agent connection, meaning that it's still accessible from the remote end.

For example: You have a private key on machine A, which you load into the agent running there, and the connect from machine A to machine B. Nothing out of the ordinary yet. Next, you connect from machine B to machine C, and this connection authenticates by talking to the agent running on machine A. Machine B doesn't need to have any private keys on it.

I do this regularly, and it works great. As an added bonus, once a key is stored in the agent, it can be used without typing the passphrase every time; I type my SSH passphrase once when I log in, and it stays with me for the duration of my session. (Of course, as a precaution, I have a hotkey set up to flush the key from the agent if for some reason that's necessary.)

Root password

[phorm]

Once an infiltrator is in a machine, it is often just a matter of time before he acquires root access - unless monitoring or disablement are standard procedure.

Depending on the power of the box and the time from which the lower-level account was compromized, it could just be that a password-cracking procedure gained root access. Of course, it's also possible that the attacker managed to nab control of a process running as root, but again the initial compromise still required cracking a password to gain access to the machine.

First rule, secure your passwords... and it's probably not a bad idea to use a password cracklib to ensure that any semi-privileged (can SSH) users have somewhat secure passwords as well.

Re:Root password

[DJ Rubbie]

Also, make sure those users can SSH *will not* submit passwords as clear, plain text, even for use inside the network! I know places that insists on using SSH, but don't care so much about FTP, even if the FTP account is the same user name AND password as the SSH account. One admin there even told me to telnet(!!!) to another remote machine within the network.

Motto: don't [write|send|communicate] your passwords in plain text, ever! If you do, change it! (always change the password root gives you, which usually arrive in plain text..)

Re:Root password

[Anonymous Coward]

Umm, shadow passwords have been the default on any serious Unix-like setup for quite a while. Password crackers would have to go through an authentication program, which is pretty slow.

Usually local users gaining root access is done by expoloiting bugs in privileged programs or the kernel. Unfortunately, while remote root vulnerabilities are becoming more rare, local root exploits are still common. Of course they aren't anywhere near as trivial as they used to be in the late 80s and early 90s...

Proof that Windows is more secure

[Qrlx]

Not really, just thought it needed to be said.

Re:Proof that Windows is more secure

[BiggerIsBetter]

Nah, it's just that rooted Windows boxen aren't news anymore.

More seriously though, it's proof that hetrogeneious networks are a good idea. Eg, Debian x86 got rooted, but Debian Sparc apparently didn't.

Security "experts"

[Anonymous Coward]

Have any other developers here noticed that all "security experts" are non-technical consultant types? At the most, they are system administrators. Yet for some reason, we let these non-techie posers ramble on about "security" when at the most they have Devry degree or a bachelors in something like English (or even worse, in MIS).

Re:Security "experts"

[crimsun]

To be fair, not even the technical consultant types and the security "experts" get it right all the time. The real world is very, very different from the edges of theory.

Furthermore, just because someone has "at most" a degree in English doesn't mean fresh insight hasn't been exposed. Narrow-minded elitism gets us nowhere.

Re:Security "experts"

[Anonymous Coward]

Come to DeVry University!

http://www.devry.edu/admissions.html

We can make you a "security expert" and it will only cost $50k!

Easy solution

[therufus]

Install windows. You'll never have to wonder if your system is being compromised, you'll know it is.

Oh, and "password" is not really a "password".

Re:Easy solution

[Anonymous Coward]

sed s/windows/debian/

ha fucking ha

Oh great!

[Anonymous Coward]

Now I'm wondering how secure the flu-shot I got last week was. What if someone rooted their distro or infected it with one of those V-word things?

#1 on Ten Immutable Laws of Security

[Saint Stephen]

I worked at Microsoft, so Microsoft's list is my frame of reference:
Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore.

Re:#1 on Ten Immutable Laws of Security

[Kulic]

Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore.

Two words: Outlook, IE.

Oh the irony.

Re:#1 on Ten Immutable Laws of Security

[prockcore]

Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore.

That's why I've been saying for years that all my computers are owned by Bill Gates.

Re:#1 on Ten Immutable Laws of Security

[Anonymous Coward]

thats like four words fuckass

Re:#1 on Ten Immutable Laws of Security

[jkrise]

Law #2: If you can get back your system to pre-disaster condition after a floppy boot, you're running Linux!

-

Re:#1 on Ten Immutable Laws of Security

[eyeye]

That law makes much less sense on multiple user systems (i.e the subject of the article).

Re:#1 on Ten Immutable Laws of Security

[Gleef]

Not that I even like Microsoft's security list, since it's very Windows-centric, I'll bite.

Law #1 doesn't apply here. The intruder sniffed a password, and ran his own software. As far as I know, nobody was tricked into running malicious software. Law #1 should read, for real OS's
"Law #1: If a bad guy can persuade you to run his program on your account, its not your account anymore."

The first failure, as per this list was Law #5 "Weak passwords trump strong security." Someone didn't properly protect their password, this gave the attacker their foot in the door.

The second failure was the unidentified privilege escalation. This doesn't appear to fit any of the laws (they appear to be written assuming privilege escallation is trivial, I guess that says something about Windows). Except perhaps, Law #10: "Technology is not a panacaea". Just because we run well designed software that has few security holes doesn't mean that we run perfectly designed software that has no security holes.

Occasionally something slips through the cracks, like here, and it's good to know that real people are paying real attention, and that there are effective ways of bringing necessary systems back up in a trusted fashion. Eventually, this escallation will be found, fixed, and machines patched.

Re:#1 on Ten Immutable Laws of Security

[SamNmaX]

I wish Microsoft had more to say about this "Law #1". I think the personal computer is in dire need of a serious security overhaul. Running a program shouldn't equate to giving it total access to your computer. Obviously it's impossible to cover for all issues, but something as simple as double clicking on an application (or attachment) SHOULD NOT be able to wreak havok on your computer. Most programs only access files that the user explicitly asks for in a dialog box, so why should they get access to everything? All programs should by default be around the equivalent of a sandbox, mixed with a UI that implicitly gives a program access only to files the user chooses in some manner. Only programs that absolutely need access to the entire system should get it, such as virus scanners. (which hopefully wouldn't be needed in such a system)

Re:#1 on Ten Immutable Laws of Security

[mentin]

Law #2: If you can get back your system to pre-disaster condition after a floppy boot, you're running Linux!

More likely you are running MSDOS.

Re:#1 on Ten Immutable Laws of Security

[Saint Stephen]

"Law #1: If a bad guy can persuade you to run his program on your account, its not your account anymore."

I think this hinges on the definition of "bad guy". To my mind, "bad guy" means "guy who knows how to gain root from an unpriviledged account".

*Anyone*, good or bad (== knows how to gain root or not), who runs a program under your account, has owned your account. A "bad guy" who knows how to gain root owns your computer. Which is what (might) have happened here.

I think the lesson they are trying to convey is: assume people know how to gain root. Which is the scary thing here, and anywhere.

Re:#1 on Ten Immutable Laws of Security

[autopr0n]

Law #1 doesn't apply here. The intruder sniffed a password, and ran his own software. As far as I know, nobody was tricked into running malicious software. Law #1 should read, for real OS's "Law #1: If a bad guy can persuade you to run his program on your account, its not your account anymore."

So linux isn't a real OS now?

Re:#1 on Ten Immutable Laws of Security

[dipipanone]

thats like four words fuckass

Heh. Not only can you not count, you can't punctuate and have no idea about the rules of grammar either.

I'd shut up now, if I were you.

Re:#1 on Ten Immutable Laws of Security

[zonix]

The second failure was the unidentified privilege escalation. This doesn't appear to fit any of the laws (they appear to be written assuming privilege escallation is trivial, I guess that says something about Windows).

[emphasis mine]

Or next to irrelevant! All the exploited Windows services I know of run with root privileges on a default setup.

And in the case of exploiting security holes in programs (like IE and Outlook) your typical user - in session - is not likely a non-root user. Definately not on the Win95/98/Me versions of Windows, and most likely not on Win2K either.

z

Re:#1 on Ten Immutable Laws of Security

[Anonymous Coward]

"And if that account is root, you're so so very screwed."

Re:#1 on Ten Immutable Laws of Security

[Anonymous Coward]

"Law #1: If a bad guy can persuade you to run his program on your account, its not your account anymore."

Even though you must feel very superior saying this, the microsoft version of that law is true. Running un-audited code on your computer will compromise your computer. The simple fact that root-kits exist makes this law extremely valid.

By saying that this law is "windows centric", you are commiting the foolish mistake of thinking Linux/*Nix is bug free... a criticism often attributed to Windows.

I think you've basically contradicted yourself in a single post.

Re:#1 on Ten Immutable Laws of Security

[Gleef]

Anonymous Coward trolled:
Even though you must feel very superior saying this, the microsoft version of that law is true. Running un-audited code on your computer will compromise your computer.

No, I maintain that thinking about things in this matter leads to bad understanding of the layout of risk, and therefore to bad security. Compromise of a user account and privilege escalation are two separate issues, and lumping them together leads to mistakes.

Case example: Lab setup for a computer programming course, one central computer, a dozen terminals. Each student has a user account where they develop programs and then email them to an instructor account on a different machine. Three security concerns: deny unauthorized access in general, allow students to keep their work private, prevent students from assuming each others identities to read work, submit flawed assignements, etc. These are programmings students, they are running unadudited software all day. By your measure, and Microsoft's measure, such a setup is impossible to secure. By my measure, such security goals can be handled by appropriate choices of tools and procedures.

The simple fact that root-kits exist makes this law extremely valid.

This sentence is a non-sequitor. You force me to assume you have no idea what a root kit is. A root kit is a set of programs, usually designed to masquerade as system software, to maximize the chance that once you have obtained root access once, you can keep it.

A root kit is only relevant after root access has already been reached. If you install a root kit in a user account, you have a johndoe kit, not a root kit. Hence, privilege escalation is the important bit here, not "unaudited code". This, again, supports my point that the law is faulty as written.

By saying that this law is "windows centric", you are commiting the foolish mistake of thinking Linux/*Nix is bug free... a criticism often attributed to Windows.

No, by saying the laws are "Windows Centric" I am pointing out that they make assumptions that, while true on Windows, are not universally true. One of these assumptions is that once a user account is compromized, the machine is compromized. Most other operating systems, including Linux, don't make this assumption, and attempt to protect against privilege escalation.

Even Windows, as an operating system, no longer makes this assumption, once you leave the 95/98/ME codebase. Now if they can get their applications programmers to stop circumventing Windows security system, they might stop being a joke.

Why would anyone assume I was claiming that Linux is bug free, in a comment about a Linux security flaw?!?

I think you've basically contradicted yourself in a single post.

I think I've seen twelve year olds with better reading comprehension than you. Even in your own post, you have not attempted to identify any contradiction.

Re:#1 on Ten Immutable Laws of Security

[Gleef]

Saint Stephen wrote:

I think this hinges on the definition of "bad guy". To my mind, "bad guy" means "guy who knows how to gain root from an unpriviledged account".

To my mind, in this context, a "bad guy" is anyone who wants to do something unauthorized on my machine. Once they've broken into someone's account, they're a bad guy whether or not they know how to get root.

I think the lesson they are trying to convey is: assume people know how to gain root.

Yes I would agree this is the lesson Microsoft wants to teach, and this is part of why I consider it "Windows Centric", since this is an assumption made by many in Microsoft and the Windows community. Most of the rest of the OS world considers privilege escalation a separate issue, that requires its own mechanisms and procedures to protect against.

Strangely enough, it's no longer even an assumption in the people who actually write the Windows operating system. Once they dumped the completely flawed (security-wise) 95/98/ME codebase, they were left with a version of Windows that actually cares whether you are a user or Administrator, and makes significant efforts to keep an unprivileged user from privilege escalation.

The trouble is, the rest of the Windows community hasn't followed suit, so you have application software that forces sysadmins to give users administrator privileges, and all sorts of other holes in the security model, all because Microsoft encourages security where you "assume people know how to gain root".

A simple disaster-mgmnt starrtegy...

[jkrise]

Since Linux has no use for hidden files, registry, active directory, complicated booting procecdures and other useless features that come standard with Windows - I see no point getting worked up about these so-called Security Warnings.

99% of Slashdot readers, I believe, treat viruses, worms and other 'security' attacks as a NUISANCE rather than a PRIVACY hazard. A Service Pack or bug fix a week for Windows merely highlights the fact that data privacy on a 'personal' computer is a joke. The nuisance of reinstalling the Windows OS from CD, and reinstalling each and every app with the zillions of settings OR buying expensive, uunreliable 3rd party s/w for disaster recovery can be intolerable.

With Linux, OTOH, simple tools exist that can take backups of disk data (not disk images, just the files), AFTRER installing the apps. A simple restore of these files gets the system back, with all settings and screen-savers intact.

To sum up, 99% of Slashdot readers do not need to care about these security risks, if they choose Linux for their personal or office systems.Those with Windows - a switch to Linux is cheaper than anti-virus s/w PLUS OS cost PLUS frequent updates PLUS frequent reinstalls PLUS loss of data PLUS nuisance.

-

Re:A simple disaster-mgmnt starrtegy...

[Anonymous Coward]

Whatever, fanboy. Just keep telling yourself this.

Re:A simple disaster-mgmnt starrtegy...

[Anonymous Coward]

Ummm... ok. Score one for the jobless wonder.

Re:A simple disaster-mgmnt starrtegy...

[Anonymous Coward]

WarCraft III doesn't run on Linux, and WINE is, well, WINE.

Don't expect too many converts.

Re:A simple disaster-mgmnt starrtegy...

[Anonymous Coward]

.... MINUS learning curve MINUS compatibility with standard off-the-shelf applications

Re:A simple disaster-mgmnt starrtegy...

[jkrise]

With Linux, it's ONE SINGLE learning curve for life. With Windows, you need to keep forgetting and re-learning with every version or Service Pack.

And BillyBoy is learning from your mistakes.

-

Re:A simple disaster-mgmnt starrtegy...

[dbIII]

A Service Pack or bug fix a week for Windows

You say that as if it's a bad thing. It is a sign that Microsoft is lifting their game. The Microsoft of days gone by would just tell us to wait for Longhorn. Give MS a break - their main operating system is now actually a true multiuser system!

Re:A simple disaster-mgmnt starrtegy...

[Anonymous Coward]

Linux has no use for hidden files, registry, active directory, complicated booting procecdures and other useless features

Nice try. Your config files are scattered all over your system, and I'll bet you don't know where half of them are. Also, the file locations aren't portable knowledge: they vary from distro to distro, and between versions of the same distro.

buying expensive, uunreliable 3rd party s/w for disaster recovery can be intolerable
I use DriveImage, which has been 100% reliable for me ever since it came out, and it can image all of my operating systems. Making a bootable restore image is a piece of cake, and network restore is just as easy. Notice that the compression is also top notch.

PS: you need a spell-checker, moron.

Re:A simple disaster-mgmnt starrtegy...

[King_TJ]

I'm in total agreement about the added hassle of Windows registries, active directories, and so forth. But your argument about backup/restore of data applies equally to *any* OS a person chooses to run on their PC!

There are pretty good tools out there to do a complete Windows backup too, you know. "BackUpMyPC" comes to mind. It's a no-brainer to use, yet it's based on the fairly full-featured "Backup Exec" software that's been around and enhanced for years now, as it changed hands from Conner/Seagate to Veritas to ???. It makes a complete backup of the system registry with a single mouse-click in a check-box, and knows how to back up open files. It works with tape drives, DVD burners, or CDR/CDRW drives.

Sure, you'll have to buy and maintain a few more things in a Windows environment - but the people who chose to use it over Linux already seem to be willing to spend the additional $'s for it anyway.

The current discussion centers around being hacked - and this can happen in Linux, Mac OS X, Windows, or practically any environment - whether you run virus scanners and do all the service packs/fixed or not.

Re:A simple disaster-mgmnt starrtegy...

[jkrise]

Your config files are scattered all over your system, and I'll bet you don't know where half of them are. Also, the file locations aren't portable knowledge: they vary from distro to distro, and between versions of the same distro.

as long as the config files are just files, not registry hive entries, it doesn't matter. A simple file backup from a floppy boot can handle config issues. Not so with Windows.

I use DriveImage, which has been 100% reliable for me ever since it came out, and it can image all of my operating systems. Making a bootable restore image is a piece of cake, and network restore is just as easy. Notice that the compression is also top notch.

If you're Win2K occupies 1gig on a 20gig partition, DriveImage is useless. You can't use it to create 2 bootable CDs that restore your system back with screen savers and settings. It's a piece of cake with Linux with just a floppy and no 3rd party code.

PS: you need a spell-checker, moron.

Actually, I'm using a new keyboard with the plastic wrapper still on. And you need a bit more tolerance, Mr.Touchy.
-

Re:A simple disaster-mgmnt starrtegy...

[Phekko]

It looks like you're writing something for Slashdot. Would you like me to add spelling errors for you?

Re:A simple disaster-mgmnt starrtegy...

[jkrise]

I don't think BackupMyPC offers a network backup solution. I remember numerous issues while using it with XP as well, besides problems with the boot floppies it generated..

I brought up this point to put in perspective some comments made in the article:
. As the machines were fairly uptodate with respect to security, an as-of-yet unknown local root exploit might be in the wild, so keep an eye on your boxen

IMO, we just need to keep an eye on our CDs, tape, disks etc. - not the box itself. Securing a box connected online is not a task for 99% of Slashdot readers, planning for disaster recovery is.

-

Re:A simple disaster-mgmnt starrtegy...

[Anonymous Coward]

As a professional programmer I have to laugh at this. I can't count the number of technologies I've learnt then forgotten and each time I've done it happily. This is the way our industry works - when something significantly better comes along, you move to it, work out how to support your legacy stuff and take advantage of the new abstraction and power of the next environment. Frankly, if I'm on the same learning curve in ten years as the one I'm on now, I'll be very dissappointed.

The moral of the story is that big changes come and static software goes. Linux will be no different. You have amply demonstrated how little you know about software.

Re:A simple disaster-mgmnt starrtegy...

[Anonymous Coward]

Since Linux has no use for hidden files, registry, active directory, complicated booting procecdures and other useless features that come standard with Windows

You haven't really been using linux in high end production facilities much, have you?
OK, so no hidden files, but registry? There are several different forms, they don't exactly match the win32 reg, but still (also, gconf..) Active Directory? That's just an LDAP rip-off. And more and more unix systems are using that for run-time critical information. Why? Because it makes really good sense. Complicated booting sequence? Yep, most unices have that. Naturally they also have the ability to fail gracefully and continue booting unassisted with minor failures, but wow, there are some instances when these systems really funk out. That's a universal thing, not just for Windows. If you run complex systems you get complicated booting sequences, simply because the dependancies and exception/error handling becomes complicated.

Useless features? Well, ok. Unix wins that round. You can pretty much strip a unix system down to the bare minimum of say 40 MB for a full system running apache in production (you can go further, I know - don't argue on this). I do that, but most systems I encounter come loaded with full development options and games. WTF? I'd rather have my systems running on win32 adminned by a comptent admin than on linux run by a lamer. OK, so I'd much, much, much prefer linux + competent admin.

Whatever.

*b*

Re:A simple disaster-mgmnt starrtegy...

[Anonymous Coward]

I'm in total agreement about the added hassle of Windows registries, active directories, and so forth. But your argument about backup/restore of data applies equally to *any* OS a person chooses to run on their PC!

Wrong! All of the equivalent in a *nix box is easily accessible, even on a currently running machine, and can be backed up by services running under the OS. You cannot say that about a Windows machine! It takes custom software from a third-party and I have yet to find a solution that works satisfactorily.

yet it's based on the fairly full-featured "Backup Exec" software that's been around and enhanced for years now, as it changed hands from Conner/Seagate to Veritas to ???. It makes a complete backup of the system registry with a single mouse-click in a check-box, and knows how to back up open files.

Notice, it takes non-Microsoft software to make this happen and it happens poorly. I use Backup Exec on the Windows server where I work and you cannot take the backup image and completely restore to a clean disk. Backup Exec's disaster recovery is a disaster. I've tried it, it dosen't work (reliably). The only way I've found to reliably backup a Windows system is to boot a third-party OS (I use a Linux boot CD) and image the entire NT boot partition.

It also cannot take our NT 4.0 backup and restore it to a win2k3 new install. I can (and do) backup data/applications on a Linux box, install a newer version of the OS and then restore the data/applications to get a fully functional new installation.

Even if Backup Exec did work (as I mentioned, I tried our disaster recovery under Backup Exec and could not get it to work) it will only work until MS releases the next round of patches or OS upgrade and changes the way they hide/obscure stuff to make sure that it doesn't backup anymore. It is in their interest to make sure that such things cannot happen under Windows because they are more conerned with piracy than they are my data!

Re:A simple disaster-mgmnt starrtegy...

[smcv]

Your config files are scattered all over your system, and I'll bet you don't know where half of them are.

On some older Linux systems with silly locations like /usr/local/etc, that might be true. On newer distributions that's just not true - they're in /etc.

According to the Filesystem Hierarchy Standard (which Linux distributions are converging towards), system-wide config files are required to go in /etc. In Debian, putting a file elsewhere when it should be in /etc is a bug; I seem to remember it counts as Serious, because it's a policy violation.

The converse is also true. If a file is in /etc but is not a configuration file, it shouldn't be there, although there are a couple of exceptions for historical or technical reasons[1].

To get users' personal config files (and documents) you also want a backup of /home, and you might also want to hang onto bits of /var (on a dpkg-based system, if you have a backup of /var, you have a complete list of installed packages, which is nice to have around).

---
[1] On my Debian system, /etc/rmt is a trivial shell-script wrapper for a program which was historically required to be in /etc (8 lines, of which 6 are an explanatory comment). /etc/mtab and /etc/ifupdown.state are variable state files which should probably be in /var, but need to be used early in the boot process before /var is guaranteed to be mounted.

Re:A simple disaster-mgmnt starrtegy...

[Anonymous Coward]

What a pathetic little ignorant zealot you are. Every time I think Slashdork has hit bottom, soneone like you comes around and surprises me. Mad propz to you sir!

Re:A simple disaster-mgmnt starrtegy...

[_Dante_]

what are the 'simple tools'? are they gpled?

SELinux

[Anonymous Coward]

SELinux would likely have prevented the root exploit from allowing this individual from doing as much harm as was done. I think that it's time for the big names like Debian, Slackware, Red Hat etc to start implementing it on their network connected machines. It's being incorporated into the stock kernel for a reason. Use it!

Re:SELinux

[placeclicker]

For some reason, i don't take closure that the NSA's version of Linux is going into stock kernels, even if it is open sourece :(

Re:SELinux

[Anonymous Coward]

SELinux would likely have prevented the root exploit from allowing this individual from doing as much harm as was done.

Assuming there are no bugs in the SELinux code, and that the system was configured correctly. (which is alot harder than it sounds)

I think that it's time for the big names like Debian, Slackware, Red Hat etc to start implementing it on their network connected machines.

Red Hat already employs a few people who are working on this stuff.

Re:SELinux

[TiggsPanther]

Okaaaaaaay. I'm sure I've now seen this exact same post at about 3 different points in this discussion. methinks someone is advertising...

Human Error or faulty security models?

[Anonymous Coward]

SELinux would likely have prevented the root exploit from allowing this individual from doing as much harm as was done.

I think that it's time for the big names like Debian, Slackware, Red Hat etc to start implementing it on their network connected machines. It's being incorporated into the stock kernel for a reason. Use it!

Re:Human Error or faulty security models?

[Coryoth]

2.6 does indeed have the LSM integrated in - that's step of abstraction up from the original SELinux. It is essentially a set of appropriate hooks into the kernel for running SELinux style security. There are actually other packages (LIDS for instance) that use this system.

The end result is: We will soon have a very strong security model built in to the standard stable kernel. The sad thing is that it will be off by default, and you will still need the set of userland tools that use it.

We have an excellent opportunity (with the 2.6 release) to seriously increase the security of Linux systems. People need to start promoting LSM modules and programs NOW so that we can get this to be the default state of most installed Linux boxes.

Jedidiah

Re:Human Error or faulty security models?

[Anonymous Coward]

The sad thing is that it will be off by default, and you will still need the set of userland tools that use it.

Maybe, but right now I think it's a good thing that it's off by default. It is a very complicated system and typical desktop users absolutely will not want to screw around with it.

Now maybe if it had really good admin tools and nice default install settings it might be OK to be enables by default. That isn't true today though.

Re:Human Error or faulty security models?

[evbergen]

Hi Russell, good to know you're still alive, well, and plugging SELinux as always ;-)

Ammended for the rest of us:

[Anonymous Coward]

Law #1: If Bill can persuade you to run his program on your computer, it's not your computer anymore.

The root of the problem

[Anonymous Coward]

The root of the problem is with the root account.

SELinux would likely have prevented the root exploit from allowing this individual from doing as much harm as was done.

I would think that it's time for the big players like Debian, Slackware, Red Hat etc to start implementing it on their network connected machines.

It's being incorporated into the stock kernel for a reason. Use it!

What could be done better...

[rxed]

Quote: "All the compromised machines were running recent kernels[1] and were
up-to-date with almost all security updates[2]."

Well, it seems that 'almost' just isn't good enough. Perhaps there is more to the break in (like unknown holes)?

Sniffing passwords? They must be using 'almost patched' version of SSHd.

Re:What could be done better...

[Anonymous Coward]

Or perhaps they just found a root password accidently typed into the bash-history of the unprivelleged account.

Re:What could be done better...

[agurkan]

Sniffing passwords? They must be using 'almost patched' version of SSHd.
not necessarily: you can connect to a machine on an unsecure channel, and from that machine use a secure channel to connect to your final destination. your password over secure channel can be sniffed by listening to the first channel.

Re:What could be done better...

[wichert]

The 'almost' is explained later on in the article. The one missing update was a postgres fix which could
never have been used to gain root privileges

Re:What could be done better...

[Anonymous Coward]

RTFA.

Re:What could be done better...

[PurpleWizard]

They could have ssh'd foolishly from some one elses account on an insecure machine that was already rooted with all ssh use being logged. From what I read earlier about suckit that would fit.

Goes to prove the security phrase "only as secure as the weakest link in the chain" if that did happen.

Openness is good

[iamdrscience]

I like how when debian's servers are cracked they tell you about it and furthermore, remind you again later with the details. If a similar thing happened with Microsoft it would be hushed down and certainly no details about it would be publicized later. Come to think of it, even a commercial Linux company like Red Hat might be weary in dealing with a similar issue as well -- I think they'd be likely to be open about it, but you never know what's going to happen when money and stock prices are involved.

a sticky situation

[gearheadsmp]

As a matter of fact, Monica Lewinski gave some teenager who lives in his parent's basement oral sex to write the rootkit. It wasn't that hard - Monica showed up wearing a poncho to shield herself from the shower of "milk", and then the script kidde saw the Saturday Night Live rerun on Comedy Central, in which Bill Clinton announces the end of his legacy, says "Suck it! Suck on it!", and Dubya shows up and brags about how he bought a Big Mouth Billy Bass for $1,000. Hence, the name. Now as to how the script kidde got mad at the Debian project, well, I'll leave that to the Gentoo Zealots.

Unknown Debian exploit?

[t0ny]

Im sure glad my network runs on Windows!

Re:Unknown Debian exploit?

[flacco]

Im sure glad my network runs on Windows!

hey it is pretty nice - i'm having a look around right now!

Re:Unknown Debian exploit?

[tiger99]

Good idea, then the hackers don't have to waste so much of their precious time getting in...

Remember what Gartner said about IIS?

oh, you didn't know

[b17bmbr]

clearly this is the work of a DX fan. (wwf reference)

local root == remote root

[Markus Registrada]

This is a good demonstration that the distinction always made between local privilege-elevation bugs and remote exploits is academic hair-splitting. It's rarely difficult to get unprivileged access through a buggy non-privileged service. (Web-server plug-ins are a reliable source of entry points.) Once you're in, privilege elevation takes you the rest of the way.

Certainly the distinction is useful to security students and analysts, but it's misleading for everybody else. "Oh, that one's just a local exploit; not so bad." The OpenBSD advocates promote the fallacy: "only one remote exploit in this millennium!" (or something like that), encouraging us to ignore almost equally damaging exploits in non-core services that provide access to local accounts and more damaging attacks.

There's a similar fallacy in distinguishing security holes from other bugs. Without a depth of analysis that hardly anybody can ever afford, almost any bug might actually be a security hole, too. The OpenBSD people get this one right -- to them, any bug is a security hole until proven otherwise, and they encourage running latest versions -- but almost everybody else gets it wrong. When I fixed a double-free segfault in lib[mumble], nobody posted security warnings about every program that relies on it. despite that double-free bugs can often be exploited.

Debian gets this wrong, and very selectively backports only proven security holes, ignoring the myriad bugfixes that might just as easily be security holes as well. To find holes in stable-branch services, just look for bug fixes in later versions, particularly in libraries used by those services. Failing that, look at new features added shortly before the library-version used. Chances are the last new feature added has bugs that haven't been noted yet, and that might be exploitable.

This might be a good place to mention that the CVS codebase is almost irreparably insecure. The practical implications are: (1) A remotely-accessible CVS server should never be run on a host that does anything else that matters, or that has access to anything else; (2) An anonymous CVS server should never be the same CVS server that is used for checkins, or even run on the same machine. The pserver should be a slave that only gets read access to a copy of the archive. (3) Checkins on remotely-accessible servers should result in patches logged to another archive kept on another, not-remotely-accessible machine. Patches from that server should be posted to the mailing list.

Re:local root == remote root

[Anonymous Coward]

> This is a good demonstration that the distinction always made between local privilege-elevation bugs and remote exploits is academic hair-splitting. It's rarely difficult to get unprivileged access through a buggy non-privileged service. (Web-server plug-ins are a reliable source of entry points.) Once you're in, privilege elevation takes you the rest of the way.

If you can remotely gain root without the use of a local user account, it's a remote exploit. The truth is that you shouldn't really inately trust any service just because it isn't being run as root (not that that's very common, anyways). With something like freebsd root-jails, it'd require a kernel exploit to even begin to gain any level of access to a regular account let alone something like root.

I don't think anything short of a very simple containment mechanism will provide any real guarantee against remote exploits. And the same mechanism can be used to contain each local account. Unfortunately, I've never seen anything approaching protection at that level. In the end, though, you can't protect everything without proper coding.

Even if you can't exploit a service to do your bidding, you might be able to crash it. In some circumstances, that's just as bad since the service is important. Just as simply gaining access to a local account can wipe out a person's important information which even if that's the only effect is a bad thing.

In any event, claiming local and remote exploits are the same is misguided. Remote exploits can be prevented by not running services. Local exploits can't normally be fixed without changing the kernel..and even then if there's a local user, they probably can physically alter the machine to allow them root access. It is, however, at least a useful barrier to entry to require a person actually be at the console (or have an account) before they can gain root access. Then you can begin to track down the blame (did they giving out passwords, any brute force attack which might hint at the perp, etc). Remote exploits mean near instant spreading making detection a lot harder.

Re:local root == remote root

[maximilln]

-----
The OpenBSD people get this one right -- to them, any bug is a security hole until proven otherwise, and they encourage running latest versions -- but almost everybody else gets it wrong.
-----

I'm glad to see at least a few other people take the security business as seriously as I do. With so many programs running next to each other in memory space and so many idiosyncracies in any kernel it's nothing short of ignorance to think that even the smallest bug could eventually be combined with several other bugs to make a security hole.

It's a really good pinball machine. This enables that which activates those which lets this ramp down so that the ball can go there and, before you know it, BINGO. We have root access (or a free ball).

A quick question...

[kinema]

Just out of curriousity, how much logging data would servers like the ones in question produce per day/week/month? It's got to be quite a bit with all the various packages like an httpd, ftpd, MTA and all the typical syslog data.

first post!!!

[Anonymous Coward]

1VIRII VIRII2 3VIRII VIRII4 5VIRII VIRII6 1VIRII VIRII2 3VIRII VIRII4 5VIRII VIRII6 1VIRII VIRII2 3VIRII VIRII4 5VIRII VIRII6

WWWWWaWWWWWWWWWWWWWWWWzWWWWWWWWWWWWWWWWWWWWWWWWWWW WWWWWWWWWasdjklcvz

WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW WWWWWWWWWewquiyrwq WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW WWWWWWWWWxzxzbvxcmn

jigger my nigger

local root != remote root

[placeclicker]

Huge diffrence.

You still need a local account to make use of a local root exploit.

You don't for remote root exploits.

Remote root exploits can be used in worms, local (for the most part) cannot.

Not to say that local root exploits should be overlooked, especially when they seem realtivly simple to create (e.g., bad symlinks)

Besides, this is supposedly an *UNKNOWN* local root exploit..

Re:local root != remote root

[pikkumyy]

You're missing parent's point entirely. Local exploit becomes a remote exploit becouse of user stupidity. You can't trust your users to keep their accounts safe.

Re:local root != remote root

[bug-eyed monster]

Example: These days, a common MS worm is spread through email attachments. Linux proponents point out that, even if such a worm was designed for Linux, the attachment would be executed by an unpriviledged user. With local root exploits, this argument becomes irrelevant, because if there are local root exploits, every user is effectively root.

Re:local root != remote root

[Anonymous Coward]

Well done, you just missed the entire point of the parent post. Allow me to refresh you:

" This is a good demonstration that the distinction always made between local privilege-elevation bugs and remote exploits is academic hair-splitting. It's rarely difficult to get unprivileged access through a buggy non-privileged service. (Web-server plug-ins are a reliable source of entry points.) Once you're in, privilege elevation takes you the rest of the way."

If you want that another way - local root exploits are not difficult to exploit, as getting a local (unpriv) account is not difficult to acquire.

As for your point about worms - it's just plain wrong.

http://www.cert.org/advisories/CA-2002-27.html

Note from the text in the above link:

"II. Impact

Compromise by the Apache/mod_ssl worm indicates that a remote attacker can execute arbitrary code as the apache user on the victim system. It may be possible for an attacker to subsequently leverage a local privilege escalation exploit in order to gain root access to the victim system."

This worm was not a remote root exploit, it ran and spread as just the apache user. It would then be trivial for the worm payload to run a local root exploit on the infected machine.

Already!

[Anonymous Coward]

This was already posted here...

Of course there are unknown exploits

[Animats]

The serious attackers don't publicize the ones they develop. They save them for use on worthwhile targets.

This is why security by patching is fundamentally ineffective against enemies, as opposed to nusances.

Re:Of course there are unknown exploits

[placeclicker]

Which is why, thank God, there has never been a worm written by a real cracker. It's all been from good old Windows documented exploits.

Re:Of course there are unknown exploits

[ReTay]

How about making that relying only on security patching?
We have all complained about users not patching their windows boxes enough so I would say that patching is mandatory. Of course relying on only one security forum is begging for problems no matter what it is. Only layering the defenses on do you really have a good chance of stopping an attacker or at least knowing how he got in. As long as we are talking about security here does anyone have a favorite remote logging software? It seems that this is gettting more important lately..

Re:Of course there are unknown exploits

[Anonymous Coward]

Which is why, thank God, there has never been a worm written by a real cracker. It's all been from good old Windows documented exploits.

What, like the Morris internet worm of 1988 that shut down much of the internet?

Sad day for Debian

[swordsaintzero]

As long as a machine is connected to the internet there is going to be a method to compromise it. My question is this why Debian? They are the only Linux distribution that is truly built by volunteers to gain any mindshare of real note. (not sure about slack so please dont sick bob dobs on me) This is not imhop the work of rank amatuer crackers with there first root kit. These were servers being run by experienced admins using a distro known for stability which when patched and up to date usually means somewhat difficult to hack. I seriously doubt these guys were running winders attempting this either. Wtf is happening to the community when people with talent are attacking a distro that yet again imhop doesnt suck. These guys need to be found and buried. Not by the police but by the commmunity. Last but not least (places tinfoil hat on head) could this have been funded by M$ trying to discredit linux. I cant see the glory angle so its got to be money or power. (no glory in getting called a dick when you tell your friends what you did)

Re:Sad day for Debian

[trick-knee]

> Wtf is happening to the community when people with talent are attacking
> a distro that yet again imhop doesnt suck. These guys need to be found and
> buried. Not by the police but by the commmunity.

hear, hear.

it's not a sad day for Debian so much as it is for the community. if Debian can find this supposed new exploit, fix it and publish details, then Debian will rise a little higher in people's esteem.

but why crack Debian in the first place? here I am stumped, but then I've never fully understood the cracker mentality.

Re:Sad day for Debian

[Anonymous Coward]

I agree. Why didn't they go after the Gentoo servers? Everyone hates their userbase anyway because of the immaturity and extreme zealotism.

Re:Sad day for Debian

[Anonymous Coward]

My money is on that they were Gentoo users trying to destroy the competition. Fucking immature little Gentoy faggots will never learn and their distro will wither and die.

Re:Sad day for Debian

[Anonymous Coward]

So it's ok to attack things you consider immoral but not to consider things you consider moral.

I'll pass that on to the people who shoot abortion clinic doctors and crash passenger jets into tall buildings containing civilians.

Re:Sad day for Debian

[Anonymous Coward]

Blaiming debian crack on M$ tactics = paranoid.
Blaiming Linux kernel CVS hack on M$ = paranoid.
Blaiming SCO shenanigans on M$ = paranoid.

Put the three together and maybe we shouldn't think it's paranoia, after all, who has the most to gain by discrediting Linux?

Re:Sad day for Debian

[Anonymous Coward]

When you're looking for a maximum of boxes to be exploited, you don't embarass yourself with such scruples. Do you think that Spamhaus.org mass DDOSers have any scruples to begin with ??

Re:Sad day for Debian

[TiggsPanther]

That does raise an intriguing point.

On their own, any one of those does jusr sound like anti-MS zealotry or paranoia. But with all three happening fairly close together, it means one of three things...

[1] Extreme paranoia.
[2] An extremely large coincidence.

And, seeing that paranoia can sometimes be justified, apparent "coincidences" often aren't...

[3] it's a valid path of speculation.

Actually, if it wasn't for the SCO situation, two major hack attempts could just be an attack on Open-Source by peoples unknown, or a deliberate attempt by crackers/virus-writers/spammers to get more vulnerabilities out there for them to use.
The SCO involvement makes this a tad less likely. I get the feeling that SCO wouldn't do something that spamemrs would put them up to.

Maybe it is all just coincidence. But it's a bloody big one, ne?

Tiggs

Re:Sad day for Debian

[Anonymous Coward]

but why crack Debian in the first place? here I am stumped, but then I've never fully understood the cracker mentality.

I think it is just part of something bigger. There have been more cracking incidents regarding Free Software.

Somebody tried to insert a backdoor on Linux recently and the GNU repository was attacked too. IMHO, whoever did this was trying to get a backdoor on debian (just in case this exploit is closed, or maybe a more powerful/remote or subtler one) or at least waiting for an oportunity to do so without being detected. I wouldn't be surprised if this local root exploit happened to be used to gain access to the kernel.org repositories.

By inserting one hole in only one piece of software (linux, debian installer, init, etc) it would be possible to 0wn a BIG amount of machines. It makes perfect sense to me.

Re:Sad day for Debian

[Anonymous Coward]

Did they even know they'd compromised the Debian boxes? Might just be some script kiddie who just viewed it all as just YACB (Yet Another Cracked Box).

Even so, though, the incident has to be treaded as if a Columbian drug cartel working in cooperation with the Russian Mob was responsible. Probably more than a few credit card numbers to be found by running similar exploits on e-commerce boxes.

Re:Sad day for Debian

[Anonymous Coward]

swordsaintzero wrote:
>
> no glory in getting called a dick when you tell your friends what you did

The underlying assumptions here are that no cracker could possibly be a dick that would get off on such a deed, and that his buddies can't be just the sort of dicks that would applaud him.

You probably think crackers are stylish Outlaws of the Electronic Frontier fighting the good fight against Corporate Power and sticking it to the Man. They can't be dicks. That would be against the Hacker Ethic!

Re:Sad day for Debian

[solattam]

but why crack Debian in the first place? here I am stumped, but then I've never fully understood the cracker mentality.

Keep it simple. Debian has enemies. That's really the only worthwhile point of all this. I know that the Debian folks are a happy bunch, but is this point so hard to understand?

Re:Sad day for Debian

[Anonymous Coward]

Oooh... there's more...

We can blaim Novel buying Suse to kill KDE on M$.
We can blaim Redhat bailing on the desktop on M$.

This is fun.

ldap?

[rsax]

Obviously we can't continue without LDAP accounts for very long either.

Can someone who's familiar with system administration on those debian boxes clarify the above statement? Have they disabled LDAP accounts or was it implied that they're going to set up authentication with a ldap backend in the future. If it's the latter then I'm curious as to how having ldap in the equation would have made cracking those system accounts harder.

Re:ldap?

[Anonymous Coward]

The accounts are stored in LDAP tree at db.debian.org[1]. However, when the compromise was noticed, all accounts are locked down, and they still are. Which is very very bad with regard to the continous developement of the Debian distribution, as I and all other developers can't log in to the developement machines, package uploads aren't being processed, many crucial internal services (such as testing propagation) are down.

That's what he meant by his comment - the Debian Project is effectively halted by this - and obviously that can't go on for long.

[1] You can obtain a listing of these by running the command ldapsearch -h db.debian.org -x -b dc=debian,dc=org '(objectClass=debiandeveloper)' from a internet-connected host.

Re:ldap?

[chrisbtoo]

Can someone who's familiar with system administration on those debian boxes clarify the above statement?

Not me, sadly, but when I saw LDAP, I was reminded of the recent Mac OS X vuln. I know the details are different, but reading the linked article led me to think LDAP's not necessarily a good way to manage your priviliged accounts.

Re:ldap?

[clacke]

I interpreted it this way:

Local admins have shadow passwords (or something), "debian accounts" are on LDAP. For now, the LDAP backend is disabled because it's uncertain whether some of those accounts are compromised. The statement simply means they can't continue shutting out developers for very long.

Re:ldap?

[Anonymous Coward]

Probably because LDAP would be handled and accounts logged on a completely different machine unaccesable from the internet. Or something like that.

More secure logging and passwords.

Re:ldap?

[Anonymous Coward]

LDAP = Large Deposit Absolute Priority.
Explaination: The hacker is watching. Pay him off. Now. Ask him to reproduce the break-in as part of the pay-off. That's the solution.

Awesome cartoon about this

[Anonymous Coward]

Find it at klerk.ru here.

Classic!

MOD PARENT DOWN - GOATSE

[Anonymous Coward]

check link, its got goatse redirect.

Nice try though, but i always check full links.

Debian.org Security Breach

[t0ny]

Makes me glad my network is running Windows!

HTML Exploit on Debian

[Anonymous Coward]

More information here.

seems like a good time

[Profe55or Booty]

seems like a good time to plug my completely pointless and unrelated website: www.isuckit.com (no it's not porn)

More info at secforum.com

[Anonymous Coward]

More information on the exploit, plus exploit code.

Yes, Mr Stallman... we don't need "wheel"

[Anonymous Coward]

No further comment.

Antifeminists hate Debian

[Anonymous Coward]

Ever read what they have been saying about security?

Security breach?

[Anonymous Coward]

This site has more useful information that Slashdot.

--Tim

SuckIt Exploit

[Elik]

I have dealt with this rootkit for nearly 4 months when it first appeared. The fairly safe methods for avoiding this is by 3 steps which I have used and it works well since then.

Move the /tmp to it own partition and set it as noexec, nosuid and give it plenty of space, around 200 to 500 megs for it.

Patch the kernel with either Grsecurity or Openwall Patch on 2.4.22 kernel and set it as mononthlic kernel, not modular with no open hooks for adding additional modules.

Then I installed the suphp module for PHP to run scripts as users instead of nobody, especially when people trying to exploit it. I get it at www.suphp.org and it works extremely well. Since the changes, I haven't seen any rootkits being successfully implemented on the servers I admin. And note the fact that I manages over 260 servers for various clients points to the track records.

Re:SuckIt Exploit

[Penguinshit]

I'd like to second the notion regarding running closed monolithic kernels on machines about which you care at all about security. It is, IMHO, one way (of many) to avoid trouble such as this.

That one little trick alone once saved me from some fuckwit's shenanigan attempt.

Re:SuckIt Exploit

[Talence]

I use a monolithic kernel on one of of my servers too after it got cracked 1.5 years ago. I also try to minimize the number of users on my machine and additionally, use the /etc/hosts.deny and /etc/hosts.allow files to really restrict where people can login from.

My precautions did not, however, stop a cracker from using my friend's account by logging in from his own (cracked/sniffed) machine. Fortunately, the person was entirely unable to gain root access and all I had to do was to kill the bot he had running on my machine.

Re:SuckIt Exploit

[Anonymous Coward]

>/tmp to it own partition and set it as noexec, nosuid and give it plenty of space /lib/ld-linux.so.* /tmp/rootkit

It works on most distributions. (In Debian, /tmp -o noexec does little more than break preinstallation scripts for packages.)
Discussion on Debian Mailing List of ld-linux.so.

Re:SuckIt Exploit

[Anonymous Coward]

There was a well known way to load modules into a monolithic Linux kernel. I don't know if it's been fixed, but it was not considered a serious bug by the Linux developers.

In short, monolithic kernels may help you security-wise, but it's not designed to be a security feature.

Re:SuckIt Exploit

[RustyTaco]

It works on most distributions. (In Debian, /tmp -o noexec does little more than break preinstallation scripts for packages.)

What packages try to exec something from /tmp, and have bugs been filed already? pre/post script are in /var/lib/dpkg/info/, anything in /tmp must by autogenerated for some silly reason.

- RustyTaco

What's up with these anti-Linux attacks?

[PurpleFloyd]

To me, this attack and the recent attempt to insert an exploit into the Linux kernel seem like possible evidence of a disturbing trend: skilled attacks against high-profile Linux sites (you can't get much higher-profile than kernel.org or debian.org). I'm pretty sure that these systems were secured against all known local root exploits; if they weren't, this probably would have happened long ago.

So, what's going on here? Are these simply two unrelated attacks? Is it an attempt by an immature highschooler with some cracking talent to boast to his friends "LOL 1 hax0rred debian.org!?" Is it an attempt by some sort of anti-Linux commandoes to undermine Linux's public image? I almost suspect the latter, but the prime suspect there is Microsoft, who have far too much to lose by going that route and plenty of money for traditional FUD that will make it into "traditional" news channels better anyway. SCO might be crazy enough to do it, but they probably wouldn't want to divert resources away from spewing lawsuits at everyone in existence.

From what I understand of the cracker community, Linux is held in fairly high regard (although I admit I don't try to keep up on the latest in the cracker community). You'd think that black-hats, who tend to be rather immature, when armed with a brand new exploit, would attack a site seen by the general public and post goatse.cx images on the front page, rather than subtly changing Debian packages. So, who's behind all this?

Re:What's up with these anti-Linux attacks?

[sqrt529]

It was bitkeepers cvs, not kernel.org which was compromised.

Re:What's up with these anti-Linux attacks?

[Anonymous Coward]

Guess what? People are assholes. There are plenty of people in the world who want to make a quick buck or have a laugh at someone else's expense. They don't give a fuck about open source moral high-ground, they don't give a fuck about Microsoft's hegemony, they don't give a fuck about you. They want to break your shit, take your identity, steal your money and send kiddie porn spam from your box.

Wake up. Linux has become more popular, more mainstream and there is much to be gained by owning your boxes. The most surprising thing about all this is that people are surprised it's happening. It sure was nice when Microsoft was the only target in the world but times have changed. It's time to grow up and realize that this is everyone's problem.

Re:What's up with these anti-Linux attacks?

[bonch]

Jeesh. Slashdotters amaze me sometimes.

Did it ever occur to you that someone might want to hack a high-profile Linux site...I don't know, for the same reasons they hack any other sites?

Re:What's up with these anti-Linux attacks?

[segment]

I'm pretty sure that these systems were secured against all known local root exploits; if they weren't, this probably would have happened long ago.

Apparently not so secure they were now were they.

So, what's going on here? Are these simply two unrelated attacks? Is it an attempt by an immature highschooler with some cracking talent to boast to his friends "LOL 1 hax0rred debian.org!?" Is it an attempt by some sort of anti-Linux commandoes to undermine Linux's public image? I almost suspect the latter, but the prime suspect there is Microsoft, who have far too much to lose by going that route and plenty of money for traditional FUD that will make it into "traditional" news channels better anyway. SCO might be crazy enough to do it, but they probably wouldn't want to divert resources away from spewing lawsuits at everyone in existence.

This is the most far out shit I've seen to date and it's sickening to think someone took this bullshit and mod'ed this trollish "Bill Gates hates Linux so much he gcc -o vixie vixie.c ; ./vixie'd kernel dot org" ... Pitiful

From what I understand of the cracker community, Linux is held in fairly high regard (although I admit I don't try to keep up on the latest in the cracker community).

FYI if you took some vitamin clue you would know Linux is not that far behind MS on security exploits. Now now now, before the Linux zealots bash get real and look it up. Linux is the second most attacked machine, now you're going to say because it's what the second highest used OS? Let's see, I have about 200k visitors for the month on one of my sites, first place for OS visits MS, second.. OSX you see what I typed there, followed by Linux, sure content wise would make the diff if you want to go there, but you'd be looking for an excuse to justify the shoddy security put into Linux.

Now I won't go into the BSD's, because I just won't nor will I go into Solaris, but do your homework, Linux `used to be` all that, nowadays I look at it as LiNuX vErSiOn v.666... A toy nothing more and don't even use it anymore, nor will I advocate it. It went from something cool into the new MS'like farce

You'd think that black-hats, who tend to be rather immature, when armed with a brand new exploit, would attack a site seen by the general public and post goatse.cx images on the front page, rather than subtly changing Debian packages.

You think about this instead of your lame MS conspiracy theory... If you're an attacker, and wanted to make a name for yourself, you would probably target a heavy site, an entire operating system spread throughout the world, and you would be an underground legend.

A criminal looking for a backdoor worldwide, and you would be rich. The possibilities are endless. Do you think that a man with so much to lose by committing such an asinine crime as the one you mentioned would stoop so low? You must be smoking oxy with Rush.

So, who's behind all this?

Better call my lawyer again before I get blamed for this shit too

Re:What's up with these anti-Linux attacks?

[marcello_dl]

The timing of the attack (just before the release of 3.0r2 and almost coincidental with the discovery of an OSX remote vulnerability) is interesting, too.

A resourceful black-hat hacker hitting debian just to boast "its" ego would have probably "signed" the attack somehow. On the other side, if i were trying to spread FUD about Linux with an attack, i'd do the same: pretending that a single immature highschooler could hax0r Debian would add insult to damage and hide the real motive.

Re:What's up with these anti-Linux attacks?

[Ogerman]

FYI if you took some vitamin clue you would know Linux is not that far behind MS on security exploits. Now now now, before the Linux zealots bash get real and look it up. Linux is the second most attacked machine ... but you'd be looking for an excuse to justify the shoddy security put into Linux.

FYI, this has nothing to do with "shoddy security put into Linux". Fact is, a properly secured Linux server is overall more secure than a properly secured Windows server. The problem is that most *distros* (and yes, this includes Debian) have fairly shoddy security by default. Then you have a lot of people who don't know what they're doing trying to use these distros to run real-world sites. Therefore, they are an easy target. (and generally more "interesting" to crackers.. what fun/glory is a compromised Windows box?) From the explanation given, it does not sound like the Debian admins had enough security experience (or paranoia :). You simply DO NOT run a high-profile site without an ACL-protected kernel (ie. LIDS, SELinux, etc.) This is not because Linux itself cannot be trusted, but because some of your services may not be. Even better is to also use kernel stack protection. But anyhow, the Debian admins will learn from their mistakes and the project will be stronger as a result.

now I won't go into the BSD's, because I just won't nor will I go into Solaris, but do your homework, Linux `used to be` all that, nowadays I look at it as LiNuX vErSiOn v.666... A toy nothing more and don't even use it anymore, nor will I advocate it. It went from something cool into the new MS'like farce

Now you're really blowing a lot of random hot air. Either you're a silly troll or you're one of those trendy anti-trend folks who thinks anything popular can't be cool/good. I guess IBM has decided to refocus its corporate vision around selling toys, eh? Riiight..

Re:What's up with these anti-Linux attacks?

[EnglishTim]

I assumed it was someone who wanted to put some backdoors in so that she could then either:

a) root some debian servers for their own nefarious pleasure and purposes

or

b) try and get some backdoors in to make a vector for a new virus.

Re:What's up with these anti-Linux attacks?

[jpop32]

On the other side, if i were trying to spread FUD about Linux with an attack, i'd do the same: pretending that a single immature highschooler could hax0r Debian would add insult to damage and hide the real motive.

Sir, you forgot to name of the conspirators. Who is it? SCO or MS? Inquiring minds want to know!

Re:What's up with these anti-Linux attacks?

[mbanck]

The timing of the attack (just before the release of 3.0r2)

Joey sent several "preperation of 3.0r2"-mails during the last six months. Things seemed to get a bit more relevent lately, but at least I did not expect an immediate release. And anyway, 3.0r2 ist just a comulative security patch, mostly. Everybody should already have most of the modified packages installed via security.debian.org.

I don't believe the release of 3.0r2 has anything to do with the timing of the attack.

Michael

Re:What's up with these anti-Linux attacks?

[yeschat]

Whoa, just because a linux server or two got hacked, it's Microsoft's or SCO's fault? So when a IIS server is broken into, does that mean Debian is behind it?

I think you are worried a bit much :)

Re:What's up with these anti-Linux attacks?

[marcello_dl]

Sir, you forgot to name of the conspirators. Who is it? SCO or MS?

If you didn't mean an XOR the answer is true.

Inquiring minds want to know!

So, the tinfoil hat works!? Great!

Seriously, I just pointed out things i find interesting, while waiting for some more detail.

Re:What's up with these anti-Linux attacks?

[Anonymous Coward]

You simply DO NOT run a high-profile site without an ACL-protected kernel (ie. LIDS, SELinux, etc.)

OK, so what you're saying is that all of the commercial Linux distros (and Debian) are unfit to run a "high-profile site", right? That people dump RH-SuSe-Mandrake-Debian-Gentoo and go with a half-baked experimental kernel release?

Wow, if that's not supremely weird I don't know what is. I tend to chuckle at the "insight" posted around here but your little piece of work definitely takes the cake.

BTW, since we're on a roll here I'd like to bring up the fact that Windows NT is an ACL-protected kernel. Maybe that's also an option?

Oh, and BTW, people who say things you disagree with are not by definition "trolls". Not any more than you, anyway. According to slashdork standards you are a troll since you just ruled out Linux as a secure server solution.

Re:What's up with these anti-Linux attacks?

[PurpleFloyd]

First, all a site like debian.org can do against attackers is secure against all known attacks. While going through kernel code line-by-line and looking for subtle vulnerabilities is a good idea, it would take up so many resources that it's not feasible for anyone but a major company or government who doesn't plan on changing kernels for a while anyway. While the security obviously isn't perfect (if it were, the attacker wouldn't ever have compromised a low-level account), one can assume that the security is good against known exploits, as we aren't presented with gaping anii weekly on debian.org visits, courtesy of whatever script kiddies r00ted the box last.

As for the "Far out shit," I was simply trying to pre-empt the inevitable "Microsoft did it!!!" and "SCO hates Linux, they did it!" responses. While both might have something to gain by attacking Linux's credibility, I pointed out that both would lose more than they gained, and thus it's not likely that they did this. I strongly doubt that some sort of anti-Linux conspiracy exists. I simply brought it up as one (remote) possibility.

Finally, to respond to your accusations against Linux's security - Linux itself has quite good security, particularly if it's used with something like the SELinux patches. Hell, Windows' security isn't that bad either, if you only consider the number of core system exploits - of course, the length of time from when a vulnerability is discovered to when a patch is issued is quite long, bringing its security level down quite a bit. Linus and his kernel hackers are not responsible for insecure defaults in many Linux distributions, and neither MS nor Linus are responsible for sysadmins clueless enough to leave the defaults in place. Remember, the burden of security rests at least as much on the sysadmin's shoulders as on the designer's.

Teminator

[gmby]

SkyNet - the userless system. Self cleanning user base. No passwords needed. "cut out" he he.....

I just can't wait...

[TheDarkener]

Until the next announcement comes out, further explaining the possible motives and more on how they exploited the system from an unprivileged account.

This is like a soap opera!! =)

P.S. I don't like soap operas, but if they had one about this, I might just have to quit my day job.

Hi

[Anonymous Coward]

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfhdfh1dasdih8yh1niu9n987hgggggga 1hb9uhb9dfdfhhb981dasdh8998h

1dasdsadassdgggkjkiggh1uhiuhiu1808h1uffasiuhidasda sdgfhsdasdas1dasddfh

Hey

[Anonymous Coward]

You all are homos!

[ Reply to This ]

• Re: No!!

Screw your filters.. Slut.

how to break that law and get away with it

[alizard]

My Windoze drive has a mirrored drive on a mobile rack which is only plugged in during backups.

You can figure out for yourself what I do if C: gets hosed. Hint: getting back to pre-disaster condition is just time-consuming.

I will say that getting back to pre-disaster condition from backup tape a few years back was an. . . adventure.

phrase password

[gearheadsmp]

I use phrase passwords. Pick two or three words. Add a symbol in there or two, and bam! secure password. Like 'bat.fart!smith?'

Re:phrase password

[Fjord]

I hope you're joking. This is exactly the kind of password crack is able to find very quickly.

Debian physical site security?

[identity0]

Okay, I read the article and it said that at least one machine was at a remote location that couldn't be accessed - can anyone tell me what kind of physical setup debian project uses? I always get the impression that they're based out of some dude's dorm or basement, like in this OpenBSD image. Do they have any physical security measures at all around their boxes?

Re:Debian physical site security?

[amck]

The primary Debian machines are in colo facilities
in the US and Netherlands (there are buildd machines available to debian developers in various locations). The machines are beefy enough - HP
recently donated a server with 48 GB RAM, for example. I believe the bandwidth out of ftp.debian.org is Gigabit ethernet (and having only that to the mirrors will be a bottleneck
when sarge is released!)

So, no, they're not in some dudes basement; we have good facilities courtesy of our sponsors.

- Alastair

Re:Debian physical site security?

[wichert]

Most machines are in colocation facilities and all the normal colo access rules apply to them. That is why I could immediately get to klecker physically (luckily its colo is moving to a new site and we'll get our own access pass for the colo). The only machines that are in locations like peoples homes or dorms are those for which regular physical access is required, for example to experiment with new (or old) architectures.

Um, what?

[bonch]

They said the password was sniffed.

Try to shunt this off to a "weak password" all you want, but let's face facts here. A beloved Linux network was clobbered.

Yes, Virgina, Linux is not invincible. You have rootkits and exploits too. Just see Linuxsecurity sometime.

And, yes, it makes all the Linux loonies who rail on about Microsoft insecurities look like religious hypocrites.

Karma Bonus unchecked, because I don't expect this to be well-received by biased moderators.

Re:Um, what?

[Yottabyte84]

My box was 0wned a while ago. They got my password when I ssh'd out from a shell account on a compromized machine (that'll teach me to trust other admins) and got root by using 'sudo bash --login' and entering my password. They installed suckit, and then started scping something from somewhere while I was logged in to X. I noticed, and promptly powered off my DSL modem, and got to work cleaning up.

Re:Um, what?

[TiggsPanther]

"Linux is not invincible."

No shit, sherlock.

It's not a difference between "Windows shoddy, Linux inherantly stable" - as all programs have potentionals for flaws and stuff.
The difference is how these flaws are treated by Windows compared to Linux.

I'm not the most security savvy geek here on /. - far from it. but even I know how to lock down my Linux box to be reasonable certain that it won't get compromised. But I also know that there's still the possibility of it happenning. but i also know what to look for, and where to check for workaround/patches/fixes.
I can't say the same about Windows. (There's a reason my Win2K box is inside the Firewall, and my Linux box is running the Firewall)

Plus on the whole development side, I'm pertty certain that teh varios Linux devs don't swear blind that their Distro is the most security-conscious one around. Linux zealots might be a different matter, but the devs don't.
Microsoft tends to get hit by exploit after virus after "patch which fixes the exploit but knackers the OS". And they still try to tell us that they're the most secure system going.

Debian seem to have handled themselves very well in this situation. They're not saying "we're still safe", rather they're going "We got compromised. Here's what we're doing abouit it, here's what we're asking other devs to do about it."
And as they think that it's due to an as-yet-unknown root exploit they're telling people to keep a look out. And they're also revealing exactly how they think they were compromised, along with how they noticed.

And I guess the most important thing is that it does remind us that Linux isn't invulnerable. We're so used to hearing about MS-related problems, we don't always notice the Linux ones. But this tells us all to be a little more vigilant.

Tiggs

So much for unbiased Slashdot

[bonch]

Look at all the posts...excuses and rationalizations. "Well, this serves as an example of weak passwords" or "non-root privileges," etc.

You never see that level of rational explanation when it comes to a user-transmitted e-mail Outlook worm. In fact, in those cases it magically becomes a "Microsoft hole," even though it's users running the executable!

I know this won't be well-recevied, so Karma Bonus is unchecked accordingly. Nonetheless, it's my opinion and I believe it. Slashdotters are hypocrites and hold double-standards.

Re:So much for unbiased Slashdot

[ishark]

Look at all the posts...excuses and rationalizations. "Well, this serves as an example of weak passwords" or "non-root privileges," etc.

Actually, what I see is people warning of a possible security hole in the wild.

You never see that level of rational explanation when it comes to a user-transmitted e-mail Outlook worm. In fact, in those cases it magically becomes a "Microsoft hole," even though it's users running the executable!

This is because one of the "strong" points which is claimed by windows is that it's designed to be used by non-tech experts, while at the same time it offers NO protection from mistakes. If outlook were modified so that it cannot execute anything and you must manually save to disk and execute whatever you would see (beside a drop in virus infections) fingers pointed at the users instead of Microsoft.

Re:So much for unbiased Slashdot

[Yottabyte84]

Whenever I get an email worm these days, I think to my self "What kind of moron would open this". The morons that keep doing this should be banned from the internet.

Re:So much for unbiased Slashdot

[Alioth]

Slashdot is NOT supposed to be unbiased. It's called /. for heaven's sake - if it was a Microsoft oriented site it would be \. (backslashdot.org)

Re:So much for unbiased Slashdot

[Anonymous Coward]

Microsoft designed Outlook to have scripting and its related insecurities. In comparison, weak passwords are very easily taken out by things like cracklib.

In the first case, Microsoft designed something to be insecure, in the latter case, the system can be made more secure.

Now, if a Microsoft system were compromised because of weak passwords, I would agree with you, but the very design of Outlook is designed to encourage these sort of mistakes.

Re:So much for unbiased Slashdot

[lgftsa]

Sloshdot

Re:So much for unbiased Slashdot

[jadavis]

Slashdotters are hypocrites and hold double-standards.

You're saying slashdot posters are inconsistant, but they're just different people who all happen to read slashdot. If you want to make a real argument, pick one person and attack their inconsistancies.

Another example is the political parties. You can't say that Democrats are inconsistant because of this, that, and the other. Democrats are a varied group, and they have many different perspectives and form their arguments in different, often contradictary ways. They just see a common means to their end, and each individual may be 100% consistant. (note: I'm not a democrat, I just used them as an example. This works with any political party that I can think of.)

Ultimately what you're doing is grouping variety of people together (slashdot readers) and then attacking the group as a whole for being inconsistant with respect to a separate issue (their perspectives about computer security).

You can do that to anyone. For example: "Blondes are so inconsistant. First they complain that the environment is being damaged, then the next week they're complaining about too much government regulation." Well, being blonde obviously has nothing to do with the topic, so of course you find inconsistancies in their viewpoint.

That type of reasoning is very simple-minded. The world is a complicated place with myriad possible groupings of people. Analogies that relate nations, corporations, SIGs, etc. to people often confuse the issue beyond repair. Microsoft isn't a "bully," it's just that the shareholders elect people that are likely to use aggressive business tactics and leverage the monopoly that they have to gain shareholder value. You can't punish MS in any way analogous to punishing a bully, because the shareholders could be long gone by now (however many years it takes to settle an antitrust lawsuit), because it's simply not a person, it's a group. Same with nations, it's a group and should not be personified. Think how much time the media has wasted talking about Bush as though he "doesn't play well with others." Nations are groups, not people.

Re:So much for unbiased Slashdot

[tiger99]

Yes, the backward slash for the backward OS, which usually has poor backward compatability.....

I think Bill must be a bit backward in certain respects.

Re:So much for unbiased Slashdot

[Luigi30]

No... I thought it was because Linux uses / for directories and Windows uses \. (period! no pun intended with that!)

Re:So much for unbiased Slashdot

[thenextpresident]

Well, no, your wrong, even if you think it's your opinion. Opinions can be wrong when they are based on misplaced fact.

First, we aren't talking about a desktop system getting hacked, we are talking about a server getting hacked. Secondly, a hack is a hack. If people at Debian let this slip, then it's their fault in the end. Whether it was MS or Debian, it would be the same thing: they screwed up.

Secondly, Debian doesn't develop all the software they distribute, or even use. Microsoft, however, developed Outlook. So, if a cracker gets into Debian because of an insecure application, it's not Debian coders at fault. However, a cracker that gets in via Outlook, well, it's MS's fault because they developed Outlook. (One could argue it was neither's fault, and rather the crackers fault, but that's another story).

Thirdly, you can't compare these two because of the open/closed source nature of either company. If MS were hacked into, how much information would they provide? How about Debian? What concerns me more isn't that Debian was hacked, but how many times has MS been hacked, and we haven't known about it.

Fourthly, you want to blame the user for the foul up when they execute a worm. First, a cracker and a work are two different things, and really can't be compared. However, looking at the work, it merely executes on Windows. The problem is that the security model for Windows sucks (it does, and any belief to the contrary is the same thing as admitting you don't care about security, and know nothing about it), that it allows all of this.

Finally, you say there are a bunch of excuses and rationalizations with all of these posts. This happens, whether it's Linux or Microsoft. The difference is that with Linux, we can check, while with Microsoft, we can't check. We have to go with what they tell us. If they say "Oh, it's merely a small problem," is their any way for us to actually verify this? No. But with Linux, it's usually open and verifiable. And what would you have the people do if they found out the crack was because of a bad password? Lie and say it was something worse. If it was a bad password, it was a bad password, nothing more. But with Linux, this can be verified, whereas with MS, this can't be.

Maybe you enjoy being lied to. I don't.

Re:So much for unbiased Slashdot

[Anonymous Coward]

I love opening them!!!! ...on Debian... I see how they are made then I resist sending them to my Windows-using relatives.

Re:So much for unbiased Slashdot

[Hank Chinaski]

This is because one of the "strong" points which is claimed by windows is that it's designed to be used by non-tech experts, while at the same time it offers NO protection from mistakes. If outlook were modified so that it cannot execute anything and you must manually save to disk and execute whatever you would see (beside a drop in virus infections) fingers pointed at the users instead of Microsoft. That is in fact the default setting for outlook for about 2 years.

Re:So much for unbiased Slashdot

[JahToasted]

What? You're arguing that slashdot users don't practice group-think? Who are you kidding?

Re:So much for unbiased Slashdot

[cscx]

There is a lot of bullshit around here. I've been a proud user of Outlook for about 3 years now (that's 3 versions -- I migrated from Eudora and Netscape Messenger) and I've never had a problem.

Let's just say I'm happy that Debian refused to install on my firewall box (couldn't see the NIC card -- sheesh!) -- It's running brand spankin' new OpenBSD 3.4, an upgrade from 3.3. It's nice not to have to worry :)

Re:So much for unbiased Slashdot

[mvpll]

Err, I thought the default behaviour was to completely fence users off from attachments. This breaks their email, so the first thing they do is turn it off...

(Actually the first thing many people do is ring their ISP/helpdesk and complain that the ISP/helpdesk has broken their email. That is OK of course, because Microsoft pays these support costs.)

Re:So much for unbiased Slashdot

[Tony-A]

You're arguing that slashdot users don't practice group-think?

Not just one group think. Many diverse group thinks.
Posted from my unpatched NT Workstation (that doesn't run Microsoft Wormage so good anymore;)

Actually, for keeping up with what Microsoft is up to, Slashdot seems to be the only readily available unbiased source.

I didn't say Slashdot was unbiased. I said it was the only source for unbiased information.

Re:So much for unbiased Slashdot

[placeclicker]

I would say you could easily determine Slashdotter's overall prefrences on issues by how the editors by and large feel.

After all, who sticks around a site that constantly pisses them off?

Re:So much for unbiased Slashdot

[saintlupus]

Slashdotters are hypocrites and hold double-standards.

Hey, slashdotters are a community, not a single voice. Personally, I think all software sucks, no matter who makes it. No double standard there.

--saint

Two useful utilities to flush out the rootkits

[Taco Cowboy]

Here are two useful utilities to flush out the SucKIT rootkit:


Kernel Security Therapy Anti-Trolls

and

Kernel Security Checker

Have a nice day !

Re:Two useful utilities to flush out the rootkits

[Anonymous Coward]

Since many of these exploits share common traits, the nero institute created this utility which will scan your boxen for possible security gaps and recommend the appropriate fixes.

Re:Two useful utilities to flush out the rootkits

[cscx]

I laughed when they mentioned the volume mounted with all those "old suid binaries..."

Shouldn't they have been mounted nosuid... like is default in OpenBSD ;)

Re:Two useful utilities to flush out the rootkits

[mvpll]

Err, yeah, because you can trust anything you run on a rooted box...

>./checkrootkits
"There are no rootkits here ... honest."
>ls
"There are no rootkits here ... I swear"
> cd /
"I didn't recompile the kernel ... these are not the system calls you are looking for."

(I'm not trying to completely devalue these projects, but ... horse ... barn door ... etc).

HEH

[Anonymous Coward]

This ought to be enough to defeat your gay ass lameness filter.

Let me just make my fucking post, you asshole, and all will be okay.

And there's more than fucking 36.2 characters per line in this post, so stop being so fucking gay about it.

Apparently Slashdot editors are gay and flunked math which is why it's been stuck on 36.2 or 36.3 characters per line for ever.

So the fucking lameness filter won't let me post this, eh? Yeah right.

As long as a machine is connected to the internet there is going to be a method to compromise it. My question is this why Debian? They are the only Linux distribution that is truly built by volunteers to gain any mindshare of real note. (not sure about slack so please dont sick bob dobs on me) This is not imhop the work of rank amatuer crackers with there first root kit. These were servers being run by experienced admins using a distro known for stability which when patched and up to date usually means somewhat difficult to hack. I seriously doubt these guys were running winders attempting this either. Wtf is happening to the community when people with talent are attacking a distro that yet again imhop doesnt suck. These guys need to be found and buried. Not by the police but by the commmunity. Last but not least (places tinfoil hat on head) could this have been funded by M$ trying to discredit linux. I cant see the glory angle so its got to be money or power. (no glory in getting called a dick when you tell your friends what you did) From what I understand of the cracker community, Linux is held in fairly high regard (although I admit I don't try to keep up on the latest in the cracker community). You'd think that black-hats, who tend to be rather immature, when armed with a brand new exploit, would attack a site seen by the general public and post goatse.cx images on the front page, rather than subtly changing Debian packages. So, who's behind all this? People with a Slashdot UID of 149812 are not to be trusted. So, what's going on here? Are these simply two unrelated attacks? Is it an attempt by an immature highschooler with some cracking talent to boast to his friends "LOL 1 hax0rred debian.org!?" Is it an attempt by some sort of anti-Linux commandoes to undermine Linux's public image? I almost suspect the latter, but the prime suspect there is Microsoft, who have far too much to lose by going that route and plenty of money for traditional FUD that will make it into "traditional" news channels better anyway. SCO might be crazy enough to do it, but they probably wouldn't want to divert resources away from spewing lawsuits at everyone in existence. To me, this attack and the recent attempt to insert an exploit into the Linux kernel [iu.edu] seem like possible evidence of a disturbing trend: skilled attacks against high-profile Linux sites (you can't get much higher-profile than kernel.org or debian.org). I'm pretty sure that these systems were secured against all known local root exploits; if they weren't, this probably would have happened long ago. This might be a good place to mention that the CVS codebase is almost irreparably insecure. The practical implications are: (1) A remotely-accessible CVS server should never be run on a host that does anything else that matters, or that has access to anything else; (2) An anonymous CVS server should never be the same CVS server that is used for checkins, or even run on the same machine. The pserver should be a slave that only gets read access to a copy of the archive. (3) Checkins on remotely-accessible servers should result in patches logged to another archive kept

Isn't it obvious?

[autopr0n]

There are people with lots of money who want to see Linux taken down. Not everyone shares your ideals.

Re:Isn't it obvious?

[Wudbaer]

You don't need to be a Microsoft or SCO to have fun vandalizing other people's systems. This is the same mentality like when someone destroys bus stops, telephone booths and other public property or the flower beds in the park some volunteers put up the week before on their own time and money. It is against the common good, but being an asshole that person just doesn't care.

Something big is missing

[rudy_wayne]

Somehow they got root on klecker and installed suckit.

"somehow they got root" isn't very informative.

Re:Something big is missing

[wichert]

One if the reasons we are taking so long with all this is that we simply do not know how exactly root was gained. When we do do and we have a fix we will gladly reveal that along with a security advisory detailing how you can protect your systems as well.

Re:Something big is missing

[TiggsPanther]

From the article, it appears that they're still working on that but.
But they are releasing what they know so far within a week of the incident. And were confirming the exploit within a day of it happening.

They might not have all the answers, but they seem to be telling us what they know, and updating us as they get further.

Hell, they know it'll appear on /. and similar places - and I've seen some Debian devs around on these comments. Meaning the news gets out to people (like me) who don't even use Debian.
Contrast with Microsoft, who don't always even let the Windows Users (or Admins for God's sake) have a good idea of what's happeneing and when things'll get fixed.

Tiggs

Re:Something big is missing

[TiggsPanther]

Well I, for one, appreciate the way that Debian are letting us know what they do know, and admitting that they don't have all the answers yet - whilst at the same time allowing people to at least be aware of the potential problems. (Whether or exploits, or of snifers and rootkits)

Re:Something big is missing

[spitzak]

That is because, duh, they don't know.

Actually a more serious question, every other time somebody has analyzed an exploit (on both Windows or Linux) it seems the analysis is able to say "they used the FooBar hole". This is the first time I have seem somebody say "they used an unknown hole".

This either means that:

1. Hackers are better able to hide what they did than before

2. Some improvement in Linux means that you can now detect unknown exploits much better than before, and before now they were all never seen and thus unanalyzed.

3. I have not really been paying attention, and reports of "unknown hole" are more common than I thought.

Re:Something big is missing

[placeclicker]

One reason for using a rootkit is to hide up what exploit you used. Especially if its an undocumented one.

Brian Regan

[Anonymous Coward]

Teacher: "Erwin, what is the plural for Ox?"
Erwin: "Oxen. The farmer used his oxen."
Teacher: "Brian!"
Brian: "Whaaaat?"
Teacher: "What's the plural for Box?"
Brian: "Boxen. I bought two boxen of doughnuts."
Teacher: "No, Brian, you're an idiot."

Teacher: "Let's try another one. Erwin, what's the plural for goose?"
Erwin: "Geese. I saw a flock of geese."
Teacher: "Brian!"
Brian: "Whaaaat?
Teacher: "Brian, what's the plural for Moose?"

Brian: "Moosen! I saw a flock of moosen! There... there were many of them. Many much of them. Many much moosen. They were out in the woods... in the woodsen! They were eating grass... greese! The meese were eating greese in the woodsen! They were looking for the foodis to eatinisit! out in the woodingenis... in the woodenis... in the woodingenisenisen!

Teacher: "Brian, you're an imbecile."
Brian: "Imbecilen!"

Re:Brian Regan

[juniorkindergarten]

Actually the plural of moose is meese.
mouse = mice
goose = geese
Therefore...
moose = meese!

Re:Brian Regan

[Xilman]

And it's long been known that the plural of spouse is spice.

Paul

Re:Brian Regan

[Mattcelt]

...and thus we have "spice is the variety of wife"! I get it now!

Re:Brian Regan

[jo42]

...and some English idiot spelled knife with a 'k'...

Re:Brian Regan

[orthancstone]

Brian: "Germany...Jermaine...Jackson!...Jackson 5...TITO!"
Teacher: "Brian, what the hell are you talking about?"

the linux attitude prevents real security...

[a_hofmann]

it's a sad thing that everyone seems to be so confident in their latest super secure linux setup, the power of fast and often patched open source software or the openess in such issues - so much that nobody takes these problems serious enough.

for every exploit known (and fixed) publically you can bet there are two yet undisclosed and maybe in the hands of the wrong people...

concepts like public key crypto (ssh, ssl), stack guarding (say no to buffer overflows) or process jail (try to escalate privileges from there) are thus essential to implement real security. still ease of setup or performance seems to be more important than safe networking.

perhaps the big desaster has to happen before people understand that projects like openbsd or selinux are not your tinfoil-hat wearing neighbor's business but the only serious choice for any public, responsible service provider.

Mod parent up!

[KamuSan]

Hoy sh*t, never thought of that, but you're absolutely right. Good thing you have 2 eyes, not?

Re:Mod parent up!

[IWannaBeAnAC]

And after the second eye gets compromised, you can train yourguide dog to log onto your computer for you ;)

Re:biometrics

[jamesh]

When someone mentions retina scanning as an authentication mechanism, i'm always reminded of the movie 'Demolition Man', and for palm/fingerprint scanning, of the 'Inquisitor' episode of Red Dwarf.

Palm scanning only proves you have the hand of someone allowed to access a system.

Retina scanning only proves you have the eyeball of someone allowed to access a system.

flaw?

[Anonymous Coward]

"Suckit is a rootkit which installs a sniffer, a process hider, a file
hider and a backdoor login in a running kernel. Apparently there was a
flaw in its kernel code which caused the kernel to oops on master and
murphy. "

So, if it hadn't had that flaw, they wouldn't have know anything about it, and continue to serve on compromised boxes.

Great.

SELinux

[Anonymous Coward]

Hmm... maybe SELinux would have stopped this? Doesn't it prevent hooking into system routines? If so, then it's a great excuse to see better SELinux support in debian :)

Re:biometrics

[God! Awful 2]

Palm scanning only proves you have the hand of someone allowed to access a system. Retina scanning only proves you have the eyeball of someone allowed to access a system.

Well, the manufacturers of palm/retina scanners generally do include a feature that detects if the bodypart being scanned has a pulse. So you can't fool these scanners just by cutting off someone's hand or ripping out their eyeball. (Although it might be possible to manufacture fake contact lenses or glue-on fingerprints that would work.)

On the other hand, the basic weakness is that the biometric signature is still just a big password. You can "sniff" the signature by installing a fake reader. You can steal the signature off the harddrive of the domain controller. You can bypass the reader by splicing the wire. And your "password" is the same for every site.

Bottom line: I would sooner trust a token card.

-a

Whoops...

[plj]

I have dealt with this rootkit for nearly 4 months when it first appeared ...you forgot to post as AC. FBI is on the way.

Re:Whoops...

[Anonymous Coward]

you think there not tracking whoes reading the article?
so did you...

suckit ...

[Pegasus]

This reminds me of a shit we had back in the april at the place where i work. We got a couple of production server r00ted with suckit, with the only possible attack vector being apache/php (only port 80 was open in the firewall), that were latest versions back then. The only way to stop it was to recompile a kernel without modules support and some minor patches to deny writes to /dev/kmem in any possible way ... therefore killing the method suckit uses to load itself. See point 6 here and here.
There were quite a lot of similiar reports from the folks all aronud at that time ...

My big hairy conspiracy theory would be in the line of super zonda type of organization hiring some of the most skilled crackers and r00ting the boxen all around ... for spamming, ddosing or whatever ... welcome to the Wild Wild Net.

WHAT THE FUCK ARE YOU ON ABOUT?!?!?

[Anonymous Coward]

Well?

Are there "Laws of Security"?

[waterbear]

Two questions:

#1: Has anyone ever proved that implementing any definite number of 'laws' or software conditions can actually add up to security (not crackable except by obtaining/compromising a root password or signature)? If this hasn't been proved, the whole concept of software security itself may be an exaggeration.

#2: What about hardware security? Under current conditions, it might be progressive to reduce the security risks so that any exploit would depend on physical access. If the answer to #1 is 'yes', then security can be implemented by passwords or signatures but it looks like the security of a combination lock. Do we have any computer software security based on a lock that requires a physical key -- (maybe a physical key, or key-guarded switch, that did something like switch an area of memory from writeable to hard-wired non-writeable)? If we do, is it available for use in a crucial installation like a debian server? If we don't, why not?

Let me tell you how not shocked I am

[Anonymous Coward]

The only interesting things are that a) a primary linux distro channel was successfully attacked and b) there's a local root sploit out there somewhere.

a) was an administrative failing.
b) is predictable.

If you do anything wrt unix security you know that local access by an intruder should be viewed as a complete compromise. With the plethora of root kits, anti-forensics kits, etc out there there is no way to be absolutely certain the attacker didn't get root.

Also, everyone knows that local vulnerabilities are still rife on most systems. That's why we set up the primary security barrier at the *network* interface. There are a lot of good systems out there for handling local security (*cough* grsecurity ACLs *cough*) but most people find these too much of a hassle to set up.

Oh well, another day on the net.

*b*

One more reason...

[Anonymous Coward]

Debian is obviously insecure. One more reason to stay with Windows XP, the king of operating systems.

Doesn't seem very logical..

[naitro]

An attacker who has access to unpublic local root exploits probably won't use a public kiddie-rootkit like Suckit.

And I hardly believe that an experienced cracker would backdoor the boxes in such an uncareful manner. Weird..

Nmap says enough about the quality of debian !!!!

[habor]

Try Redhat and see de difference. How is it possible. They have to learn how to work with iptables!! Incredible. Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on www.de.debian.org (141.76.2.5): (The 1583 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 22/tcp open ssh 80/tcp open http 111/tcp filtered sunrpc 135/tcp filtered loc-srv 136/tcp filtered profile 137/tcp filtered netbios-ns 138/tcp filtered netbios-dgm 139/tcp filtered netbios-ssn 161/tcp filtered snmp 162/tcp filtered snmptrap 445/tcp filtered microsoft-ds 515/tcp filtered printer 593/tcp filtered http-rpc-epmap 873/tcp open rsync 1993/tcp filtered snmp-tcp-port 4444/tcp filtered krb524 6346/tcp filtered gnutella

Re:Nmap says enough about the quality of debian !!

[tigertiger]

That tells you they are running an ftp, ssh, rsync and a web server - hardly surprising.

'Filtered' means that the port is blocked by the firewall, as opposed to closed ports which can be reached through the firewall but have nothing listening on it.

Re:Nmap says enough about the quality of debian !!

[habor]

You have to see nothing only the open ports !! This kinds of configurations you see if you make your rules by shorewall or some other tool. I see they run samba and gnutella on their main webserver. How is it possible after the hacks! In a commercial organisation you will be dismissed

Re:Are there "Laws of Security"?

[ScepticOne]

Rule #1: Don't plug it in.

Why might ssh keys be compromised ?

[simoncrute]

I've a couple of questions on this.
There was a comment in the origanal posting that remote SSH keys may be compromised if authentication forwarding was used ? Can anyone explain why that might be ?

Also, isn't anyone worried that the only reason the root kit was discovered is because *two* machines were oopsing. ?

Re:biometrics

[abulafia]

Well, the manufacturers of palm/retina scanners generally do include a feature that detects if the bodypart being scanned has a pulse. So you can't fool these scanners just by cutting off someone's hand or ripping out their eyeball.

Um, someone needs to tell that to the manufacturers.

I can't find a reference at the moment, but there was a nice report recently by someone who has been playing with fooling fingerprint scanners for a long time that the cost of tricking one is now about $20 and 15 minutes, no clever expertise needed. I've been meaning to try it out - the only thing I'm lacking is a fingerprint scanner. In any case, apparently, nobody looks for a pulse on commonly used hardware.

For methods, see google.

Re:Nmap says enough about the quality of debian !!

[Anonymous Coward]

No, the samba and gnutella ports are both filtered - not open!

Defeat binary evil!

[DrHyde]

Note that the main ftp archive running on a sparc machine was not compromised, so the exploit might not yet be ported to non-i386 architectures.

So if we run Linux on Sparc, and Solaris on x86, we're safe!

Local Postfix exploit

[Anonymous Coward]

Rumor has it that there exists a local exploit in Postfix and this was used to gain root in the Debian exploit. More later.

No OS can ever be 100% secure, but.........

[DFJA]

Proprietary OSes will ultimately be left behind Open Source OSes in terms of security for the following reason. In the fight against proprietary OS's such as Microshaft's, there is a big propaganda war with both sides saying "Look, your OS is insecure". Both OS's will have security holes discovered, and hopefully fixed, from time to time. That is a fact we have to live with. The rate at which they are discovered and fixed is roughly proportional to the number of people actively investigating holes in the OS (ignoring the fact that there might be other, political reasons to look for security holes one OS rather than another). However as time goes on, we should expect the number of users of Debian (and GNU/Linux in general) to increase, hence the number of people discovering and fixing security holes will go up in proportion. This is the 'many eyeballs' effect. this will lead to GNU/Linux becoming ultimately very secure. In contrast the number of people actively looking for security holes in, say windows, is proportional to the amount of money their perpetraitors (sic) are willing to spend in this task. This does not go up in proportion to the number of users. In fact as competition pushes prices down for proprietary offerings, the perpetrators find they have progressively _less_ money to spend on looking for security holes. Ultimately they will get left behind. So we should see that Open Source OSes such as GNU/Linux will become more and more secure at a rate which accelerates much faster than for proprietary OSes. At the moment, we have one OS which is used by 95% of the world's desktops, and scores fairly low on security (although it is improving). On the other hand, we have GNU/Linux which is used on something like 2% of the world's desktops (more on servers), and scores fairly high on security (although it's not perfect). So from this small user-base, we have already benefitted from the 'many eyeballs' effect of Open Source to gain an advantage over the competition in this respect. This advantage can only accelerate, for the reasons I have outlined above. Ultimately we should expect to see Open Source winning on all fronts in terms of reliability, functionality and security. It will never be perfect and there will always be crackers trying to spoil the party, but it will be a lot better than today's situation. We just need to work hard to make this happen sooner rather than later, as it will be a long haul...........

Re:No OS can ever be 100% secure, but.........

[Fjord]

I think you meant proprietors and not perpetrator even if the second is somewhat fitting.

Hey...

[Anonymous Coward]

They are not going to find out how the intruder got root access. This is the reality. Face it.

Other distros affected???

[Malc]

Everybody here is talking about an unknown exploit in Debian. What I haven't seen is a discussion on the probability that this might affect other distros too. Is it Debian specific, or Linux, or even UNIX (based on an app) specific? Let's not be complacent here.

Re:Other distros affected???

[maximilln]

It's not distro specific. Every distro of every OS has unknown exploits associated with it.

This is a prime reason why OSS is the only rational solution. Proprietary software companies such as Microsoft will first deny that there is any security problem. Then they will admit that there is a security problem but refuse to tell anyone what it is for security reasons and will empasize with political clout that they and only they are allowed to work on it. They will refuse help from any outside source.

Re:Other distros affected???

[HiThere]

Since it's an unknown kernel escalation attack, we don't know how it's done. So it could, indeed, effect other systems. For all we know, this same attack could attack Mac OS9 systems...though the chances seem quite remote. It's not beyond the bounds of possibility, though, that it could attack other distributions. Or even varieties of Unix. But I suspect that it's got some severe limitations, or we'd be hearing more about it than we are.

Re:Other distros affected???

[Malc]

In your rush to make a [partially inaccurate] political rant you missed what I was saying. I'm sure every distro or OS under the sun has many unknown exploits. However, I was talking about this one in particular. It's obviously not completely unknown (it's been exploited) - can this particular issue be exploited in the same way on systems running other distros?

If you want to make comments about all the other unknown issues and the different philosophies for dealing with them, fine - please start another thread though as it's off-topic for this one.

Re:Other distros affected???

[Malc]

Aren't you making an assumption that it's a kernel escalation attack? Couldn't it be via a flawed setuid binary?

Could it be related to Debian patches?

Could one of RedHat's main servers have already been exploited... but we don't know about it yet?

Re:Other distros affected???

[maximilln]

Ouch. I feel flamed.

Perhaps I stole this guy's girlfriend in a past life?

Re:Other distros affected???

[HiThere]

Yeah...I'm assuming that, though I believe that was mentioned in the Debian log. But since they really don't know HOW it was done...the guy who wrote that message could be wrong too. He's guessing based on the evidence, and I'm guessing based on his expertise (a MUCH weaker position).

Re:biometrics

[Feyr]

that was in the lastest cryptogram by bruce schneider

How much would writing applications in Java help?

[totierne]

I know slashdot is almost a java free zone but:

With java
-There are mo buffer over runs or memory allocation issues, but then
-There may be bugs in the java implementation. -Cleartext passwords would still be a problem if the app is not written with security in mind.

Deep problems do not go away, but java solves/automates the solution to many shallow problems.

Re:biometrics

[abulafia]

Right! I couldn't remember where I read it.

BTW, there's not 'd' in his name.

the unknown

[maximilln]

This is really the heart of the issue: the unknown exploits. I've often been at the forefront of theorizing about possible vectors for unknown exploits. I'm usually flamed severely for it. The fact of the matter is that these unknown exploits exist and people need to be ready to deal with them.

If a "bad" hacker comes up with a new root exploit he's not going to e-mail all of the "good" hackers and let them know. He's going to make use of it mercilessly until he's noticed and caught. Microsoft ignores this issue outright and the OSS community tends to skate around it. If the computing public as a whole knew the facts about security then McAfee and Norton wouldn't even be in business. "Updating virus definitions" twice a week is still going to be ten weeks behind the hardcore caffeinated malicious hacker.

The OSS community has dealt with this issue in the most productive manner possible: complete openness and timely notice. Microsoft, on the other hand, would happily allow millions of users to remain compromised for months or years until their internal programmers manage to find the "unknown local root exploit". This could easily result in identities and credit card numbers stolen, bank accounts infiltrated, and possibly even malicious interference with real life relationships and employers just for fun.

Should the software manufacturer be liable? No. Should the user be entitled to know? Yes.

The OSS community is the only solution which addresses this situation correctly.

time of attack

[Anonymous Coward]

take a look at the time of the attacks.

The attacker stoped at 19:00h and started back at 5:00h.

Now from this time, and assuming the attacker is like most computer guys I know, he would sleep around 2-3 AM, and wake up around 11-12.
This would place the attacker at 6-8+ GMT hours.

that is, in china, Mongolia, Rusia or Indonesia.

You do development at home not on remote host...

[Mongoose]

I sure hope no one uses remote machines for development, unless they need to test build on say a remote machine like a mac/sparc. Not everyone owns their own G5s and SunBlades, but more than likely you own the arch you develop for or have it in a lab at work/school.

This couldn't happen ....

[Anonymous Coward]

This couldn't happen to a closed-source software vendor, right? I mean, if someone did somehow manage to hack into Microsoft's highly secured CVS, for instance, the intruder would be too scared to actually plant a Trojan or anything. And, if he did, the closed-source vendor would immediately notice the intrusion and inform all its customers who downloaded binaries based on the Trojaned sources. Right? So, everyone running Windows, for example, is immune to the effects of such evil deeds. Gosh, closed-source is soooo nice in comparison to open-source!

[This message, sent from a Windows XP system, has been automatically sniffed, scanned, and transmitted to PHC for review and filing by software installed on cvs.microsoft.com by biffy crew.]

This is exactly what I posted might have happened.

[FRAKK2]

I can't believe it this is exactly what I posted was
most likely to have happend, someone sniffed a
password and then cracked the machines from within.

Of course this went above the head of the windoze idiots all posting tripe about how linux as just
as weak as windows.

By the way yet agin my winxp box has been updated becuase of an IE remote exploit. Fucking piece of shite good thing its only used for games.

Accidents happen

[PurpleWizard]

Someone could have typed the password in at the wrong time so it was sent unencrypted. Then someone watching and waiting patiently sees it and deduces it is a password. I've type passwords in at the wrong time before.

Hence even if the system was otherwise totally secure accidents happen. A bit like driving safely but someone stepping out from behind a van at the very last second. One careless moment is all it takes.

Bar code reader and mobile phone

[PurpleWizard]

Get a bar code scanner and a mobile phone that is capable of displaying bar codes.

I don't know how long a bar code can be but if you are in need of a longer password you can always require multiple codes.

Yes people can steal your phone but at least that can be protected by a simple PIN that can't be sniffed.

Of course your phone may be insecure if it has Bluetooth:-)

Re:biometrics

[God! Awful 2]

If you're trying to disagree with something, I think you quoted the wrong part of my message. I only said that *dead* bodyparts can't be used to fool the scanner. I haven't read the latest issue of crypto-gram (have to be on the list to see it), but I take it from context that that's not what you meant.

-a

7 degrees of seperation

[PurpleWizard]

That principle suggests to me that no system into which ssh (or indeed any secure) access is possible is safe.

Here's why

You go in through the easiest system you can that has people that use the target or use something that is a step on the way to the target.

Once you have the ability to use suckit or other ways to compromise SSH on any machine you hace access to the next machine along.

Eventually if you are quiet and patient you will get somewhere interesting.

So who is secure?

Re:biometrics

[__past__]

Well, the manufacturers of palm/retina scanners generally do include a feature that detects if the bodypart being scanned has a pulse. So you can't fool these scanners just by cutting off someone's hand or ripping out their eyeball.

Tests regularly show that you can fool a lot of fingerprint scanners with an image of the fingerprint on translucent foil, and face recognition systems by holding a black-and-white photograph in front of the camera. Biometric access control is a cool idea with lots of geek appeal - just wait a few more decades until it actually works. Or at least make damn sure that the system you plan to buy isn't snake oil.

Re:biometrics

[abulafia]

I'm not sure that I'm disagreeing with you, either.

I _want_ to play with this stuff, but don't currently have the tools. I'm not likely to have dead body parts sitting around, so I suppose I can't provide a comprehensive answer. All I was getting at was that refactored horse hooves apparently are good, in the minds of current, state of the art scanners, when said refactored hooves are used to fool said scanner by someone with access to Google, access to a grocery store, access to a hardware store , and a motive.

Finding a pulse via software shouldn't be that hard. However, trusting biometrics is not the same thing.

That's all I was getting at.

Re:biometrics

[ChaosDiscord]

Well, the manufacturers of palm/retina scanners generally do include a feature that detects if the bodypart being scanned has a pulse.

One would hope so, but the evidence isn't as promising.

UNINFORMED! : password => access => rootkit

[Anonymous Coward]

or what's your way of installing suckit?

What debian's not said, clarifications speculation

[fw3]

I beleive the additional details of this exploit are roughly:

A debian developer (who I'm not going to name but it's not exactly a secret) revealed his password by logging into some machine that had been rooted. Shame on him for using the same password, and the Debian project for not policing that kind of thing. (That said, people do this all the time, even people who do/ought to know better.)

The password 'sniffing' being referenced is not sniffing network packets but rather session IO. If you read the 'developer cleanup' instructions it will be clear that they beleive that the 4 dev boxes that were rooted were being used to collect account and password info from developer's sessions. (Another procedure error, the systems in question probably should not be allowing users with shell access to ssh out to other machines.)

There has been a LOT of speculation that there's a privilege-escalation vulnerability in the kernel version running on the target systems and/or up to the 2.4.22 kernel (I'm dubious, however 2.4.23 has just been released today so who knows).

As many here and elsewhere have wondered, it seems unlikely that a 'kiddie would have access to somthing not yet observed in the wild, and if this is the work of more capable 'bad guys' then it seems equally unlikely that they would have been so noisy as to have been caught in less than a day.

Leaving us really not knowing much about the state of either debian or the kernel at this time. I certainly hope that a more complete complete 'explantaion' will be coming, hopefully soon.

bad guys

[frovingslosh]

Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore.

Strange that Microsoft would admit this, in light of Longhorn and how many people believe Bill Gates is a bad guy.

Incomming newsflash!

[Anonymous Coward]

Aliens from Neptune have found scientific proof for the premise: Linux is a kernel.

Same reason they tried to trojan the kernel?

[Kjella]

but why crack Debian in the first place? here I am stumped, but then I've never fully understood the cracker mentality.

It's called poisoning the well. Now, if you suddenly have a big host of infected computers running a compromised Debian, you got one damn nice Botnet, either for getting data from those, DDoS, platform for other attacks, or just general havoc. In particular I imagine many Debian boxes are connected to fat pipes they'd like, not throttled cable/dsl residential Windows-boxes.

Kjella

They run gnutella filesharing !!!!!

[habor]

An nmap scan on debian.org found they run gnutella. I don't know they do that under root. But it's real stupid thing.I very pissed. Imagine that Microsoft is running kazaa on their main webserver. With this kind of behaviour Debian linux is not ready fot the enterprise.

We had similar experiences recently

[mnmn]

Our Linux firewall was compromised a while ago. The attacker apparently used a samba exploit to break in (RedHat 9.0 with patches installed) and then tried a bunch of sendmail, NFS and samba exploits on other machines. Its not clear how he got root access but it seems he replaced some libraries with a few extra routines. After becoming root, he replaced all files in /bin and tried many exploits on the win2000 servers.

We were lucky not to have been hit hard, but the scare made us replace the Linux with an OpenBSD firewall with tightly configured ipf and snort. In the proceeding days, we logged attempted telnets and ssh from 3 different IPs 2 in korean primary schools, 1 from a chinese telecommunication company. (APNIC)

So the RedHat has been moved to be an internal server and we're careful about packet filtering now. Theres a finer level of permissions control all over the place and all services run as nonroot users, some in jails.

Re:Nmap says enough about the quality of debian !!

[habor]

The ports has to be masquerated for the outsite world Gnutella filesharing !!! Why

What excellent FreeBSD security(7) says

[Przepla]

One must always assume that once an attacker has access to a user account, the attacker can break root.

So nothing special about that break-in. In long time run such incidents must happen on any machine with publicly available accounts.

Look what Balmer says !

[habor]

Microsoft has taken its lumps, he concedes, but the problem is how patches are implemented, not whether Windows is natively insecure, he says. Furthermore, he says recent evidence indicates that security vulnerabilities with Linux are vast, too. "If those genius teen-age hackers out there start picking on those guys instead of Microsoft, it could be devastating because the open-source guys just don't have the infrastructure and ecosystem to deal with it like Microsoft does," he says. TalkBack

What about Python?

[RdsArts]

Why Java? Why not python?

No, seriously. C/C++ is great for local apps and kernels, but for world-facing servers isn't managed code a good idea?

Of course, we could also begin working on some general-purpose security "modules" and make them availed to everyone. Plus the servers would now be multiplatform almost by accident, and be Free software in every sense.

OT

[ShieldW0lf]

Generalizations are essential to thought. It allows us to analyse things, percieve patterns, judge new things and make decisions. At the end of the day, you can never really be absolutely specific, all you can do is adjust your level of generalization. You simply can't analyse or discuss large scale things without using generalizations. That being the case, you'd be a fool to discard a statement just because it's a generalization.

The simple-minded thing is when you can't communicate with someone about things without nit-picking over exceptions instead of just accepting their comment as being a trend/pattern/norm/whatever and not an absolute.

Re:OT

[jadavis]

Yeah... 'cept the whole point was that slashdot readers are inconsistant! Of course a group is inconsistant if you pick and choose all the varying opinions. If he said that slashdot readers' perspectives about computer security are flawed for reasons x,y, and z that would be fine with me. Sure, it's a generalization, and that's a good thing. But he said that slashdot readers were contradicting themselves. It's a feeble attempt at an argument if you do both the grouping and then find the inconsistancies, and then imply that the people are individually inconsistant.

power of diversity

[Anonymous Coward]

That the sparc ftp server was not hacked is really interesting and demonstrates the power of diversity. Using different software on different machines really can help avoid huge security problems.

Re:biometrics

[c_code]

This gives a whole new meaning to "Identity Theft"

Re:What debian's not said, clarifications speculat

[mgbastard]

A debian developer (who I'm not going to name but it's not exactly a secret) revealed his password by logging into some machine that had been rooted. Shame on him for using the same password, and the Debian project for not policing that kind of thing. (That said, people do this all the time, even people who do/ought to know better.)

I'm going to have to beat into all the distro maintainers. Your servers should adopt OPIE one-time passwords. Failing that, enforce keypair authentication with your users. Put it right into your ssh_config. Force it. I recently engaged in a pro/con discussion of OPIE v. keypair authentication with another unix sysadmin. OPIE, by design, doesn't store the passphrase on either local or remote hosts. If you a rooted/keystroke logger on a connecting client, the password will not get them access after 30 seconds or so (depends on your OPIE config timeouts...) OPIE removes the possibility of keypairs being stolen. I do believe there is still a serious vulnerability to keystroke loggers capturing your OPIE passphrase, if entered on a compromised host. But this removes the possibility of a user's password being discovered with the easier methods.

You could always encourage folks to run their opie calculator on their cell-phone/pda, instead of a host directly attached to a network. (Are people hacking into your mobile yet?) No way to enforce that via policy though.

OPIE provides a one-time password system for POSIX-compliant UNIX-like operating systems. The system should be secure against the passive attacks now commonplace on the Internet (see RFC 1704 for more details). The system is vulnerable to active dictionary attacks, though these are not widespread at present and can be detected through proper use of system audit software. The NRL OPIE software is derived in part from and is backwards compatible with the Bell Communications Research (Bellcore) S/Key(TM) Version 1 Software Distribution. Because Bellcore claims "S/Key" as a trademark for their software, NRL has been forced to use a different name (they picked "OPIE") for its software distribution.

Exploit might not be debian-specific

[guilhem]

Our server has been hacked twice in a 3 weeks time :

at first we had a redhat70 fully patched and up to date. we never managed to find how :
1) he got in
2) he got root

he installed 3/4 rootkits and defaced all our html with a javascript/iframe pointing to http://viprating.com/rate and http://viprating.com/counter
there, tripwire saved my life!
neverless, we reinstalled every thing with a debian woody.

3 weeks later (4 days ago), the (same?) hacker broke in using :
1) an apache 1.3.26 shellcode which attempted to install linux.JAC virus from http://www.infosmolensk.ru/c [217.107.188.155] (beware! virus!), apparently failed to run
The logs showed some shellcodes, followed by a wget
2) second apache 1.3.26 shellcode followed by an unknown root exploit
The logs showed some shellcodes, but no command output
Then he installed suckit rootkit, and defaced all our html with a javascript/iframe pointing to http://viprating.com/rate and http://viprating.com/counter

I found the attack came from a russian site, http://www.infosmolensk.ru [217.107.188.155], as a saw several established connections from this IP to our port 80 with apache stopped...

Yesterday, he tried once again, but hopefully apache 1.3.29 behaved better :

access_log: 217.107.188.155 - - [27/Nov/2003:08:00:02 +0100] "\x93OZ\xe0\xe6\xe6\xef\xaeDRRq\x8dg\x82\xe1\xfd\x fe\x84f\x93OZ\xe0\xe6\xe6\xef\xaeDRRq\x8dg\x82\xe1 \xfd\xfe\x84f\x93OZ\xe0\xe6\xe6\xef\xaeDRRq\x8dg\x 82\xe1\xfd\xfe\x84f" 501 - "-" "-"
error_log: [Thu Nov 27 08:00:02 2003] [error] [client 217.107.188.155] Invalid method in request \x93OZ\xe0\xe6\xe6\xef\xaeDRRq\x8dg\x82\xe1\xfd\xf e\x84f\x93OZ\xe0\xe6\xe6\xef\xaeDRRq\x8dg\x82\xe1\ xfd\xfe\x84f\x93OZ\xe0\xe6\xe6\xef\xaeDRRq\x8dg\x8 2\xe1\xfd\xfe\x84f

I hope this exploit will be found 'cause we updated apache and put a kernel without LKM, but could not find the exploit!!!
Maybe the same exploit was used against the redhat... which means it might not be debian-specific!
Once sure thing : it is the same hacker, cause the defacing was the same

Not a bad idea that

[fw3]

I'm not so sure that keypair enforcement (unless it were enforced globally) would have helped in this instance, it seems that this developer's password was gotten when he gave it on a hacked box. Yes, skey/opie would serve, so would kerberized rlogin.

Of course there seems to be no better way to grab the ire of todays average crop of open / free software developers than to suggest that anything other than ssh is the correct solution to a problem.

In this instance to the best of our knowlege enforcing the use of cleartext protocols with encrypted authentication could have helped prevent the situation (e.g. as you say opie/skey over telnet or kerberized rlogin)

Additionally iff development work had been done over plaintext then all developer sessions could have been captured with snort/tcpdump and then the methods used by the miscreants would be accessible.

Of course your better class of miscreant is going to recognize this, but that's just part of the game.

It's a pretty sad thing that we're left with such a dilemma, I'm sorry to see it happen to the Debian project, simply because so many folks rely on it. Talk about putting the whole community on the horns of a dilemma (quadrilemma?):

• Unknown kernel exploit --- details sometime?
• There is some other hole introduced in the debian machines (side-note, it's odd/interesting that deb servers are seemingly running kernels not distributed by the debian project)
• An attacker suffieciently inept to have been discovered in 24 hrs has access to one of the above two posited exploits.
• (least palatable) These machines were priorly penetrated and the miscreant's have had an opportunity to place backdoors into Deb.