Sorry, my mod-points just expired. I'm a strong RedHat supporter (not because they're good, but because every other distro is worse). However, you just pointed out exactly what is wrong with the Fedora model.
I run Fedora on my laptop, and it works pretty well for me. But the stability isn't good enough for production. We use RHEL for that.
No, it's not practical for a well-funded adversary. Their attack only made it 2048 times easier. That's not particularly significant, in itself. What *is* significant is that it suggests that other attacks might be possible. But as it stands, SHA-1 is quite secure.
All they did was provide a hash that produces 1 collision
No, they didn't. No hash has been produced. Only a claim that they can do it in 2^69 operations. The collisions they gave were for SHA-0 and for a reduced-round version (58 rounds instead of 80) of SHA-1. Unless someone can extend the break (which is likely) then it's still quite secure.
Every time any/. article mentions RedHat, we get a bunch of kiddies attacking it. So, I propose a new rule: before attacking RHEL, please consider a few points:
Do you have 5+ years of sysadmin experience?
Do you have 100+ users?
Do you have 10+ machines?
Do you have to support enterprise applications?
Seriously, if you can't answer "yes" to all four questions, perhaps you should just keep your opinions to yourselves. The other distros are great for your mommy's basement, but in the enterprise, there are serious support/stability issues to consider.
Let's say I'm an ISP, and am concerned about getting my mail relays blacklisted if one of my customers starts spamming through them. Obviously I'd want to require SMTP AUTH so I can track problem users, but that only helps after-the-fact. What systems exist that can detect a problem as it occurs and take corrective action?
I see in sendmail a MaxRecipientsPerMessage option, which would prevent an infected client from specifying too many RCPT addresses. (It's not clear to me what happens if we have a mailing list with > MaxRecipientsPerMessage subscribers, though.)
What I don't see is an option to limit based on messages per hour. Does anyone know if this exists within sendmail? Or do you need separate monitoring software for that?
Not hard... in fact, we recently went through the process with our users. The trick to "convincing" them is to not give them a choice. Enable SMTP AUTH, and disable all relaying without it. Yes, a few won't change their settings before you disable the IP-based relaying, but that all gets resolved in one day. Not a big deal.
Same strategy worked well for the telnet/ftp to ssh/sftp conversion and the pop/imap to pop3s/imaps conversion.
Something sysadmins (and ISPs) need to learn is that it's our job to protect the users, even from themselves. Spending 5 minutes showing them how to do things in a more secure way is worth it -- taking a chance that their account will be compromised is just too risky.
Gah, sad. I thought you were asking what the words were for the above-posted binary coded ascii. Wasn't till I'd translated the entire thing, and re-read your post, that I discovered the truth.
The infamous "Bagle" virus actually has the string "beagle" in it.
The infamous "netsky" viruses were released by a group calling itself "Sky Net".
It's a real nightmare for sysadmins trying to figure out if their software blocks a certain threat, when each A/V vendor picks their own name. Many of those names are selected independently, and it's understandable that they don't want to change their names after they've released their updates. So, the obvious solution is to have the virus-writers come up with unique names which are easily identified, and for all the A/V vendors to use them. Yes, it means you encourage their ego. But really, who cares? It'd simplify everything else. I think it's worth it.
Agreed. I considered a switch to dvorak back in college. I actually got to the point where I could type without looking at the keys, and was doing maybe 10 wpm (which sucks, but it's over the hump of the learning curve). Then I realized that it completely broke may things, like the ctrl-c, ctrl-v thing, or the placement of j and k for scrolling in vi. As it turns out, the querty format has strongly influenced the design of many software products. It just isn't worth it to switch anymore.
Silly question, but at what point did they realize there was a problem? If they didn't find out there was a problem until after failing to receive channel A data from the orbiter, then the radio waves from the probe would have already passed the Earth also.
Did they somehow know that they'd forgotten to flip the switch before any data was transmitted?
Or maybe the transmit time was several days, and they only missed the first few hours?
Just trying to make sense out of this, since the journalists obviously don't have a clue. Hopefully someone who worked on the project can respond.
The point that these two guys are alleging, btw, is Heisenberg's Uncertainty Principle which states that observation of a particle changes the probability of it's existence to virtually zero.
What two guys? And the uncertainty principle doesn't say that at all.
So, if one were to attempt to 'brute force' attack a quantum crypto-stream, one would have to have had to receive a copy of that stream before it hit the 'quantum wire', ie before it reached the point where quantum mechanics superceded the laws of the seeable, knowable universe.
There is no "before". The photons are entangled at the moment of their creation.
Not impossible, but not likely either.
Actually, it is impossible. Unless quantum mechanics is a flawed theory, of course.
Once again, Slashdot and it's readers manages to fuck up a fantastic article written months in print.
Looks like you assholes need to learn how to read.
Actually, to be honest, I didn't read the article before responding. But that's probably because I was doing research in quantum computers back in 1996-97, and didn't feel that there were any major changes in the foundations since then. And I've known the details of quantum cryptography since about 2001, when I had an interesting chat with a researcher in that field.
But, just to humor you, I read the article. And now I know that there are two companies selling products. Which is rather amusing, because I would guess those products to be snake oil. As I'd mentioned in the grandparent post, it's very difficult to randomly select a polarization basis randomly at a high bitrate. I don't believe this issue has been resolved yet, so I would be wary of any products claiming perfect security.
Eventually, we will have quantum computers capable of brute-forcing even quantum encryption...
No, we won't. It's an interesting thought, but it doesn't work that way. According to the laws of physics (as we currently understand them) quantum encryption, if done properly, is provably secure. That is, there is no way to break the encryption, unless quantum mechanics itself is flawed.
Of course, there are other attacks. For example, QC (quantum cryptography) requires you to pick the polarization basis randomly. If you don't pick it randomly enough then there's a bias that could potentially be exploited by an attacker. And it's difficult to be random at high speeds, so QC will probably be limited to slow speeds, at least at first.
The real problem with QC is that it requires a point-to-point transaction, with no repeaters. So it doesn't really work with the internet. Still, it could be useful for Whitehouse-to-Pentagon communications, or other similar setups.
One reason to disable the Ctrl-Alt-Del entry is to prevent accidental reboots. Yes, it can happen. Especially if the admins also manage Windows machines. I now habitually hit CAD while sitting down, simply because I need to do it so often in order to log in or unlock my screensaver on a Windows box. And it would really suck to reboot your server due to such a trivial mistake.
In any case, what use does CAD serve? You can always become root and type "reboot", right? Unless, of course, the machine is horribly hung, in which case CAD probably wouldn't do you much good anyway.
It's now been several days since the uselib() kernel exploit was posted and reports started to trickle in that it works. But there is no patch from the RedHat (or any other vendor, from what I've seen). What gives? Anyone got the inside scoop on what these vendors are saying on vendor-sec?
The fact that it doesn't even show up in bugzilla makes me think it's still under embargo for some reason. Shouldn't the leak be sufficient reason to change their timeline? For those of us running production servers, this waiting game is more than a little inconvenient.
On a side note, from what I've seen, the exploit has only been demonstrated on uniprocessor 2.4 kernels. Anyone get it to work on an SMP kernel, or a 2.6 kernel?
Right... I haven't gotten it to work under RHEL3 or RH9, both using SMP kernels. Note that's true even if there's only one processor (no HT) in the machine.
I think you'll find the percentage depends a lot more on how much ham they receive than how much spam they receive. For example, if I got 100 spams/day, I'd be happy. Given my 300 hams/day, that would put me at 25%. But others, who get only 10 hams/day, would claim seeing 91% spam. Maybe counting raw spams per account would be a more useful metric.
I think it was at the 1994 Belmont Stakes I saw my dad tie two Nikon cameras together. Each shot at 6 fps (which was pretty good back then) for a total of 12 fps. Nice to see the researchers are picking up on the ideas of the old pros.
A more recent application is the "bullet time" developed for "The Matrix" movies.
Nothing has changed... a 5xx rejection is given if the receiving machine can make the decision. The problem is there are frequently mail relays before the final destination, and they might not know whether they can reject. Making the decision as far upstream as possible is the only answer.
If you run the M$ software, it will automagically be updated when patches come out. What happens with Firefox? Does it check for updates and warn you when they're available? Or are you expected to remember to check for security patches regularly?
The project you're looking for is called StegFS. Google for it. Cool stuff, but unfortunately is a massive waste of CPU and Disk unless you REALLY need it.
Slashdot Mirror
It's called clamuko. Not that I've ever had a reason to use it. I think it might be unreliable still, so be careful.
I run Fedora on my laptop, and it works pretty well for me. But the stability isn't good enough for production. We use RHEL for that.
Fighting the FUD....
No, they didn't. No hash has been produced. Only a claim that they can do it in 2^69 operations. The collisions they gave were for SHA-0 and for a reduced-round version (58 rounds instead of 80) of SHA-1. Unless someone can extend the break (which is likely) then it's still quite secure.
- Do you have 5+ years of sysadmin experience?
- Do you have 100+ users?
- Do you have 10+ machines?
- Do you have to support enterprise applications?
Seriously, if you can't answer "yes" to all four questions, perhaps you should just keep your opinions to yourselves. The other distros are great for your mommy's basement, but in the enterprise, there are serious support/stability issues to consider.You should learn to use Google.
I see in sendmail a MaxRecipientsPerMessage option, which would prevent an infected client from specifying too many RCPT addresses. (It's not clear to me what happens if we have a mailing list with > MaxRecipientsPerMessage subscribers, though.)
What I don't see is an option to limit based on messages per hour. Does anyone know if this exists within sendmail? Or do you need separate monitoring software for that?
Not hard... in fact, we recently went through the process with our users. The trick to "convincing" them is to not give them a choice. Enable SMTP AUTH, and disable all relaying without it. Yes, a few won't change their settings before you disable the IP-based relaying, but that all gets resolved in one day. Not a big deal.
Same strategy worked well for the telnet/ftp to ssh/sftp conversion and the pop/imap to pop3s/imaps conversion.
Something sysadmins (and ISPs) need to learn is that it's our job to protect the users, even from themselves. Spending 5 minutes showing them how to do things in a more secure way is worth it -- taking a chance that their account will be compromised is just too risky.
Gah, sad. I thought you were asking what the words were for the above-posted binary coded ascii. Wasn't till I'd translated the entire thing, and re-read your post, that I discovered the truth.
It's easy to say you don't get spam to your inbox. It's much harder to say you aren't missing anything important. Hence the problem.
Seriously. It seems like it shouldn't be that hard, but it is. So let's solve it already!
The infamous "netsky" viruses were released by a group calling itself "Sky Net".
It's a real nightmare for sysadmins trying to figure out if their software blocks a certain threat, when each A/V vendor picks their own name. Many of those names are selected independently, and it's understandable that they don't want to change their names after they've released their updates. So, the obvious solution is to have the virus-writers come up with unique names which are easily identified, and for all the A/V vendors to use them. Yes, it means you encourage their ego. But really, who cares? It'd simplify everything else. I think it's worth it.
Agreed. I considered a switch to dvorak back in college. I actually got to the point where I could type without looking at the keys, and was doing maybe 10 wpm (which sucks, but it's over the hump of the learning curve). Then I realized that it completely broke may things, like the ctrl-c, ctrl-v thing, or the placement of j and k for scrolling in vi. As it turns out, the querty format has strongly influenced the design of many software products. It just isn't worth it to switch anymore.
Did they somehow know that they'd forgotten to flip the switch before any data was transmitted?
Or maybe the transmit time was several days, and they only missed the first few hours?
Just trying to make sense out of this, since the journalists obviously don't have a clue. Hopefully someone who worked on the project can respond.
What two guys? And the uncertainty principle doesn't say that at all.
So, if one were to attempt to 'brute force' attack a quantum crypto-stream, one would have to have had to receive a copy of that stream before it hit the 'quantum wire', ie before it reached the point where quantum mechanics superceded the laws of the seeable, knowable universe.
There is no "before". The photons are entangled at the moment of their creation.
Not impossible, but not likely either.
Actually, it is impossible. Unless quantum mechanics is a flawed theory, of course.
Once again, Slashdot and it's readers manages to fuck up a fantastic article written months in print.
Looks like you assholes need to learn how to read.
Actually, to be honest, I didn't read the article before responding. But that's probably because I was doing research in quantum computers back in 1996-97, and didn't feel that there were any major changes in the foundations since then. And I've known the details of quantum cryptography since about 2001, when I had an interesting chat with a researcher in that field.
But, just to humor you, I read the article. And now I know that there are two companies selling products. Which is rather amusing, because I would guess those products to be snake oil. As I'd mentioned in the grandparent post, it's very difficult to randomly select a polarization basis randomly at a high bitrate. I don't believe this issue has been resolved yet, so I would be wary of any products claiming perfect security.
Nice troll, BTW.
No, we won't. It's an interesting thought, but it doesn't work that way. According to the laws of physics (as we currently understand them) quantum encryption, if done properly, is provably secure. That is, there is no way to break the encryption, unless quantum mechanics itself is flawed.
Of course, there are other attacks. For example, QC (quantum cryptography) requires you to pick the polarization basis randomly. If you don't pick it randomly enough then there's a bias that could potentially be exploited by an attacker. And it's difficult to be random at high speeds, so QC will probably be limited to slow speeds, at least at first.
The real problem with QC is that it requires a point-to-point transaction, with no repeaters. So it doesn't really work with the internet. Still, it could be useful for Whitehouse-to-Pentagon communications, or other similar setups.
In any case, what use does CAD serve? You can always become root and type "reboot", right? Unless, of course, the machine is horribly hung, in which case CAD probably wouldn't do you much good anyway.
Usually we make fun of these extremist geeks by saying they'll never get laid. In this case, I think it's a given. Public indecency laws....
The fact that it doesn't even show up in bugzilla makes me think it's still under embargo for some reason. Shouldn't the leak be sufficient reason to change their timeline? For those of us running production servers, this waiting game is more than a little inconvenient.
On a side note, from what I've seen, the exploit has only been demonstrated on uniprocessor 2.4 kernels. Anyone get it to work on an SMP kernel, or a 2.6 kernel?
Right... I haven't gotten it to work under RHEL3 or RH9, both using SMP kernels. Note that's true even if there's only one processor (no HT) in the machine.
To get a rough idea of trends, I've been plotting stats on a mailserver I manage. In general, we see spam and viruses are increasing, while ham is decreasing. Spam is about 67% of incoming mail.
I also plot my personal spam stats but obviously an individual account is hardly representative.
A more recent application is the "bullet time" developed for "The Matrix" movies.
Nothing has changed... a 5xx rejection is given if the receiving machine can make the decision. The problem is there are frequently mail relays before the final destination, and they might not know whether they can reject. Making the decision as far upstream as possible is the only answer.
For the average person this is a huge issue.
The project you're looking for is called StegFS. Google for it. Cool stuff, but unfortunately is a massive waste of CPU and Disk unless you REALLY need it.