In addition, the foul odors emitted in that room were quite offensive. The farting, sweating, lack of showering...etc.... The best configuration for programmers is individual offices.
Actually, if you're only concerned about farting et al., an office with 2 people would work just as well. You know you weren't the one who let one slip out (or if you were indeed, your mate knows he wasn't). Add a third person, and along comes plausible deniability.
But they are visible to all devices connected to the same LAN or WLAN. Such as your browser. So all Google needs is a trojan (Google Earth, Google toolbar) that records the Mac of the router you're connected to, and forward that to its headquarters. And now they see that very often such and such gmail account is connecting to such and such router. Chances are, it's his router.
If you ever use your Wifi-enabled phone to first use google maps via your AP, and then log in to Adsense (or Gmail), they can tie the SSID and AP MAC to your identity.
And if your girlfriends (or boyfriends) use their phone in your appartment (or vice versa), google now knows who knows who.
And if during some steamy hot action, your iPhone happens to fall from the nightstand onto the bed, they can do some nice Fourier analysis of the vibrations, thanks to the built-in accelerometers.
Why not? As the current events and financial impact on the airlines prove, there is definately a market in instruments for hedging against this type of risk. The only problem: who will take up the other side?
They should probably get paid a little more, but then again you have the whole tech/geek culture which scrutinizes any product that costs more then the competition.
Then, the consumer could pay a couple of cents more for ethically manufactured hardware, without needing to be afraid that the extra would be pocketed by one of the many middlemen.
This is not "how to exploit NULL pointers"... this is "how to exploit a kernel NULL function pointer".
No, it's just the "simplest" example of exploiting NULL pointers. If your NULL pointer is not a function pointer, you can still exploit it in many cases, you just need to work slightly harder.
changing address spaces, which is a costly operation in any architecture.
Not necessarily. What if Intel had real segments, pointing each to a separate address space rather than just being windows into a same global address space.
In a perfect world, each segment would have its own CR3 (page table root), and it would not only be more secure, but also more performant (no flushing of kernel's TLB cache when switching from one process to the other), and would have allowed better "big memory" support under 32 bit systems.
to deference any NULL pointer would effectively be calling that function, assuming this memory mapping really works.
It's not as simple as that. If the kernel contained a read access to that pointer in the exploitable code, it would still perform a read, even though the memory location contained executable code. The only thing would be, that now you would have the numerical value of the instructions in a register, that's it.
But in many cases, the NULL pointer dereference would still be exploitable, it would only be slightly more complicated.
TFA explains how to exploit a theoretical kernel bug that happens to "read a function pointer from address 0, and then call through it". That's a long shot from turning "any NULL pointer" into a root exploit as the summary claims.
Having the NULL pointer being a function pointer was just the easiest "use case" for this kind of bug.
For another example, involving a write to a doubly dereferenced NULL pointer, read here.
And, with most structures containing pointers to other structures, double dereferencing doesn't look so far-fetched.
It might not work with all NULL pointer dereferences, but it definately works with more than just function pointers.
Here is one example how to exploit a different kind of NULL pointer dereference.
The article is rather long, but the short summary is, the kernel does a->some_field->x=NULL , where a is the NULL pointer.
The NULL page is under the control of the exploiter. So he can set some_field to point to a memory location he wants to zero out. That could be any location in kernel space (such as a hypothetical byte that contains the user id of the current process). In our case, the exploiter used the return address on the stack. Which caused the system call to "return" to address NULL, nicely transforming a "write to NULL" exploit into a "call NULL exploit", and from there, we continue just like in the tutorial.
The "using root access to tell the OS to let me map page 0" bit was just to simulate a hypothetical situation were this the block about checking page 0 wasn't effective (there used to be a bug in recent kernels which allowed you to bypass this).
The point of the article was not to hand you an exploit on a platter, but rather tell you how to leverage 2 kinds of bugs (1. bypassable mmap 0 protection, and 2. an unchecked null pointer dereference) into a root exploit.
Bugs of both classes have existed multiple times in the past (fixed by now), and it is reasonable to assume that more might be discovered in the future.
Lacking any current "real life" instances of such bugs, the article deliberately sets these up, but an actual exploit would of course not depend on custom kernel modules and deliberate misconfiguration of the kernel, but would use 2 real vulnerabilities.
The article highlights dangers of current handling of null pointers (which are used internally in many softwares as meaning "value unknown" or "value not supplied"), but this usage is dangerous as in some rare circumstances, a Null pointer may indeed be dereferenced without triggering an exception.
Also not just any dereference will do, it has to be a function pointer dereference.
The Null pointer doesn't have to be a function pointer. A pointer to a structure containing a function pointer would work too. Or a pointer to a structure that contains a pointer to another structure that will be changed. And many other situations as well. The only thing is, it will be (slightly) harder to exploit, but not impossible.
A 1km-tall stack of cards... results in a measly 342.89 megabytes
... nice.
But you forgot a nice wording flame:
I could pull out a stack of punch cards 1 km tall and claim it's got 1 TB storage capacity too, thus having 'caught up' with HDDs.
You "catch up" with somebody how had a headstart. Given that HDDs are newer technology than punch cards, it's cute to claim the punch cards could "catch up" with HDDs, even if there was a way to make a 1TB stack of them.
"This isn't helped by the architecture of most SSDs. Usually, data is laid down within a block of available memory, meaning that it might not take up all the available space--yet will still write to all of it"
Does the author think traditional hard drives write to byte-addressable boundaries? Hard drives write blocks and sectors too and have wasted slack space at the end of their blocks too.
Yes, but these blocks of memory might be much bigger than sectors on a hard disk.
And filesystem code in operating systems knows about the (small) sectors of disks, and might not be able to cope with the large blocks of SSDs. Meaning that the SSD must be sufficiently smart to read the entire block, change whatever range needs to be changed, and rewrites it. And this might happen lots of times, because the higher level code (filesystems) might not be aware of the issue.
There is no reason to defrag an SSD because their is no latency getting to a further sector.
There is no latency, but defragging may be useful for a different purpose: making sure that each memory block is occupied by as few different files as possible (in order to dampen the effect of the phenomenon outlined above).
I think that depends on the place. Here in Luxembourg, back in the day when I was still a student myself, when you were kicked out, you were usually supposed to wait the rest of the hour (or until the teacher called you back in) before the door of the classroom.
Younger children did indeed stay.
Older ones (high-school age) didn't bother, and enjoyed the nice extra free time...
I remember one memorable time, when several students were playing cards during geography lesson. Eventually the teacher (peace to his soul) got fed up, and kicked them out with the words "if you like playing cards so much, please go play somewhere else". And when the 4 left, the rest of the class left along with them...
Nowadays, teachers rarely kick anybody out, probably for this reason.
Even if teachers could kick kids out of their classroom, many kids would actually enjoy it. Gee, an hour at the pub, rather than in a boring class! W00t!
Parent should have access to their kids communications, and failure to monitor and stop criminal activity makes them accomplices.
Actually, parents having access to kids' communications could make the situation much worse. The victim's parents would have access to the victim's communication as well, and with if his parents are of the "bullying is good, it builds character" kind? (which they most likely are, in cases like this, or else the kid would already have whined to them, and they would have done sth).
The thing that usually breaks the victim's back is complete lack of support even from their own family. So they try to keep it secret, and carry their cross in isolation.
And, what solution did you use to avoid such tampering? Loading the library via https? Or just praying to God that hackers wouldn't know how to fake a checksum?
Slashdot Mirror
In addition, the foul odors emitted in that room were quite offensive. The farting, sweating, lack of showering...etc.... The best configuration for programmers is individual offices.
Actually, if you're only concerned about farting et al., an office with 2 people would work just as well. You know you weren't the one who let one slip out (or if you were indeed, your mate knows he wasn't). Add a third person, and along comes plausible deniability.
Also MAC addresses do not traverse the internet,
But they are visible to all devices connected to the same LAN or WLAN. Such as your browser. So all Google needs is a trojan (Google Earth, Google toolbar) that records the Mac of the router you're connected to, and forward that to its headquarters. And now they see that very often such and such gmail account is connecting to such and such router. Chances are, it's his router.
And if your girlfriends (or boyfriends) use their phone in your appartment (or vice versa), google now knows who knows who.
And if during some steamy hot action, your iPhone happens to fall from the nightstand onto the bed, they can do some nice Fourier analysis of the vibrations, thanks to the built-in accelerometers.
No, you just should close the blinds.
Why not? As the current events and financial impact on the airlines prove, there is definately a market in instruments for hedging against this type of risk. The only problem: who will take up the other side?
You may need this for your new bold space policy
the well-bribed, local officials
Bribed? What a dirty word! The officials are just getting some money for the hard work they are doing helping their spouses run an efficient business!
They should probably get paid a little more, but then again you have the whole tech/geek culture which scrutinizes any product that costs more then the competition.
Why do not do the same thing as for coffee, bananas, chocolate and soccer balls, and create a Fair-trade label for ethically manufactured computer mice?
Then, the consumer could pay a couple of cents more for ethically manufactured hardware, without needing to be afraid that the extra would be pocketed by one of the many middlemen.
This is not "how to exploit NULL pointers" ... this is "how to exploit a kernel NULL function pointer".
No, it's just the "simplest" example of exploiting NULL pointers. If your NULL pointer is not a function pointer, you can still exploit it in many cases, you just need to work slightly harder.
changing address spaces, which is a costly operation in any architecture.
Not necessarily. What if Intel had real segments, pointing each to a separate address space rather than just being windows into a same global address space.
In a perfect world, each segment would have its own CR3 (page table root), and it would not only be more secure, but also more performant (no flushing of kernel's TLB cache when switching from one process to the other), and would have allowed better "big memory" support under 32 bit systems.
no null pointer reads and writes in kernel mode (which are more common) will get you root.
Wrong
to deference any NULL pointer would effectively be calling that function, assuming this memory mapping really works.
It's not as simple as that. If the kernel contained a read access to that pointer in the exploitable code, it would still perform a read, even though the memory location contained executable code. The only thing would be, that now you would have the numerical value of the instructions in a register, that's it.
But in many cases, the NULL pointer dereference would still be exploitable, it would only be slightly more complicated.
TFA explains how to exploit a theoretical kernel bug that happens to "read a function pointer from address 0, and then call through it". That's a long shot from turning "any NULL pointer" into a root exploit as the summary claims.
Having the NULL pointer being a function pointer was just the easiest "use case" for this kind of bug.
For another example, involving a write to a doubly dereferenced NULL pointer, read here.
And, with most structures containing pointers to other structures, double dereferencing doesn't look so far-fetched.
Here is one example how to exploit a different kind of NULL pointer dereference.
The article is rather long, but the short summary is, the kernel does a->some_field->x=NULL , where a is the NULL pointer.
The NULL page is under the control of the exploiter. So he can set some_field to point to a memory location he wants to zero out. That could be any location in kernel space (such as a hypothetical byte that contains the user id of the current process). In our case, the exploiter used the return address on the stack. Which caused the system call to "return" to address NULL, nicely transforming a "write to NULL" exploit into a "call NULL exploit", and from there, we continue just like in the tutorial.
The point of the article was not to hand you an exploit on a platter, but rather tell you how to leverage 2 kinds of bugs (1. bypassable mmap 0 protection, and 2. an unchecked null pointer dereference) into a root exploit.
Bugs of both classes have existed multiple times in the past (fixed by now), and it is reasonable to assume that more might be discovered in the future.
Lacking any current "real life" instances of such bugs, the article deliberately sets these up, but an actual exploit would of course not depend on custom kernel modules and deliberate misconfiguration of the kernel, but would use 2 real vulnerabilities.
The article highlights dangers of current handling of null pointers (which are used internally in many softwares as meaning "value unknown" or "value not supplied"), but this usage is dangerous as in some rare circumstances, a Null pointer may indeed be dereferenced without triggering an exception.
Also not just any dereference will do, it has to be a function pointer dereference.
The Null pointer doesn't have to be a function pointer. A pointer to a structure containing a function pointer would work too. Or a pointer to a structure that contains a pointer to another structure that will be changed. And many other situations as well. The only thing is, it will be (slightly) harder to exploit, but not impossible.
A 1km-tall stack of cards ... results in a measly 342.89 megabytes
... nice.
But you forgot a nice wording flame:
I could pull out a stack of punch cards 1 km tall and claim it's got 1 TB storage capacity too, thus having 'caught up' with HDDs.
You "catch up" with somebody how had a headstart. Given that HDDs are newer technology than punch cards, it's cute to claim the punch cards could "catch up" with HDDs, even if there was a way to make a 1TB stack of them.
"This isn't helped by the architecture of most SSDs. Usually, data is laid down within a block of available memory, meaning that it might not take up all the available space--yet will still write to all of it"
Does the author think traditional hard drives write to byte-addressable boundaries? Hard drives write blocks and sectors too and have wasted slack space at the end of their blocks too.
Yes, but these blocks of memory might be much bigger than sectors on a hard disk.
And filesystem code in operating systems knows about the (small) sectors of disks, and might not be able to cope with the large blocks of SSDs. Meaning that the SSD must be sufficiently smart to read the entire block, change whatever range needs to be changed, and rewrites it. And this might happen lots of times, because the higher level code (filesystems) might not be aware of the issue.
There is no reason to defrag an SSD because their is no latency getting to a further sector.
There is no latency, but defragging may be useful for a different purpose: making sure that each memory block is occupied by as few different files as possible (in order to dampen the effect of the phenomenon outlined above).
Not if those boys have been to a different church before...
Go back to church dickhead.
And you think priests don't have Gonorrhea?
Younger children did indeed stay.
Older ones (high-school age) didn't bother, and enjoyed the nice extra free time...
I remember one memorable time, when several students were playing cards during geography lesson. Eventually the teacher (peace to his soul) got fed up, and kicked them out with the words "if you like playing cards so much, please go play somewhere else". And when the 4 left, the rest of the class left along with them...
Nowadays, teachers rarely kick anybody out, probably for this reason.
...in the vagina I don't have.
But you do have an arse.
Even if teachers could kick kids out of their classroom, many kids would actually enjoy it. Gee, an hour at the pub, rather than in a boring class! W00t!
Parent should have access to their kids communications, and failure to monitor and stop criminal activity makes them accomplices.
Actually, parents having access to kids' communications could make the situation much worse. The victim's parents would have access to the victim's communication as well, and with if his parents are of the "bullying is good, it builds character" kind? (which they most likely are, in cases like this, or else the kid would already have whined to them, and they would have done sth).
The thing that usually breaks the victim's back is complete lack of support even from their own family. So they try to keep it secret, and carry their cross in isolation.
And, what solution did you use to avoid such tampering? Loading the library via https? Or just praying to God that hackers wouldn't know how to fake a checksum?