Well, slashdot insists on word-wrapping this,
making the link unusable, sorry.
Here's the address, cut and paste it together
yourself:
http://a1376.g.akamai.net/7/1376/2064/OpenOffice60 5/anoncvs.openoffice.org/download/
OpenOffice605/oo_605_src.tar.gz
Doesn't seem too excitingly original to me. Just a variation on having a backup web server located at another datacenter, and directing DNS to the backup web server when the primary gets attacked. Lots of other posts have already pointed out the faults with this basic mechanism (like the 0 DNS TTL??? there goes your DNS server. A few minutes would be a bit more reasonable. Plus, if the DDOS checks DNS every once in a while, they can attack both).
The only difference with this is it requires just one server machine instead of a primary and a backup, with the same trick of changing DNS, but also directing away the old route. So you save a little money - just need one server, one ISP, etc. Then again, this is only a benefit if you're not willing to just buy two servers, co-lo them at two different datacenters, stick your DNS servers at a third datacenter, and be done with it. And if you're not willing to do that, you're probably going for a cheap ISP who'll get overloaded by the attack, making this whole method useless anyway.
While I agree that this is pretty useless for your general purpose desktop, this is useful for real-time systems.
People would love to write programs for such systems using a high-level language like Java or C++. The main issue is that real-time systems must be able to deterministically predict how long any operation will take. Problem is, with current implementations of runtimes, the garbage collector could kick in at any time and take some arbitrary amount of time to finish, totally messing things up.
Lets say you've got a software-controlled robot arm, putting together a car or something (cheesy example). A start command is executed, and the arm begins moving. Then, right before the stop command was supposed to be executed, in comes your garbage collector. It does its thing and finishes, and the stop command executes - 50 milliseconds too late, putting the arm out of position. Oops - I hope you weren't planning on selling that car.
But if you can deterministically predict when and how long all of the operations will take, voila, you can just take them into account when scheduling what happens and everything is all hunky-dory. The hardware part of it is a bit of a distraction I think - the deterministic part is what's cool.
A lot of companies encourage their employees to patent anything that is vaguely related to their field, in the hopes that it either will be useful to them for future products, or will at least give them another income stream from royalties, even if they never use it themselves. So extrapolating product functionality from a companies patents is sketchy at best - it may just be easier to get the patent and let someone else build it.
The countries owning those country codes in most cases have given their permission for them to be used globally, typically because the country is small enough to have no real need for them. And usually said country is making a good chunk of change on the side from this too.
It's just naming schemes - nothing worth getting disgusted or losing sleep over:). And if it helps make names easier to remember - well that's the whole point of not just spewing out IP addresses in the first place, right?
Check your RFCs. ORG was never for "non-profits" only. It was deemed as the miscellaneous category for people who didn't fit into INT, EDU, GOV, MIL, NET, or COM.
Here's the snippet from RFC 1591, written by Jon Postel himself:
"ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non-government organizations may fit here."
Read the two articles for yourself. No mention is made of them having the keys in them - for all we know they could just be hardware implementations of RSA/DH/whatever.
It's no secret that public/private key operations are slow, even today. Without special hardware, you can't get an SSL web server to keep up with a very heavy load at all. If you imagine a future where even clients may be doing dozens of these operations a second, then having such a chip in every pc would be useful.
Unfortunately, there currently isn't enough information to really know what is going on with this chip, so at least lets not jump to conclusions and burn IBM at the stake now...
(side note: as others have said, if you don't want a unique ID in your computer, you better get rid of that ethernet card...)
The MIT project you are thinking of is probably the RAW project. The web site is a bit sparse - not much more than a list of all of the groups research papers. You can get a bit more info about the project in the latest Scientific American in the section about MIT's Oxygen project (hey the article is actually online too - go read it here. Note that it is aimed at the general public, so it's on the simplistic side).
I was just trying to grok it too. Best as I can tell, this patent describes setting aside two "special" registers which it uses to cache a memory address and the data at that address.
The interesting part comes when it detects an access to that memory address - it then goes ahead and rewrites the next block of instructions, so that they use the special data register instead of a memory access to load/store the data (and dealing with keeping memory up to date in the background I guess - the patent seems a bit vague on this, as well as on how it chooses which memory address and data to store in those two registers initially).
Interesting idea, but I'm worried that the patent may be a bit vague on some points... as given, this method isn't guaranteed to work on SMP systems...
I'm always interested to know if anyone was able to glean more out of the patent, or find problems with my own description. =)
If you've been broken into, first thing you should do is take it off the network ASAP. Then, if you like, you can try and track down where he came from by looking through the logs. Note though that most script kiddy root kits do a pretty decent job of covering their tracks once they get in. And really, finding the little twerp should be secondary to getting your own machine online again.
This is where you demonstrated the greatest failure - your system has been compromised, so as far as you should be concerned, every binary is untrustworthy now. ls could have been modified to not show their files, ps modified to not show their processes, and there's probably a number of setuid root bash binaries lying around. The only truly safe thing to do is reinstall the OS from scratch - trying to track down all of their modifications is a waste of time, and you'll probably miss a few anyways, with potentially disastrous results.
In the future, it's always worthwhile to invest in tape backups (if you can afford the server, surely you can spare about $200 more? this doesn't have to be some super-automated DDS3 drive...), and to keep up to date with security patches.
Slashdot Mirror
Well, slashdot insists on word-wrapping this, making the link unusable, sorry.0 5/anoncvs.openoffice.org/download/
Here's the address, cut and paste it together yourself:
http://a1376.g.akamai.net/7/1376/2064/OpenOffice6
OpenOffice605/oo_605_src.tar.gz
You can download the source tarball from this address:0 5/anoncvs.openoffice.org/download/OpenOf fice605/oo_605_src.tar.gz
http://a1376.g.akamai.net/7/1376/2064/OpenOffice6
Enjoy
The only difference with this is it requires just one server machine instead of a primary and a backup, with the same trick of changing DNS, but also directing away the old route. So you save a little money - just need one server, one ISP, etc. Then again, this is only a benefit if you're not willing to just buy two servers, co-lo them at two different datacenters, stick your DNS servers at a third datacenter, and be done with it. And if you're not willing to do that, you're probably going for a cheap ISP who'll get overloaded by the attack, making this whole method useless anyway.
Just my two cents.
-Andy
People would love to write programs for such systems using a high-level language like Java or C++. The main issue is that real-time systems must be able to deterministically predict how long any operation will take. Problem is, with current implementations of runtimes, the garbage collector could kick in at any time and take some arbitrary amount of time to finish, totally messing things up.
Lets say you've got a software-controlled robot arm, putting together a car or something (cheesy example). A start command is executed, and the arm begins moving. Then, right before the stop command was supposed to be executed, in comes your garbage collector. It does its thing and finishes, and the stop command executes - 50 milliseconds too late, putting the arm out of position. Oops - I hope you weren't planning on selling that car.
But if you can deterministically predict when and how long all of the operations will take, voila, you can just take them into account when scheduling what happens and everything is all hunky-dory. The hardware part of it is a bit of a distraction I think - the deterministic part is what's cool.
A lot of companies encourage their employees to patent anything that is vaguely related to their field, in the hopes that it either will be useful to them for future products, or will at least give them another income stream from royalties, even if they never use it themselves. So extrapolating product functionality from a companies patents is sketchy at best - it may just be easier to get the patent and let someone else build it.
The countries owning those country codes in most cases have given their permission for them to be used globally, typically because the country is small enough to have no real need for them. And usually said country is making a good chunk of change on the side from this too.
It's just naming schemes - nothing worth getting disgusted or losing sleep over :). And if it helps make names easier to remember - well that's the whole point of not just spewing out IP addresses in the first place, right?
Here's the snippet from RFC 1591, written by Jon Postel himself:
"ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non-government organizations may fit here."
It's no secret that public/private key operations are slow, even today. Without special hardware, you can't get an SSL web server to keep up with a very heavy load at all. If you imagine a future where even clients may be doing dozens of these operations a second, then having such a chip in every pc would be useful.
Unfortunately, there currently isn't enough information to really know what is going on with this chip, so at least lets not jump to conclusions and burn IBM at the stake now...
(side note: as others have said, if you don't want a unique ID in your computer, you better get rid of that ethernet card...)
The MIT project you are thinking of is probably the RAW project. The web site is a bit sparse - not much more than a list of all of the groups research papers. You can get a bit more info about the project in the latest Scientific American in the section about MIT's Oxygen project (hey the article is actually online too - go read it here. Note that it is aimed at the general public, so it's on the simplistic side).
I was just trying to grok it too. Best as I can tell, this patent describes setting aside two "special" registers which it uses to cache a memory address and the data at that address.
The interesting part comes when it detects an access to that memory address - it then goes ahead and rewrites the next block of instructions, so that they use the special data register instead of a memory access to load/store the data (and dealing with keeping memory up to date in the background I guess - the patent seems a bit vague on this, as well as on how it chooses which memory address and data to store in those two registers initially).
Interesting idea, but I'm worried that the patent may be a bit vague on some points... as given, this method isn't guaranteed to work on SMP systems...
I'm always interested to know if anyone was able to glean more out of the patent, or find problems with my own description. =)
This is where you demonstrated the greatest failure - your system has been compromised, so as far as you should be concerned, every binary is untrustworthy now. ls could have been modified to not show their files, ps modified to not show their processes, and there's probably a number of setuid root bash binaries lying around. The only truly safe thing to do is reinstall the OS from scratch - trying to track down all of their modifications is a waste of time, and you'll probably miss a few anyways, with potentially disastrous results.
In the future, it's always worthwhile to invest in tape backups (if you can afford the server, surely you can spare about $200 more? this doesn't have to be some super-automated DDS3 drive...), and to keep up to date with security patches.