If you don't replicate the bugs in something like Samba you run the risk of your clone being incompatible with the original.
Of course that is true as long as the bugs are in the protocol. But it does not apply to exploits. Just because there are exploits in the original, you don't need to replicate those for compatibility.
The only reason not to update, is if you haven't QA'd (burn in test) your new kernel.
There is no reason not to update. But of course some QA first would make sense for a production system. Review the patch, and test it on a nonproduction system. But don't wait many days before upgrading. The ptrace feature is not very important to production systems, so you wouldn't expect much to break. The flaw OTOH can potentially be a major problem. My uptime when I read this on/. was more than 22 hours - with an updated kernel.
Microsoft would have a monopoly on privilege escalation exploits
No, Microsoft has a bulletproof way to prevent privilege escalations. They simply make sure the attacker gets all privileges at once, then there is nothing to escalate.
I must admit, I like my 'closed' phone. I know it won't crash.
Yeah right. My "SAGEM MC 820" was so horrible it made me really want an open phone. Not that an open phone would solve all the problems, but it would solve some of them. Crappy hardware is crappy no matter how good software you install on it.
The 820 would in fact crash if you typed too fast on the keypad. And the user interface design was braindead. Those two problems could be solved by an open implementation. The fact that it spontaneously turned off at random times might be a hardware problem that couldn't have been solved by replacing the software.
If I knew the Exact time your system last booted, and the Exact time you generated the password
You are wrong. The kernel uses a 4096bit seed, and it combines random input from different sources including the timing of keyboard and mouse input. And the seed is saved at system shutdown and restored during boot. In total this means you need to know the exact keypresses and mouse movements I made in the two years passing from when I installed the system and until I generated the password. My password is truly random.
Maybe you're just oversyplifying, but wouldn't this charge me only for outbound data (like HTTP GET requests) and not for the gigabytes of pr0n I download every day?
Sounds like that would almost be the case. However if you only send the GET request, you are not going to get much pr0n. If the server doesn't get some ACKs it will stop sending. For TCP it would be better if the ISP does connection tracking. They can then take payment for any connection you initialize, and for any incomming connection which you accept with a SYN ACK packet. OTOH unexpected incomming packets that you reject with a RST packet should be free, and the RST packets should also be free. But not all traffic on the net is TCP, for other protocols it is more tricky to compute a fair payment. I'd say the remaining outgoing packets should be chared double, because there is probably going to be a response for each. Except from the cases where you send an ICMP response for an incomming packet, those should be free. Sure, this sounds complicated, but I guess that is as fair as you can do it.
I run a SMTP honeypot on my computer. It accepts any incomming mail but doesn't deliver it anywhere. Some time ago a person misconfigured his computer so it would send lots of his own outgoing mail to me. To make this even more funny he got infected by a virus that produced lots of outgoing emails with random files attached. I got a few cached HTML documents from hotmail, including one email containing his username and password for a datingsite.
Why is it such a pain to run multiple X Servers on a single Linux box?
It is unclear what you are talking about. It could be multiple instances of XFree86 on a single computer. I can do that on one of my computers, but not on the other, unfortunately I don't know what makes the difference. If OTOH you are actually talking about connecting X terminals like the NCD to a Linux box, I must unfortunately say that is something I have litle experience with, but it certainly is possible.
How do you actually define a percent of the traffic? Is there some requirement to how far the traffic must go? When I access files on an NFS server on our local net, does that count as internet traffic? (Both server and client has a real IP address i.e. not RFC 1918.) Perhaps not. Then how about me accessing computers on other universities through the the university-network, does that count as internet traffic? How about when I access messages on our newsserver which is somewhere on the university-network, does that count as internet traffic? How about when I post something, does that count? How about postings that nobody ever read? (But that might not be possible.) How about when I tunnel most of my traffic through ssh to the university, does that count twice? (Or more because of the blowup in size because of me using X11 forwarding, or does X11 forwarding not count even if used to display pr0n?) And how would you find out what I was portforwarding anyway? And if you do not think access to a local newsserver acrosss the university network counts, then how about access to a local newsserver at an ISP? And does all traffic count equal no matter how far it goes? And does lost packets count? Do they count twice when retransmitted? I could come up with a lot more questions, in all it is nontrivial to define the percentage, which is a requirement before you can attempt to meassure it. It really is important, because I believe the most packets being send are in fact not traveling very far, and never leaves the local network.
And exactly how was less not functional? It'll work without any terminal capabilities
Even without knowing anything about the terminal, less will try to display a status line at the bottom of the display. Unfortunately it fails to get that status line removed when scrolling. The result is, that the status line will be clutering up the display.
Don't do that. I have tried loging in remote to such a system and were having problems with my terminal. (I don't remember if this was a TERM environment problem, or broken terminal emulation.) Either way I had to use more, because less wouldn't work. However somebody had found it a good idea to make more an alias for lessand replace more with a symlink to less.
copy/pasted the admin password over the root password.
I don't know what system you are talking about, but my system surely doesn't have any kind of admin password, only a root password here.
This is what normal people asssociate with password recovery
Oh yeah? I don't see a logical reason why anybody would think password recovery would mean anything else than finding out what the password is.
There is a limit to the types of characters, and the number that can be used in a unix password.
Sure with systems still using DES based passwords there might be an issue. But with MD5 based passwords, this is not really a problem.
most likely root passwords
I take 16 chars from/dev/urandom, what password is the most likely then?
Of course I don't. But don't tell that to the spammers, because I try to make them believe I do have an open delay. Then they can send their junk to my blackhole where it does no harm.
I have a SparQ drive connected to a parallel port. (Had I known what piece of crap it was, I'd never have bought it.) The documentation says it cannot eject from software. Before I got my first Linux computer, I tested the drive on a friends Linux computer. He had not read the documentation, so he just used the eject command. To my surprise it actually worked.
If you have physical access to a machine then yes, root password recovery takes 10-15 minutes.
There are lots of things you can easilly do with physical access to the computer, but finding the root password is not one of them. Unless something has been done to prevent it, I can bypass the root password in less than five minutes. Either pass an init argument to the kernel or boot from external media. Once the root password has been bypassed it can easilly be changed if I would want to.
Preventing boot from external media and boot arguments will slow down the process, and of course BIOS and bootloader must be password protected. But I can get a long way with a screwdriver unless the harddisk has been encrypted.
In case you want to prove your claim, please tell me what my root password is. Here is the line from my/etc/shadow file:
Some years ago I managed to make an xterm dump core simply by typing the contents of a binary file, which did not contain any malicious data, it just be coincidence contained a byte sequence that would cause xterm to dump core. Investigating this I found, that some sequence of 24 bytes was responsible. But if I made the xterm window larger, it would not crash from this sequence, however it turned out the original file contained another longer sequence that could also make a larger xterm dump core. I never actually understood exactly what was going on, but I found that later xterm versions does not crash from the sequences I saved from back then.
Slashdot Mirror
If you don't replicate the bugs in something like Samba you run the risk of your clone being incompatible with the original.
Of course that is true as long as the bugs are in the protocol. But it does not apply to exploits. Just because there are exploits in the original, you don't need to replicate those for compatibility.
The only reason not to update, is if you haven't QA'd (burn in test) your new kernel.
/. was more than 22 hours - with an updated kernel.
There is no reason not to update. But of course some QA first would make sense for a production system. Review the patch, and test it on a nonproduction system. But don't wait many days before upgrading. The ptrace feature is not very important to production systems, so you wouldn't expect much to break. The flaw OTOH can potentially be a major problem. My uptime when I read this on
Microsoft would have a monopoly on privilege escalation exploits
No, Microsoft has a bulletproof way to prevent privilege escalations. They simply make sure the attacker gets all privileges at once, then there is nothing to escalate.
I'm switching back to Morse Code.
Then I recomend Linux. With appropriate patches you can get the error message in morse code in case of a kernel panic.
Thank god that cd doesn't have a recursive switch.
If I knew what you'd expect from such a feature, I'd have implemented it.
I must admit, I like my 'closed' phone. I know it won't crash.
Yeah right. My "SAGEM MC 820" was so horrible it made me really want an open phone. Not that an open phone would solve all the problems, but it would solve some of them. Crappy hardware is crappy no matter how good software you install on it.
The 820 would in fact crash if you typed too fast on the keypad. And the user interface design was braindead. Those two problems could be solved by an open implementation. The fact that it spontaneously turned off at random times might be a hardware problem that couldn't have been solved by replacing the software.
If I knew the Exact time your system last booted, and the Exact time you generated the password
You are wrong. The kernel uses a 4096bit seed, and it combines random input from different sources including the timing of keyboard and mouse input. And the seed is saved at system shutdown and restored during boot. In total this means you need to know the exact keypresses and mouse movements I made in the two years passing from when I installed the system and until I generated the password. My password is truly random.
Maybe you're just oversyplifying, but wouldn't this charge me only for outbound data (like HTTP GET requests) and not for the gigabytes of pr0n I download every day?
Sounds like that would almost be the case. However if you only send the GET request, you are not going to get much pr0n. If the server doesn't get some ACKs it will stop sending. For TCP it would be better if the ISP does connection tracking. They can then take payment for any connection you initialize, and for any incomming connection which you accept with a SYN ACK packet. OTOH unexpected incomming packets that you reject with a RST packet should be free, and the RST packets should also be free. But not all traffic on the net is TCP, for other protocols it is more tricky to compute a fair payment. I'd say the remaining outgoing packets should be chared double, because there is probably going to be a response for each. Except from the cases where you send an ICMP response for an incomming packet, those should be free. Sure, this sounds complicated, but I guess that is as fair as you can do it.
How did you get into my hotmail account?
I run a SMTP honeypot on my computer. It accepts any incomming mail but doesn't deliver it anywhere. Some time ago a person misconfigured his computer so it would send lots of his own outgoing mail to me. To make this even more funny he got infected by a virus that produced lots of outgoing emails with random files attached. I got a few cached HTML documents from hotmail, including one email containing his username and password for a datingsite.
Haven't you even seen the movie hackers?
Yes.
The one thing they got right in that movie was the top three most commonly used passwords.
They didn't get much right. And I'm not so sure about that part with the passwords. Personally I'd never use such insecure passwords.
"bEnDoVeRtAkEiTlIkEaMaN!"
That is not my password.
high-end Unix boxes are powerful enough to run emulators, right?
I doubt any emulator on a high-end Unix box could match the speed of VMware on IA32 Linux.
I think everything but the kitchen sink is installed with Linux
That might soon be fixed with mozilla.
Why is it such a pain to run multiple X Servers on a single Linux box?
It is unclear what you are talking about. It could be multiple instances of XFree86 on a single computer. I can do that on one of my computers, but not on the other, unfortunately I don't know what makes the difference. If OTOH you are actually talking about connecting X terminals like the NCD to a Linux box, I must unfortunately say that is something I have litle experience with, but it certainly is possible.
How do you actually define a percent of the traffic? Is there some requirement to how far the traffic must go? When I access files on an NFS server on our local net, does that count as internet traffic? (Both server and client has a real IP address i.e. not RFC 1918.) Perhaps not. Then how about me accessing computers on other universities through the the university-network, does that count as internet traffic? How about when I access messages on our newsserver which is somewhere on the university-network, does that count as internet traffic? How about when I post something, does that count? How about postings that nobody ever read? (But that might not be possible.) How about when I tunnel most of my traffic through ssh to the university, does that count twice? (Or more because of the blowup in size because of me using X11 forwarding, or does X11 forwarding not count even if used to display pr0n?) And how would you find out what I was portforwarding anyway? And if you do not think access to a local newsserver acrosss the university network counts, then how about access to a local newsserver at an ISP? And does all traffic count equal no matter how far it goes? And does lost packets count? Do they count twice when retransmitted? I could come up with a lot more questions, in all it is nontrivial to define the percentage, which is a requirement before you can attempt to meassure it. It really is important, because I believe the most packets being send are in fact not traveling very far, and never leaves the local network.
since the test mail would fall into a black hole
Well, the hole wasn't completely black. They really end up on my harddisk where I occationally pick up a few tests and allow them to be relayed.
And exactly how was less not functional? It'll work without any terminal capabilities
Even without knowing anything about the terminal, less will try to display a status line at the bottom of the display. Unfortunately it fails to get that status line removed when scrolling. The result is, that the status line will be clutering up the display.
Or replace more with a link to less.
Don't do that. I have tried loging in remote to such a system and were having problems with my terminal. (I don't remember if this was a TERM environment problem, or broken terminal emulation.) Either way I had to use more, because less wouldn't work. However somebody had found it a good idea to make more an alias for less and replace more with a symlink to less.
Does this actually work?
I have received 50 million spammails that way.
try to use it to send a mail to myself...
I can tell the difference between a test mail and a spam mail.
copy/pasted the admin password over the root password.
/dev/urandom, what password is the most likely then?
I don't know what system you are talking about, but my system surely doesn't have any kind of admin password, only a root password here.
This is what normal people asssociate with password recovery
Oh yeah? I don't see a logical reason why anybody would think password recovery would mean anything else than finding out what the password is.
There is a limit to the types of characters, and the number that can be used in a unix password.
Sure with systems still using DES based passwords there might be an issue. But with MD5 based passwords, this is not really a problem.
most likely root passwords
I take 16 chars from
And you don't run an open relay, do you? Do you?
Of course I don't. But don't tell that to the spammers, because I try to make them believe I do have an open delay. Then they can send their junk to my blackhole where it does no harm.
eject from linux
I have a SparQ drive connected to a parallel port. (Had I known what piece of crap it was, I'd never have bought it.) The documentation says it cannot eject from software. Before I got my first Linux computer, I tested the drive on a friends Linux computer. He had not read the documentation, so he just used the eject command. To my surprise it actually worked.
mount -o remount,rw -t (root fs type) (root fs device) /
/. And I don't think you need /proc to change the root password.
Why make it so complicated? I'd just have typed: mount -o remount,rw
There are lots of things you can easilly do with physical access to the computer, but finding the root password is not one of them. Unless something has been done to prevent it, I can bypass the root password in less than five minutes. Either pass an init argument to the kernel or boot from external media. Once the root password has been bypassed it can easilly be changed if I would want to.
Preventing boot from external media and boot arguments will slow down the process, and of course BIOS and bootloader must be password protected. But I can get a long way with a screwdriver unless the harddisk has been encrypted.
In case you want to prove your claim, please tell me what my root password is. Here is the line from my
Some years ago I managed to make an xterm dump core simply by typing the contents of a binary file, which did not contain any malicious data, it just be coincidence contained a byte sequence that would cause xterm to dump core. Investigating this I found, that some sequence of 24 bytes was responsible. But if I made the xterm window larger, it would not crash from this sequence, however it turned out the original file contained another longer sequence that could also make a larger xterm dump core. I never actually understood exactly what was going on, but I found that later xterm versions does not crash from the sequences I saved from back then.