a: Remote management cards often have command line interfaces for resetting, system health, etc, through SSH. True, SSH with 800ms RTT times is a pain-in-the-ass, but if scripted, should work fine.
b: Once you can power cycle/machine health remotely, now you use SSH to connect to a command line shell on the system itself (yes, even windows) and do all further tasks from the command line.
Hello senator. Congratulations on being reelected dispite being a convicted felon. I hope you enjoy serving your remaining term in PMITA Federal Prsion. Have a nice day.
You can target the iPod touch as well as the iPhone, and can develop on the iPod touch as well as the iPhone ($220 development platforms with no per-month cost).
You have some very interesting features (accelerometer, GPS, camera) which make for some particularly interesting ideas
You have a large installed base thats still growing rapidly.
And apple takes only a 30% cut of revenue, in exchange for a nice distribution mechanism.
You aren't missing out on a "whole lot": You end up being about 80 ADAM down per 3 little sisters, or 320 in the whole game. I'm sure there are 320 atom worth of useless upgrades you don't need to buy in return for some pretty cool bonuses.
FireWire is a dying standard. Only apple has really been supporting it, and its going away is dissapointing but rather inevitable, especially as USB performance closes the gap.
The biggest annoyance is lack of target-disk mode. But is there a USB target-disk mode on the new ones? And, worst case, you can always get a $20 enclosure and pull the drive: it just pops right out of the new MacBooks.
No you don't. Because what you do is you demand-swap the pages as they are accessed, ideally with some trace-based hacks so you know "if this page is fetched, these pages are fetched".
Boot the system. Now snapshot a memory image (a'la hybernate).
Now for "instant on", set up the page table and start running, and in the background, lazily swap in the rest of the memory. Anything you need immediately gets paged from disk, and the rest of the state gets swept up over the next 30 seconds.
Also, in the background, do "lazy write" as well: Any page that is stable for >X seconds but the disk is still active, write it out, so that going back to sleep (rehibernating) can be fast as well.
Then all DNSSEC is is Yet Another CA Infrastructure.
And if you want an integrity-assured object store, why use DNSSEC? INstead, build an alternate application protocol that doesn't have silly record limits and the like in it.
Unfortunatly, I disagree. The problem is DNSSEC is about securing DNS from in-path (MitM) adversaries. But in almost all cases, a DNS MitM can also be a MitM on the application.
If the application resists a MitM, it never trusted DNS anyway.
If the application doesn't resist a MitM, that the DNS resists a MitM is irrelevant.
Thus the net marginal increase in system security that DNSSEC offers is suprisingly low in my opinion, and our objective should be securing out-of-path resolvers against all adversaries SHORT of a man-in-the-middle.
Apple is obsessed with thin packaging. Look at the iPhone, nano, or iPod touch. A removable battery would add a good 2mm of thickness, which may not sound like much, but thats a good 30% increase in thickness.
Once you get a TCP communication up, you then play stateholding tricks: EG, a packet then a long gap and then another packet, to force a large buffer alloctaion.
Wrong about Fossett, wrong about Reiser...
on
Fossett's Plane Found
·
· Score: 5, Funny
What are the random internet nutcases right about anymore?
As an extra special bonus, it acts to rapidly age cheap snake-oil from the rancid dead rattler-junk it started out as to something equivelent to the finest age tawny boa extract.
The observation: You can use a SYN-cookie like trick on the client side as well for an attacker:
You send SYNs where the initial seq # = H(sip, dip, sport, dport).
Now when you get a SYN/ACK back, you can send the ACK to complete the handshake. You can use the ACK field back from the server to know where you are in what data to send (just subtract the value from the initial sequence # to know what the next piece of data to send is), and you can know where you are in the received data (if necessary) by storing just the server's initial sequence #.
As a result, you can now interact with the server without having to maintain ANY TCP session state, or just a single word (the server's initial seq #), allowing the attacker to use vastly fewer resources to tie up server resources.
On one hand, this is a cool trick, and potentially useful for an attacker: if you have only a couple of machines and really want to tie up server resources, you can use this quite quickly.
But OTOH, attackers already have so many zombie resources that this really doesn't necessarily buy the attacker all that much: If you have 10K machines banging on a server, the 10K machines have a good 2000x more state than the servers. So who cares about stateholding requirements on the zombie side? Thus I think its only really relevant if you wanted to DOS google, akamai, or some similar very-high-resource infrastructure.
And as the attacker can't SPOOF packets with this (it needs to see the SYN/ACK), the zombies can be filtered if the DOS is detected and the attacker's identified as well.
It sounds like a blind resource consumption attack against SYN-cookie implementations, no? (Without SYN-cookies, the attack is trivial, just spoof SYNs).
SYN-cookies are a simple idea. Upon receiving a SYN, rather than creating all the state, the server returns a SYN/ACK with the SEQ value = H(IP,ACK value). Thus when it sees the ACK packet it can check that the value is returned, and then create all the state.
If this is the case, it seems to require that a SYN-cookie be predictible, that the attacker can probe a client to predict what H(IP,ACK value) is. IF that is the case then there is an easy fix: simply use more and better random data as salt in a better hash function.
Simply because ANY blind resource consumption attack against a SYN-cookie server requires knowing what the SEQ value from the server for the SYN/ACK in order to establish a connection by sending the proper ACK (and then some data to load the server further).
If the attacker can't predict the SYN/ACK's SEQ value, it can't construct a proper ACK and cause the server to consume resources.
Slashdot Mirror
The universe really was made just for me!
"Specifications subject to drastic change"
They've been promising this thing for what, 4 years now?
a: Remote management cards often have command line interfaces for resetting, system health, etc, through SSH. True, SSH with 800ms RTT times is a pain-in-the-ass, but if scripted, should work fine.
b: Once you can power cycle/machine health remotely, now you use SSH to connect to a command line shell on the system itself (yes, even windows) and do all further tasks from the command line.
It looks for files like "guyongirlonsheep37.jpg"
A scene a few months from now:
Hello senator. Congratulations on being reelected dispite being a convicted felon. I hope you enjoy serving your remaining term in PMITA Federal Prsion. Have a nice day.
You can target the iPod touch as well as the iPhone, and can develop on the iPod touch as well as the iPhone ($220 development platforms with no per-month cost).
You have some very interesting features (accelerometer, GPS, camera) which make for some particularly interesting ideas
You have a large installed base thats still growing rapidly.
And apple takes only a 30% cut of revenue, in exchange for a nice distribution mechanism.
You aren't missing out on a "whole lot": You end up being about 80 ADAM down per 3 little sisters, or 320 in the whole game. I'm sure there are 320 atom worth of useless upgrades you don't need to buy in return for some pretty cool bonuses.
Gee, lets use the EM spectrum as a massive garbage dump for high-frequencey EM waste.
Seriously, folks. Computers NEED shielding to keep their em garbage from causing massive interference to everything else in the room.
FireWire is a dying standard. Only apple has really been supporting it, and its going away is dissapointing but rather inevitable, especially as USB performance closes the gap.
The biggest annoyance is lack of target-disk mode. But is there a USB target-disk mode on the new ones? And, worst case, you can always get a $20 enclosure and pull the drive: it just pops right out of the new MacBooks.
No you don't. Because what you do is you demand-swap the pages as they are accessed, ideally with some trace-based hacks so you know "if this page is fetched, these pages are fetched".
So? How many "interesting" hardware reconfigurations happen?
If the hardware has changed, reboot the F@#er.
Boot the system. Now snapshot a memory image (a'la hybernate).
Now for "instant on", set up the page table and start running, and in the background, lazily swap in the rest of the memory. Anything you need immediately gets paged from disk, and the rest of the state gets swept up over the next 30 seconds.
Also, in the background, do "lazy write" as well: Any page that is stable for >X seconds but the disk is still active, write it out, so that going back to sleep (rehibernating) can be fast as well.
Then all DNSSEC is is Yet Another CA Infrastructure.
And if you want an integrity-assured object store, why use DNSSEC? INstead, build an alternate application protocol that doesn't have silly record limits and the like in it.
Unfortunatly, I disagree. The problem is DNSSEC is about securing DNS from in-path (MitM) adversaries. But in almost all cases, a DNS MitM can also be a MitM on the application.
If the application resists a MitM, it never trusted DNS anyway.
If the application doesn't resist a MitM, that the DNS resists a MitM is irrelevant.
Thus the net marginal increase in system security that DNSSEC offers is suprisingly low in my opinion, and our objective should be securing out-of-path resolvers against all adversaries SHORT of a man-in-the-middle.
I believe DNSSEC is unnecessary to counter the Kaminski attack.
See draft-weaver-dnsext-comprehensive-resolver-00 for how I believe you can secure resolvers against attacks less powerful than MitM, including Kaminski (race-until-win) attacks.
Are you a middle eastern looking young male? A white male returning from Thailand? If so, be paranoid.
If not, no worries.
Actually, you CAN get aftermarket batteries and replace em yourself. It just takes skill.
And there are plenty of third party companies which will replace your battery as well.
Apple is obsessed with thin packaging. Look at the iPhone, nano, or iPod touch. A removable battery would add a good 2mm of thickness, which may not sound like much, but thats a good 30% increase in thickness.
Once you get a TCP communication up, you then play stateholding tricks: EG, a packet then a long gap and then another packet, to force a large buffer alloctaion.
What are the random internet nutcases right about anymore?
As an extra special bonus, it acts to rapidly age cheap snake-oil from the rancid dead rattler-junk it started out as to something equivelent to the finest age tawny boa extract.
Score one more for the subtitle on the original CAPTCHA paper: "How Lazy Cryptographers do AI"...
The observation: You can use a SYN-cookie like trick on the client side as well for an attacker:
You send SYNs where the initial seq # = H(sip, dip, sport, dport).
Now when you get a SYN/ACK back, you can send the ACK to complete the handshake. You can use the ACK field back from the server to know where you are in what data to send (just subtract the value from the initial sequence # to know what the next piece of data to send is), and you can know where you are in the received data (if necessary) by storing just the server's initial sequence #.
As a result, you can now interact with the server without having to maintain ANY TCP session state, or just a single word (the server's initial seq #), allowing the attacker to use vastly fewer resources to tie up server resources.
On one hand, this is a cool trick, and potentially useful for an attacker: if you have only a couple of machines and really want to tie up server resources, you can use this quite quickly.
But OTOH, attackers already have so many zombie resources that this really doesn't necessarily buy the attacker all that much: If you have 10K machines banging on a server, the 10K machines have a good 2000x more state than the servers. So who cares about stateholding requirements on the zombie side? Thus I think its only really relevant if you wanted to DOS google, akamai, or some similar very-high-resource infrastructure.
And as the attacker can't SPOOF packets with this (it needs to see the SYN/ACK), the zombies can be filtered if the DOS is detected and the attacker's identified as well.
Its simply using the SYN-cookie style trick on the client side to reduce the state-holding requirements on the client to near-zero.
SNEAKY!
It sounds like a blind resource consumption attack against SYN-cookie implementations, no? (Without SYN-cookies, the attack is trivial, just spoof SYNs).
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html
SYN-cookies are a simple idea. Upon receiving a SYN, rather than creating all the state, the server returns a SYN/ACK with the SEQ value = H(IP,ACK value). Thus when it sees the ACK packet it can check that the value is returned, and then create all the state.
If this is the case, it seems to require that a SYN-cookie be predictible, that the attacker can probe a client to predict what H(IP,ACK value) is. IF that is the case then there is an easy fix: simply use more and better random data as salt in a better hash function.
Simply because ANY blind resource consumption attack against a SYN-cookie server requires knowing what the SEQ value from the server for the SYN/ACK in order to establish a connection by sending the proper ACK (and then some data to load the server further).
If the attacker can't predict the SYN/ACK's SEQ value, it can't construct a proper ACK and cause the server to consume resources.