Eh. Better yet, build a nuclear rocket that doesn't release any radioactive material at all. After all, you only need the heat. Use a propellant that absorbs UV and flow it around a nuclear lightbulb, and you have a rocket many times as efficient as anything we can build today, even at the low end of its theoretical range. Anyhow, it should be usable in atmosphere...
TWICE, eh? Look up the doubling time on world population. Hell, I'll do it for you: http://en.wikipedia.org/wiki/W... The short version is, given enough resources, the human population can now double more than once just in a single lifetime. We expect to hit a peak at around 2025 - that's barely over a decade away, now - but if we instead did away with that "human greed" you claim would allow supporting twice as many people, that would give a reprieve of somewhere between 20 years (assuming the historical trend of "each doubling takes half the time of the one before" holds) to possibly as much as 50 years (the estimate for the time to get from half the predicted 2025 pop to 2025). Then we're full up, again.
Aside from your 3rd point, which is frankly stupid (we've been sending people into space without an escape option for half a century now even though recovery from low earth orbit isn't nearly as hard, and yeah, sometimes they died...) the rest of what you say is probably true enough, or at least worth considering. But the argument that we could double the Earth's carrying capacity, as though that would grant more than a few decades reprieve, is bogus. We need a better option.
You know, if you're going to talk about the explosion of 1 (out of 9) rockets on one launch, you really should also mention the fact that they were able to complete the primary mission anyhow... they lost one nozzle, it shut down automatically, the fuel was diverted to the other nozzles, and they burned a little longer. They successfully rendezvoused with the ISS anyhow, despite a moderately explosive engine failure during launch. Let that sink in for a moment. Many rockets wouldn't even have been able to reach orbit in the case of a nozzle simply shutting down, much less blowing up.
In fairness to your complaint, though, the secondary goal of the mission was not attempted. SpaceX said they could give 95% assurance that the satellite would reach its safe orbit (not putting the ISS at risk), but NASA required over 99% assurance. Due to the extra fuel they'd had to burn, this could not be guaranteed. Still, it was highly likely they could have pulled it off, and likely would have tried under different circumstances.
Seattle has Centurylink DSL (12Mbps where I live, better or worse depending on your distance from the infrastructure), cable (I don't know what they'll tell you speed-wise, I hate Comcast, but faster than the DSL), Clear WiMax (~10Mbps, last I checked), CondoInternet (specific buildings only, but it's at least 100Mbps), and a few other various options (including LTE from all of the Big 4). The eastside (and possibly other suburbs) can get FiOS from Frontier (I think they have 40+Mbps), and down south there are some other fiber options as well, or so I've heard.
Now, out in the boonies, yeah it's going to suck. Sticking near the major metropolitan areas though, you can definitely get good service.
When you find a command line that lets me launch programs by typing the first few letters of any word in their name (in the case of multiple results it defaults to the one you run most often), let me know, OK? Oh, and by name I don't mean just the binary name, but the program's full name and any description you've given it in the Start menu/screen.
I mean, I use command line stuff a fair bit. I've got two windows of cmd and one of bash open right now, and I'm surprised I've only got one session of the latter running. But, that's mostly developer stuff (Visual Studio Tools in the one, manpages in the other; yes I write portable code in VS). Aside from programs that are inherently CLI-based though (like man), I rarely launch programs from the CLI. It's much faster to hit the WinKey and type "not" [ENTER] than to switch to a command line and type "notepad++" (even with command completion, which will get stuck on other expansions) and that assumes Notepad++ is in my path.
Uh... if that's an OS cache, your OS has serious problems (and you have a LOT of RAM). If that's on-disk cache... where do you buy your disks?!? Mine has 64MB of cache, that's it...
Cool, good for you. I don't know why the hell you'd map Power to Sleep when I guarantee that your laptop's keyboard already has a Sleep key, but hey, whatever. I wasn't talking to you, though, I was talking to the AC who was complaining that they don't know what happens when they hit the Power button. You obviously do know, so why the fuck talk back at me like I'm trying to tell you how to do things?
Sorry to self-reply, but a bit more info: You can also configure the Sleep button (if you have one in hardware, or have one on your keyboard as many users will) and the lid-close action (if you have a laptop). So for example, you can make closing the lid just go quickly to sleep, but taking the time to press a button first cause a full hibernate. It's also very handy to have the power button configured for a (reasonably safe) shutdown; it can be used to get the machine out of various states where the UI is hung so you can't use a normal software shut down, but don't want to hard-kill the machine (which is pretty much never a good idea).
Oh, and every single computer I've seen since I first found this feature also supports press-and-hold on Power to do a hard shutoff anyhow, in case the system is *so* frozen that it can't even turn itself off (or in case there's some process which is continually aborting the shutdown).
Windows Control Panel - Power Options (reachable directly by Start search since Vista, of course) - "Choose what the power buttons do" - "When I press the power button:" [Do Nothing | Sleep | Turn Off]. This is on my desktop which boots from an SSD, so I disabled Hibernate, but normally that would be there too. The default option is Turn Off.
This has been there since *at least* Windows 2000. Congratulations, you're almost 1.5 decades behind the times...
Um, no. Most JITs since, oh, late last decade do something much more clever: they write the emitted binary to non-executable memory, then they call mprotect (or on Windows, VirtualProtect) and change the page they just wrote from RW to RX, and then they execute it. Behold, a way to implement a JIT while still enforcing W^X and not opening up any security holes that aren't implicit in executing code in whatever the source of the JITed instructions are anyway.
Wow, really? Sorry random person on the Internet, but you are *completely* wrong. Did you even read the link on return-oriented programming (ROP)?
Here's how ROP works. First, I (the attacker) get memory corruption on your program. Let's say a big, meaty buffer overflow on stack (yes, I still see these vulns all the time. In 2014. It makes me sad too). Second, I spray a bunch of fake stack frames, overwriting all the real return addresses and frame pointers. I also dump some shellcode. Third, the function I'm in returns. Instead of returning to the shellcode directly, though (can't, because it's not executable), it returns to an instruction somewhere that does a tiny piece of work (like loading the address of the page with the shellcode into a register) and then returns. This is called a "gadget". Fourth, that first gadget "returns" into another gadget, and so on, each one setting up a function call that will convert the page containing shellcode from RW to RX. Fifth, after the call is set up, the last gadget (second-to-last sprayed stack frame) "returns" to the entry point of the memory protection call (mprotect on Linux, VirtualProtect on Windows). Sixth, the final sprayed stack frame - the one the mem protection function is using - returns to my newly-executable shellcode. You are pwned.
So yeah, it turns out that bypassing W^X is really not that hard. This is not a new technique, either; it's been around since basically right after DEP (rather, the NX bit that enforces no-execute at the CPU/memory manager level on any modern OS) was invented. There are actual compilers for ROP, where C goes in one end (along with the program you're exploiting) and the ROP chain comes out the other. You don't need very much code to be able to make ROP Turing-complete. This is partially due to the way that x86/x64, with their variable-length instructions, allow mis-aligned operations. You may think there's code in your program that loads the stack pointer into EAX and then immediately RETs, but if you read every single byte of the program (and all its loaded libraries) as a potential instruction start, you will probably find one!
To defeat ROP, you use ASLR (Address Space Layout Randomization), which in theory prevents successful ROP by randomizing the addresses of all the gadgets (specifically, loading all the executable code at addresses which have been XORed with a random mask). In practice, just like the way somebody will do something stupid that throws away the protection of DEP (like execheap does here...), somebody will write code that relies on being loaded at a fixed address, making an ASLR bypass possible. There are other ways too, like combining the overflow bug with an information leakage bug that tells the attacker what the ASLR mask is (i.e. if they can leak the address Y of something that is "supposed to" be at address X, they can get the ASLR mask M = Y^X) and then XOR their ROP addresses before exploitation.
Nonetheless, ROP is harder than just smashing the stack (or heap) data structures and pivoting into your shellcode. Marking some memory as RWX is just asking for trouble, and should never be done.
Even leaving aside the bizarreness of an audio decoder needing a JIT, it's still not that hard to allocation some RW memory, write to it, then re-flag it as RX. RWX should never happen.
You realize these are OEM machines, right? They don't even have a fully-installed OS on them. You have to do the last steps (license agreement, user account creation, etc.) first. Then after that, the machine will configure all that pre-installed stuff that comes with it.
They're charging $27 to use one install image instead of another. That's it. There's no time spent doing something that wouldn't otherwise be done.
Except that part of Firefox's value as a brand is that it is available free. If Dell charges for it (whether they charge for the software license or the labor is completely irrelevant) than they are damaging that aspect of the brand.
Arguably, Dell isn't really installing Firefox. They're installing something that is exactly like Firefox except that it's not distributed for free. They can't call that thing Firefox.
Except... A) it doesn't cost them anything, not even time. These are imaged disks, not somebody clicking "Next" a bunch through the install prompts of 50 shitware programs that come with the system. Your argument is invalid. B) Mozilla explicitly prohibits the use of their trademark if you're going to charge for it. Charging for the service of installing Firefox is still charging for it. Basically, part of the value of the Firefox brand is that you don't have to pay to get it.
Seems straightforward enough to me. Doesn't mean they'd win in court, since that requires convincing a jury that you have a better lawyer, but it's certainly understandable that Mozilla would see this as misuse of trademark.
Of course not! Snowden blew the whistle during the Obama administration for a reason! Surely you don't think any of those programs go back further than 2009, do you?!? </sarcasm> Fuck them both. Idiots like the GP, with their partisan blindness perpetuating the stupidity, are part of the problem.
Well, you could try HTTP Public Key Pinning, but not many clients implement it yet and some proxies might just re-write the headers too. You can tell your users how to check, of course, but good luck getting many to do that. Otherwise, unless you use TLS client certificates, not really. One client's key looks much like another's...
So, if this is a work machine and you're using Windows, I'm going to guess you're on IE. If not, you can find similar steps for other browsers, though.
1) Connect to an HTTPS site. 2) Find the "Lock" icon in the address bar (it should be on the right side). 3) Click on it; the exact result of doing this will vary by version but you should get some info about the security of the connection. 4) Click on "View Certificates" (on IE10+ this is right in the little box that appears when you click the icon; I don't have an older version available to check). 5) Check each certificate in the chain of trust. Under the General tab, look at Issued By. Also look up the "chain of trust" to check the signing certificates in the Certification Path tab.
They should be signed by known certificate authorities (if you aren't sure whether a given company is a known CA, look it up online). If the cert is instead signed by your employer or something like that, you're pwned.
Right. Steganography, for example - and it really doesn't have to be very good to fool a computer - will easily bypass this. Take a zip of sensitive files. Encrypt it. Wrap a BMP header around it. If needed, embed that "image file" into another document (one containing no sensitive info). Email it to yourself or post it to an externally-accessible website. Retrieve the file at home, strip the image metadata portion, decrypt the data, unzip your lovely exfiltrated files. Of course, there are lots of other and possibly cleverer ways to handle this, but the basic idea is nearly impossible for a computer to detect, and if you can make it look close enough to your usual usage patterns it probably won't even get flagged for human review.
In that case, it is legal to do the following: A) Block access to those sites. B) Fire employees who attempt to access those sites (whether or not successful).
A proxy is perfectly capable of handling either or both of these (well, probably not the actual firing, but raising a ticket about it) *WITHOUT* intercepting the traffic. Such interception would still be illegal.
Slashdot Mirror
Eh. Better yet, build a nuclear rocket that doesn't release any radioactive material at all. After all, you only need the heat. Use a propellant that absorbs UV and flow it around a nuclear lightbulb, and you have a rocket many times as efficient as anything we can build today, even at the low end of its theoretical range. Anyhow, it should be usable in atmosphere...
TWICE, eh? Look up the doubling time on world population. Hell, I'll do it for you: http://en.wikipedia.org/wiki/W...
The short version is, given enough resources, the human population can now double more than once just in a single lifetime. We expect to hit a peak at around 2025 - that's barely over a decade away, now - but if we instead did away with that "human greed" you claim would allow supporting twice as many people, that would give a reprieve of somewhere between 20 years (assuming the historical trend of "each doubling takes half the time of the one before" holds) to possibly as much as 50 years (the estimate for the time to get from half the predicted 2025 pop to 2025). Then we're full up, again.
Aside from your 3rd point, which is frankly stupid (we've been sending people into space without an escape option for half a century now even though recovery from low earth orbit isn't nearly as hard, and yeah, sometimes they died...) the rest of what you say is probably true enough, or at least worth considering. But the argument that we could double the Earth's carrying capacity, as though that would grant more than a few decades reprieve, is bogus. We need a better option.
You know, if you're going to talk about the explosion of 1 (out of 9) rockets on one launch, you really should also mention the fact that they were able to complete the primary mission anyhow... they lost one nozzle, it shut down automatically, the fuel was diverted to the other nozzles, and they burned a little longer. They successfully rendezvoused with the ISS anyhow, despite a moderately explosive engine failure during launch. Let that sink in for a moment. Many rockets wouldn't even have been able to reach orbit in the case of a nozzle simply shutting down, much less blowing up.
In fairness to your complaint, though, the secondary goal of the mission was not attempted. SpaceX said they could give 95% assurance that the satellite would reach its safe orbit (not putting the ISS at risk), but NASA required over 99% assurance. Due to the extra fuel they'd had to burn, this could not be guaranteed. Still, it was highly likely they could have pulled it off, and likely would have tried under different circumstances.
http://en.wikipedia.org/wiki/S...
Seattle has Centurylink DSL (12Mbps where I live, better or worse depending on your distance from the infrastructure), cable (I don't know what they'll tell you speed-wise, I hate Comcast, but faster than the DSL), Clear WiMax (~10Mbps, last I checked), CondoInternet (specific buildings only, but it's at least 100Mbps), and a few other various options (including LTE from all of the Big 4). The eastside (and possibly other suburbs) can get FiOS from Frontier (I think they have 40+Mbps), and down south there are some other fiber options as well, or so I've heard.
Now, out in the boonies, yeah it's going to suck. Sticking near the major metropolitan areas though, you can definitely get good service.
When you find a command line that lets me launch programs by typing the first few letters of any word in their name (in the case of multiple results it defaults to the one you run most often), let me know, OK? Oh, and by name I don't mean just the binary name, but the program's full name and any description you've given it in the Start menu/screen.
I mean, I use command line stuff a fair bit. I've got two windows of cmd and one of bash open right now, and I'm surprised I've only got one session of the latter running. But, that's mostly developer stuff (Visual Studio Tools in the one, manpages in the other; yes I write portable code in VS). Aside from programs that are inherently CLI-based though (like man), I rarely launch programs from the CLI. It's much faster to hit the WinKey and type "not" [ENTER] than to switch to a command line and type "notepad++" (even with command completion, which will get stuck on other expansions) and that assumes Notepad++ is in my path.
Huh... every device I've seen with a dedicated keyboard either had an actual key or (more often) a simple key chord (Fn+F3 or similar) for sleep. Odd.
Don't even actually have to use Run (Win+R); the Start search accepts command line arguments. So WinKey and just type the command works fine too.
Uh... if that's an OS cache, your OS has serious problems (and you have a LOT of RAM). If that's on-disk cache... where do you buy your disks?!? Mine has 64MB of cache, that's it...
Cool, good for you. I don't know why the hell you'd map Power to Sleep when I guarantee that your laptop's keyboard already has a Sleep key, but hey, whatever. I wasn't talking to you, though, I was talking to the AC who was complaining that they don't know what happens when they hit the Power button. You obviously do know, so why the fuck talk back at me like I'm trying to tell you how to do things?
Sorry to self-reply, but a bit more info:
You can also configure the Sleep button (if you have one in hardware, or have one on your keyboard as many users will) and the lid-close action (if you have a laptop). So for example, you can make closing the lid just go quickly to sleep, but taking the time to press a button first cause a full hibernate. It's also very handy to have the power button configured for a (reasonably safe) shutdown; it can be used to get the machine out of various states where the UI is hung so you can't use a normal software shut down, but don't want to hard-kill the machine (which is pretty much never a good idea).
Oh, and every single computer I've seen since I first found this feature also supports press-and-hold on Power to do a hard shutoff anyhow, in case the system is *so* frozen that it can't even turn itself off (or in case there's some process which is continually aborting the shutdown).
Windows Control Panel - Power Options (reachable directly by Start search since Vista, of course) - "Choose what the power buttons do" - "When I press the power button:" [Do Nothing | Sleep | Turn Off]. This is on my desktop which boots from an SSD, so I disabled Hibernate, but normally that would be there too. The default option is Turn Off.
This has been there since *at least* Windows 2000. Congratulations, you're almost 1.5 decades behind the times...
Um, no. Most JITs since, oh, late last decade do something much more clever: they write the emitted binary to non-executable memory, then they call mprotect (or on Windows, VirtualProtect) and change the page they just wrote from RW to RX, and then they execute it. Behold, a way to implement a JIT while still enforcing W^X and not opening up any security holes that aren't implicit in executing code in whatever the source of the JITed instructions are anyway.
Wow, really? Sorry random person on the Internet, but you are *completely* wrong. Did you even read the link on return-oriented programming (ROP)?
Here's how ROP works.
First, I (the attacker) get memory corruption on your program. Let's say a big, meaty buffer overflow on stack (yes, I still see these vulns all the time. In 2014. It makes me sad too).
Second, I spray a bunch of fake stack frames, overwriting all the real return addresses and frame pointers. I also dump some shellcode.
Third, the function I'm in returns. Instead of returning to the shellcode directly, though (can't, because it's not executable), it returns to an instruction somewhere that does a tiny piece of work (like loading the address of the page with the shellcode into a register) and then returns. This is called a "gadget".
Fourth, that first gadget "returns" into another gadget, and so on, each one setting up a function call that will convert the page containing shellcode from RW to RX.
Fifth, after the call is set up, the last gadget (second-to-last sprayed stack frame) "returns" to the entry point of the memory protection call (mprotect on Linux, VirtualProtect on Windows).
Sixth, the final sprayed stack frame - the one the mem protection function is using - returns to my newly-executable shellcode. You are pwned.
So yeah, it turns out that bypassing W^X is really not that hard. This is not a new technique, either; it's been around since basically right after DEP (rather, the NX bit that enforces no-execute at the CPU/memory manager level on any modern OS) was invented. There are actual compilers for ROP, where C goes in one end (along with the program you're exploiting) and the ROP chain comes out the other. You don't need very much code to be able to make ROP Turing-complete. This is partially due to the way that x86/x64, with their variable-length instructions, allow mis-aligned operations. You may think there's code in your program that loads the stack pointer into EAX and then immediately RETs, but if you read every single byte of the program (and all its loaded libraries) as a potential instruction start, you will probably find one!
To defeat ROP, you use ASLR (Address Space Layout Randomization), which in theory prevents successful ROP by randomizing the addresses of all the gadgets (specifically, loading all the executable code at addresses which have been XORed with a random mask). In practice, just like the way somebody will do something stupid that throws away the protection of DEP (like execheap does here...), somebody will write code that relies on being loaded at a fixed address, making an ASLR bypass possible. There are other ways too, like combining the overflow bug with an information leakage bug that tells the attacker what the ASLR mask is (i.e. if they can leak the address Y of something that is "supposed to" be at address X, they can get the ASLR mask M = Y^X) and then XOR their ROP addresses before exploitation.
Nonetheless, ROP is harder than just smashing the stack (or heap) data structures and pivoting into your shellcode. Marking some memory as RWX is just asking for trouble, and should never be done.
Even leaving aside the bizarreness of an audio decoder needing a JIT, it's still not that hard to allocation some RW memory, write to it, then re-flag it as RX. RWX should never happen.
Aww... when you said "three-headed dragon" I was hoping you were talking about Dahak.
(Link to legal free copies of the books, because they're awesome like that: http://baencd.thefifthimperium... No personal association)
And on that note, I'm off on an intrastellar voyage for dinner. I'm considering between walking and riding my bike. The estimated budget is $12.
You realize these are OEM machines, right? They don't even have a fully-installed OS on them. You have to do the last steps (license agreement, user account creation, etc.) first. Then after that, the machine will configure all that pre-installed stuff that comes with it.
They're charging $27 to use one install image instead of another. That's it. There's no time spent doing something that wouldn't otherwise be done.
Except that part of Firefox's value as a brand is that it is available free. If Dell charges for it (whether they charge for the software license or the labor is completely irrelevant) than they are damaging that aspect of the brand.
Arguably, Dell isn't really installing Firefox. They're installing something that is exactly like Firefox except that it's not distributed for free. They can't call that thing Firefox.
Except...
A) it doesn't cost them anything, not even time. These are imaged disks, not somebody clicking "Next" a bunch through the install prompts of 50 shitware programs that come with the system. Your argument is invalid.
B) Mozilla explicitly prohibits the use of their trademark if you're going to charge for it. Charging for the service of installing Firefox is still charging for it. Basically, part of the value of the Firefox brand is that you don't have to pay to get it.
Seems straightforward enough to me. Doesn't mean they'd win in court, since that requires convincing a jury that you have a better lawyer, but it's certainly understandable that Mozilla would see this as misuse of trademark.
Honestly, that's what most security bugs are. "I thought the user would put their name in the signature field, not a JavaScript block!"
Of course not! Snowden blew the whistle during the Obama administration for a reason! Surely you don't think any of those programs go back further than 2009, do you?!? </sarcasm>
Fuck them both. Idiots like the GP, with their partisan blindness perpetuating the stupidity, are part of the problem.
Well, you could try HTTP Public Key Pinning, but not many clients implement it yet and some proxies might just re-write the headers too. You can tell your users how to check, of course, but good luck getting many to do that. Otherwise, unless you use TLS client certificates, not really. One client's key looks much like another's...
So, if this is a work machine and you're using Windows, I'm going to guess you're on IE. If not, you can find similar steps for other browsers, though.
1) Connect to an HTTPS site.
2) Find the "Lock" icon in the address bar (it should be on the right side).
3) Click on it; the exact result of doing this will vary by version but you should get some info about the security of the connection.
4) Click on "View Certificates" (on IE10+ this is right in the little box that appears when you click the icon; I don't have an older version available to check).
5) Check each certificate in the chain of trust. Under the General tab, look at Issued By. Also look up the "chain of trust" to check the signing certificates in the Certification Path tab.
They should be signed by known certificate authorities (if you aren't sure whether a given company is a known CA, look it up online). If the cert is instead signed by your employer or something like that, you're pwned.
Right. Steganography, for example - and it really doesn't have to be very good to fool a computer - will easily bypass this. Take a zip of sensitive files. Encrypt it. Wrap a BMP header around it. If needed, embed that "image file" into another document (one containing no sensitive info). Email it to yourself or post it to an externally-accessible website. Retrieve the file at home, strip the image metadata portion, decrypt the data, unzip your lovely exfiltrated files. Of course, there are lots of other and possibly cleverer ways to handle this, but the basic idea is nearly impossible for a computer to detect, and if you can make it look close enough to your usual usage patterns it probably won't even get flagged for human review.
In that case, it is legal to do the following:
A) Block access to those sites.
B) Fire employees who attempt to access those sites (whether or not successful).
A proxy is perfectly capable of handling either or both of these (well, probably not the actual firing, but raising a ticket about it) *WITHOUT* intercepting the traffic. Such interception would still be illegal.