Here is a suggestion that would allow computers that are not in use to be "co-opted" for use in the cluster.
Identify the PC's that COULD theoretically be used, and collect their MAC addresses. Also, configure them to try netboot first, then fall back to booting from the hard drive.
When you want to perform computations, send a WakeOnLAN packet targeted to each of these computers. Wait for netboot solicitations, then, if you have recently sent a WOL packet to that computer, respond with an appropriate netboot directive, booting the PC into a cluster node configuration, with all details loaded from the cluster director.
Otherwise, allow the netboot solicitation to time out, and the computer will boot into its normal configuration.
Not sure how OpenMosix handles nodes that simply vanish, but users could simply reboot the PC when they arrive in the morning, if the computation is still ongoing. Otherwise, the cluster director could remote shutdown/reboot each node prior to the user arriving at work.
Unused PC's would not consume power, cluster node PC's could be instructed to immediately drop the monitor into Power-save mode, etc.
The cluster director could decide how many nodes to start, or the location of the nodes, to optimise the comms between it and the servers.
... has solved this problem more than 6 years ago. And it does not require the password to be stored in clear-text by the server. (although, "with a little thought", according to the article, neither does this scheme. BAH! Proof is left as an excercise for the reader)
Stick with something that has been rigorously reviewed, and proven over a period of time. And something that can be explained simply, in terms of the actual technology, rather than resorting to pathetic analogies that do not explain anything!
If you look up www.bank.com, receive a wrong IP address from the DNS server (e.g. dnsspoof), and connect to it, your browser will warn you that the certificate does not match the name. (Note that if the attacker is using dnsspoof, using a local DNS server will not necessarily protect you from this)
If you ignore this warning, you deserve everything you get.
It is not so easy to get around this problem, other than: a) brute forcing the server's SSL cert to get the private key (a HARD problem) b) stealing a copy of the cert by hacking the bank's webserver. (Hopefully also a HARD problem), or c) getting your own CA cert installed into the victim's browser (maybe not *that* difficult, but still not trivial)
Anyone who thinks that SSL is *INSECURE* needs to understand the protocol better.
Sounds more like a window manager problem to me. If your window manager does not give focus to the windows in the order that you like, configure it to, or choose a different one that does.
Don't assume that because they are buzzword compliant (AES 256-bit encryption!!!) that they have implemented it correctly.
That was the first mistake which led to all the war-driving originally - early WEP implementations used good algorithms, but chose a weak Initialisation Vector, which made it easier to decrypt the traffic.
Let's hope that they've learned their lesson this time, and aren't just trying to get people on the upgrade cycle again - WEP -> WPA -> WPA2 -> when will it stop?!
Note that you have to have physical access to get into the box. i.e physically disconnecting the hard drive, and mounting it on another host, in order to set the root password.
And I'm pretty sure that you need to have the admin password to enable telnet in the first place, too.
This attack works through proxies, because the proxy will simply relay a well-formed DNS request straight to the attackers DNS server, and return the well-formed DNS response back to the client.
Read the slides. It's quite impressive, even if it has also been known for a large number of years. No, Dan is not the first to realise the potential of this.
About 10 years back we had a DEC field service rep working on one of our systems and the talk turned to the copious amount of dust in the fans and air filters (yeah, screw clean DP rooms, it's the paper dust more than anything!) and he brought up a service call to GM's Central Foundry in Saginaw, Michigan.
Seems some system stopped functioning and everyone started scratching their heads, trying to figure out what ran it. Finally an electician was brought in with wiring diagrams and found there was actually a DEC PDP 8 (yeah, one of those things) which controlled the system. They found it had been build around and buried behind HVAC ducts, pipes and conduits. Once they cut their way in to it, the field service rep cleaned out solid packed dust and grime, having to replace an 8" floppy, and reboot it from a backup disk.
After they got another boot disk and told how ancient their system was, they responded something along the lines of, "Well if it ran for 15 years and we didn't even know it was there, why replace it?" Indeed.
Slow down, cowboy. Thawte has been offering free personal certificates for at least 5 years already, along with a "Web of Trust" that allows for distributed certification of identity, exactly as this group is doing.
Admittedly, these are not usable as server certs (I think), but don't be so quick to slam things you wot not of.
It sounds like you already know what it is that you need to do, but are looking for implementation ideas.
Couple of thoughts:
LD_PRELOAD might help you to override open, seek, read, etc calls. You can probably do a HEAD on the URL to get the actual size of the MP3, without downloading the entire file and fake stat results from that.
Seek and read can be faked with Byte-Ranges, as you have already indicated.
Problems that I see are convincing the application to open "http://host:port/path" using the filesystem, and not spewing immediately.
I'm thinking that extending the python code that you have is probably going to be the easiest.
Why not? Would you prefer MP3, perhaps or Ogg Vorbis?
What's better than an uncompressed format for this sort of archival work? I don't think there was any mention of the sample rate in the article, but it seems to me that they could make it as high as they want to, given that they are generating it from a model of an analogue system.
Obviously they are limited by the resolution of their scans, and the quality of their model, but it seems from the story that they have got both right already.
MD5Crk.com has an applet on their site that does distributed calculations so long as it is visible in the browser (and assuming that you have specifically permitted it to do so). They are trying to find a collision to demonstrate that MD5 is insecure.
This is great for a simple calculation that returns simple results (e.g.MD5), but probably wouldn't work in a situation where you have to have lots of data to work from. Of course, if you can break it down sufficiently, it might work, and I guess he has already done the work in figuring out how to break it down and recombine the results.
This looks just like the Virtual Server project that Jacques Gelinas started a number of years ago. Possibly with some neat configuration utilities, but much the same. I'm not sure whether VServers can be allocated a dedicated CPU, or certain hardware exclusively, etc, but I think it can.
Xen, on the other hand is a much "heavier" approach, similar to VMWare, which virtualises the hardware, and emulates certain peripherals.
ssh access is all you really need to execute X11 commands. Install Cygwin and Xfree86 if Exceed is too complex. Then SSH in to the box, and check what your DISPLAY variable is set to (echo $DISPLAY). It should point back to your IP address (or hostname), followed by:0.0
if it is not, do "export DISPLAY=your.ip:0.0" and execute an xterm, or start gnome, or do whatever you want to.
You mean something like the 2.6.0-test series? Which started with the following post, 5 months before the final 2.6.0 was released: Linus Torvalds: Linux 2.6.0-test1 Jul 14 2003, 09:16 (UTC+0) Ok, the naming should be familiar - it's the same deal as with 2.4.0.
One difference is that while 2.4.0 took about 7 months from the pre1 to the final release, I hope (and believe) that we have fewer issues facing us in the current 2.6.0. But very obviously there are going to be a few test-releases before the real thing.
The point of the test versions is to make more people realize that they need testing and get some straggling developers realizing that it's too late to worry about the next big feature. I'm hoping that Linux vendors will start offering the test kernels as installation alternatives, and do things like make upgrade internal machines, so that when the real 2.6.0 does happen, we're all set.
Never mind the Nano-ITX board. How about the infotainment PC reference design below it! See here
I WANT one!
Around 3000 coming that I know about
on
Windows ATMs by 2005
·
· Score: 2, Interesting
A client of mine is investing heavily in Diebold ATMs, running Windows XP Embedded. Pentium 4, dual monitor, etc.
I have been responsible for locking them down, and I don't have an entirely happy feeling about it. But that's about 3000 odd ATMs to add to the statistics!
My first reaction on reading the headline was: BS!
But after reading the article, I think this could actually work, right down to the bitstream level, if the bitstream was slow enough. I don't see it working on a 115,200 bps link, but on anything less than 19,200, it seems realistic.
Unbelievable!
Anyone have a circuit diagram for a receiver? I've got some passwords to hack!:-)
Slashdot Mirror
Really? Even the smart card reader?
Interesting!
Where did you get the drivers for that?
Here is a suggestion that would allow computers that are not in use to be "co-opted" for use in the cluster.
Identify the PC's that COULD theoretically be used, and collect their MAC addresses. Also, configure them to try netboot first, then fall back to booting from the hard drive.
When you want to perform computations, send a WakeOnLAN packet targeted to each of these computers. Wait for netboot solicitations, then, if you have recently sent a WOL packet to that computer, respond with an appropriate netboot directive, booting the PC into a cluster node configuration, with all details loaded from the cluster director.
Otherwise, allow the netboot solicitation to time out, and the computer will boot into its normal configuration.
Not sure how OpenMosix handles nodes that simply vanish, but users could simply reboot the PC when they arrive in the morning, if the computation is still ongoing. Otherwise, the cluster director could remote shutdown/reboot each node prior to the user arriving at work.
Unused PC's would not consume power, cluster node PC's could be instructed to immediately drop the monitor into Power-save mode, etc.
The cluster director could decide how many nodes to start, or the location of the nodes, to optimise the comms between it and the servers.
An idea with potential, I think!
... has solved this problem more than 6 years ago. And it does not require the password to be stored in clear-text by the server. (although, "with a little thought", according to the article, neither does this scheme. BAH! Proof is left as an excercise for the reader)
Stick with something that has been rigorously reviewed, and proven over a period of time. And something that can be explained simply, in terms of the actual technology, rather than resorting to pathetic analogies that do not explain anything!
SRP
If you look up www.bank.com, receive a wrong IP address from the DNS server (e.g. dnsspoof), and connect to it, your browser will warn you that the certificate does not match the name. (Note that if the attacker is using dnsspoof, using a local DNS server will not necessarily protect you from this)
If you ignore this warning, you deserve everything you get.
It is not so easy to get around this problem, other than:
a) brute forcing the server's SSL cert to get the private key (a HARD problem)
b) stealing a copy of the cert by hacking the bank's webserver. (Hopefully also a HARD problem), or
c) getting your own CA cert installed into the victim's browser (maybe not *that* difficult, but still not trivial)
Anyone who thinks that SSL is *INSECURE* needs to understand the protocol better.
Sounds more like a window manager problem to me. If your window manager does not give focus to the windows in the order that you like, configure it to, or choose a different one that does.
;-)
That's why there are so many window managers
Don't assume that because they are buzzword compliant (AES 256-bit encryption!!!) that they have implemented it correctly.
That was the first mistake which led to all the war-driving originally - early WEP implementations used good algorithms, but chose a weak Initialisation Vector, which made it easier to decrypt the traffic.
Let's hope that they've learned their lesson this time, and aren't just trying to get people on the upgrade cycle again - WEP -> WPA -> WPA2 -> when will it stop?!
Note that you have to have physical access to get into the box. i.e physically disconnecting the hard drive, and mounting it on another host, in order to set the root password.
And I'm pretty sure that you need to have the admin password to enable telnet in the first place, too.
How's this?
http://www.digitwireless.com/
This attack works through proxies, because the proxy will simply relay a well-formed DNS request straight to the attackers DNS server, and return the well-formed DNS response back to the client.
Read the slides. It's quite impressive, even if it has also been known for a large number of years. No, Dan is not the first to realise the potential of this.
http://tux.iiivx.net/uptime_story.txt
About 10 years back we had a DEC field service rep working on one of our systems and the talk turned to the copious amount of dust in the fans and air filters (yeah, screw clean DP rooms, it's the paper dust more than anything!) and he brought up a service call to GM's Central Foundry in Saginaw, Michigan.
Seems some system stopped functioning and everyone started scratching their heads, trying to figure out what ran it. Finally an electician was brought in with wiring diagrams and found there was actually a DEC PDP 8 (yeah, one of those things) which controlled the system. They found it had been build around and buried behind HVAC ducts, pipes and conduits. Once they cut their way in to it, the field service rep cleaned out solid packed dust and grime, having to replace an 8" floppy, and reboot it from a backup disk.
After they got another boot disk and told how ancient their system was, they responded something along the lines of, "Well if it ran for 15 years and we didn't even know it was there, why replace it?" Indeed.
Slow down, cowboy. Thawte has been offering free personal certificates for at least 5 years already, along with a "Web of Trust" that allows for distributed certification of identity, exactly as this group is doing.
Admittedly, these are not usable as server certs (I think), but don't be so quick to slam things you wot not of.
It sounds like you already know what it is that you need to do, but are looking for implementation ideas.
Couple of thoughts:
LD_PRELOAD might help you to override open, seek, read, etc calls. You can probably do a HEAD on the URL to get the actual size of the MP3, without downloading the entire file and fake stat results from that.
Seek and read can be faked with Byte-Ranges, as you have already indicated.
Problems that I see are convincing the application to open "http://host:port/path" using the filesystem, and not spewing immediately.
I'm thinking that extending the python code that you have is probably going to be the easiest.
Why not? Would you prefer MP3, perhaps or Ogg Vorbis?
What's better than an uncompressed format for this sort of archival work? I don't think there was any mention of the sample rate in the article, but it seems to me that they could make it as high as they want to, given that they are generating it from a model of an analogue system.
Obviously they are limited by the resolution of their scans, and the quality of their model, but it seems from the story that they have got both right already.
MD5Crk.com has an applet on their site that does distributed calculations so long as it is visible in the browser (and assuming that you have specifically permitted it to do so). They are trying to find a collision to demonstrate that MD5 is insecure.
This is great for a simple calculation that returns simple results (e.g.MD5), but probably wouldn't work in a situation where you have to have lots of data to work from. Of course, if you can break it down sufficiently, it might work, and I guess he has already done the work in figuring out how to break it down and recombine the results.
See MD5Crk for the applet in question.
I tried to duplicate this, with no success using either of the abovementioned browsers.
I tried using
openssl s_server -nocert -ciphers eNULL:aNULL:NULL -www
as well as
openssl s_server -cert mycert.crt -ciphers eNULL:aNULL:NULL -www
In both cases, both browsers refused to connect, saying that there were no shared algorithms (Firefox), or simply giving a error page (IE).
In all cases, openssl gave me messages similar to
332:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c
Perhaps this does not qualify as "most browsers", but I'm sceptical of this report.
No, it is just pure logic.
If L is Life and
E is Evidence of Life, then
E ===> L
but
!E =/=> !L
That is:
Evidence of Life implies that there was life, but lack of evidence of life does not imply that there was no life.
For the same reason, not finding a vulnerability cannot prove that software is secure
This looks just like the Virtual Server project that Jacques Gelinas started a number of years ago. Possibly with some neat configuration utilities, but much the same. I'm not sure whether VServers can be allocated a dedicated CPU, or certain hardware exclusively, etc, but I think it can.
Xen, on the other hand is a much "heavier" approach, similar to VMWare, which virtualises the hardware, and emulates certain peripherals.
ssh access is all you really need to execute X11 commands. Install Cygwin and Xfree86 if Exceed is too complex. Then SSH in to the box, and check what your DISPLAY variable is set to (echo $DISPLAY). It should point back to your IP address (or hostname), followed by :0.0
if it is not, do "export DISPLAY=your.ip:0.0" and execute an xterm, or start gnome, or do whatever you want to.
You mean something like the 2.6.0-test series? Which started with the following post, 5 months before the final 2.6.0 was released:
Linus Torvalds: Linux 2.6.0-test1
Jul 14 2003, 09:16 (UTC+0)
Ok, the naming should be familiar - it's the same deal as with 2.4.0.
One difference is that while 2.4.0 took about 7 months from the pre1 to the final release, I hope (and believe) that we have fewer issues facing us in the current 2.6.0. But very obviously there are going to be a few test-releases before the real thing.
The point of the test versions is to make more people realize that they need testing and get some straggling developers realizing that it's too late to worry about the next big feature. I'm hoping that Linux vendors will start offering the test kernels as installation alternatives, and do things like make upgrade internal machines, so that when the real 2.6.0 does happen, we're all set.
Linus
I WANT one!
I have been responsible for locking them down, and I don't have an entirely happy feeling about it. But that's about 3000 odd ATMs to add to the statistics!
Are you perhaps confusing us with Zimbabwe?
The hash that is returned could contain all the information that can be determined from the XML doc (and maybe the DTD as well), such as type, etc.
My first reaction on reading the headline was: BS!
:-)
But after reading the article, I think this could actually work, right down to the bitstream level, if the bitstream was slow enough. I don't see it working on a 115,200 bps link, but on anything less than 19,200, it seems realistic.
Unbelievable!
Anyone have a circuit diagram for a receiver? I've got some passwords to hack!