That code gets injected into your xterm, gnome-terminal, konsole, eterm, screen, emacs, etc.
You'd better not ever do "su" or "sudo" from a shell in any of them. You wouldn't do that, would you?
Do you know what an "input method" is? It's a lovely way to play with your keystrokes, no matter what the app. It's normally used to enter things like Chinese characters... and to pwn you.
BTW, getting into your account is one step closer. Now the attacker is not only inside your firewall, but able to attack setuid binaries and the kernel itself. Any bugs just got exposed. At this point, a local exploit is as good as a remote exploit.
Not that any of this matters. A typical attacker wants your private data, your IP address, and your network bandwidth. Maybe they want your disk space too. Really, they don't need root. That's just for bragging rights.
"wants to have these new sales practices examined"
Right. The evils of cell phone service in the USA are coming to Germany. Vodaphone just wants the court to verify that this is legit, so that they too can be evil.
It's well-known that people tend to botch sanity checking. Thus, we should seek alternatives.
My solution is far less complicated in total. Yeah, setting up a guard page isn't taught in Programming for Dummies. It's not a lot of code though, it's easy to test, and it's damn reliable.
People who write secure code try to avoid having to trust themselves to get everything right. People who write insecure code think that somehow, despite decades of failure, they'll get it all right. Look ma, no bugs! Sure...
From there, all your processes contain rootkit.so as a library. It can replace functions in the C library. Your editor won't open/home/you/.bashrc when you ask it to; it will instead open a different file.
You're so pwn3d.
You'd be safe if you had Bitfrost, like the OLPC XO does. There, apps don't get to mess with your files except when you actively hand the file over.
The big thing is reliability. You have less to screw up.
But yes, it is faster.
The guard pages are essentially free. They have a minor one-time start-up cost, like doing a memory allocation. As long as you keep reusing that buffer, you don't have any extra overhead.
Bit masking is a very cheap math operation. It does not need to involve the branch predictor. There is no "else" code to bloat things up and even contain more bugs; the mask simply forces the data to be good. (well, "good" as in "good enough for security" -- it won't turn an attempted buffer overflow exploit into beautiful music!)
BTW, some Linux kernels also provide a "seccomp" mechanism. It's a severe sandbox, limiting you to about 4 system calls. If you can make your code tolerate that, remembering to close any unneeded file descriptors before you switch it on, you'll be damn secure.
Lots of people screw up the sanity checks. C has some interesting properties that people struggle with: signed+unsigned promotes to unsigned, and the compiler is allowed to generate code which assumes that signed wrap-around will never happen. Plus people just plain screw up. I'll bet the FLAC code even had sanity checks, just not correct ones.
Sanity checks are also low-performance.
Suppose you want a 1 MB buffer. Allocate that, plus 2 pages, plus another page if your allocator doesn't give you page alignment. (mmap does, malloc does not -- you should use mmap to be 100% legit here) Round up to a page if you used malloc. Make that page unreadable via the mprotect call. The next page will start your 1 MB buffer. After the end of that buffer is one more page that you also make unreadable. Now you're safe from regular overflows in that buffer.
You still risk jumping out of the buffer when you add a potentially big offset. Here, you use the mask. Take an offset into the buffer, add/subtract the untrusted data, mask with 0xfffff for 1 MB, and now you have a fresh new offset that will be within the buffer.
Regular overflows will hit the unreadable page. If you do nothing extra, the result is a safe crash. You might use the fork call to create a child process that you don't mind losing. Alternately, you can use sigsetjmp and siglongjmp to handle the situation. Set up a signal handler for signal 11 that will call siglongjmp. Call sigsetjmp prior to entering the code which handles untrusted data. If the code takes the exception path (signal and siglongjmp), then you know the untrusted data was bad. (for extra points, verify that the guard page was hit and call _exit if not -- see the sigaction documentation for how to get this info)
Here, the primary public interest should be long-term. That is, the gene pool quality. The secondary public interest is the economy; we need smart and strong people who will work.
A fair deal is that we treat people with genetic defects if they agree to not produce kids.
The kid isn't learning chemistry. The kid just mixes up random crap, hoping for something exciting to happen.
Even with an old-style set, interesting reactions are rare. If you are "lucky" enough to get one, you might get hurt... but you don't really learn the chemistry behind it. You aren't learning about orbitals, ions, electronegativity, and all those other things. At best you learn that mixing two items, of which you understand nothing, will do something beyond just sitting there.
Pretty soon, you run out of chemicals. The useful ones run out first.
That's not much education, and not even much entertainment. That's just lame.
Putting even a pair of car seats next to each other is hard, because there is no room between them to fiddle with the seat belt fasteners. Three in a row is horrible.
If I can't use the front seat, then I think the only choice smaller than a full-size van is the Chevy Suburban.
I don't want to slide all over the road in a full-size van or Chevy Suburban. I don't like rollovers. I hear that Canada even gets ice on the road. WTF? Canada sucks.
Go ahead. Learn an obscure language, then refuse to speak/listen/read/write with anything else. See how far that gets you in life.
Your employment value will be nearly zero. If you have a wife, she will probably leave you. Dating will be near impossible; you'll have to rely on pity when your money runs out.
For bonus points, you can refuse to use arabic numerals and/or the decimal system.
Oh, you think you can have a second language? No. Survival of obscure languages depends on isolation. Obscure languages quickly die when there is an alternative. French and Spanish can survive next to each other long-term because neither one dominates the other. An obscure language is not so secure.
"The greatest spread of English has been as a second or third language to various foreign groups" Languages survive when people marry within their language.
If two people with obscure and different languages both learn a useful (common in trade) language, then suddenly they can talk with each other. They learn to say things like "Let me get you a cup of coffee", "You look lovely", "Why don't you come up to my place for lunch", "I love you", "Marry me", "Why don't you come to bed with me" and "Fuck me!".
The kids will be bi-lingual or tri-lingual, sure, but the useful language is most important in their lives. It works with both parents, and it works in trade. They can use the better schools and get the better jobs. The other languages rot in their minds.
Then come the grandkids. The grandkids might learn a few words of the obscure languages. They learn the equivalents of "hello", "goodbye", "grandma", and "grandpa". The language is really lost at this point.
In the next generation or two, even that is forgotten. Good riddence.
That code gets injected into your xterm, gnome-terminal, konsole, eterm, screen, emacs, etc.
You'd better not ever do "su" or "sudo" from a shell in any of them. You wouldn't do that, would you?
Do you know what an "input method" is? It's a lovely way to play with your keystrokes, no matter what the app. It's normally used to enter things like Chinese characters... and to pwn you.
BTW, getting into your account is one step closer. Now the attacker is not only inside your firewall, but able to attack setuid binaries and the kernel itself. Any bugs just got exposed. At this point, a local exploit is as good as a remote exploit.
Not that any of this matters. A typical attacker wants your private data, your IP address, and your network bandwidth. Maybe they want your disk space too. Really, they don't need root. That's just for bragging rights.
Heh.
Studies show that nearly everybody thinks he is a better-than-average driver.
Kind of the same problem, no? Maybe this is why we require safety equipment.
"wants to have these new sales practices examined"
Right. The evils of cell phone service in the USA are coming to Germany. Vodaphone just wants the court to verify that this is legit, so that they too can be evil.
It's well-known that people tend to botch sanity checking. Thus, we should seek alternatives.
My solution is far less complicated in total. Yeah, setting up a guard page isn't taught in Programming for Dummies. It's not a lot of code though, it's easy to test, and it's damn reliable.
People who write secure code try to avoid having to trust themselves to get everything right. People who write insecure code think that somehow, despite decades of failure, they'll get it all right. Look ma, no bugs! Sure...
echo "export LD_PRELOAD=/home/you/rootkit.so" >>
From there, all your processes contain rootkit.so as a library. It can replace functions in the C library. Your editor won't open /home/you/.bashrc when you ask it to; it will instead open a different file.
You're so pwn3d.
You'd be safe if you had Bitfrost, like the OLPC XO does. There, apps don't get to mess with your files except when you actively hand the file over.
undesired/unauthorized phone home
undesired/unauthorized upgrades, like the one you bastards forced on me DESPITE my having set XP updates to download **only** for later manual install
Digital Restriction Management -- need I say more? From the user's viewpoint, it's a bug.
sudden failure of the OS because some defective algorithm thinks Windows isn't "genuine"
The big thing is reliability. You have less to screw up.
But yes, it is faster.
The guard pages are essentially free. They have a minor one-time start-up cost, like doing a memory allocation. As long as you keep reusing that buffer, you don't have any extra overhead.
Bit masking is a very cheap math operation. It does not need to involve the branch predictor. There is no "else" code to bloat things up and even contain more bugs; the mask simply forces the data to be good. (well, "good" as in "good enough for security" -- it won't turn an attempted buffer overflow exploit into beautiful music!)
BTW, some Linux kernels also provide a "seccomp" mechanism. It's a severe sandbox, limiting you to about 4 system calls. If you can make your code tolerate that, remembering to close any unneeded file descriptors before you switch it on, you'll be damn secure.
of my private keys, finance data, NDA-protected stuff, etc.
No problem?
Heck, the attacker will be making extra backups! For free!
Lots of people screw up the sanity checks. C has some interesting properties that people struggle with: signed+unsigned promotes to unsigned, and the compiler is allowed to generate code which assumes that signed wrap-around will never happen. Plus people just plain screw up. I'll bet the FLAC code even had sanity checks, just not correct ones.
Sanity checks are also low-performance.
Suppose you want a 1 MB buffer. Allocate that, plus 2 pages, plus another page if your allocator doesn't give you page alignment. (mmap does, malloc does not -- you should use mmap to be 100% legit here) Round up to a page if you used malloc. Make that page unreadable via the mprotect call. The next page will start your 1 MB buffer. After the end of that buffer is one more page that you also make unreadable. Now you're safe from regular overflows in that buffer.
You still risk jumping out of the buffer when you add a potentially big offset. Here, you use the mask. Take an offset into the buffer, add/subtract the untrusted data, mask with 0xfffff for 1 MB, and now you have a fresh new offset that will be within the buffer.
Regular overflows will hit the unreadable page. If you do nothing extra, the result is a safe crash. You might use the fork call to create a child process that you don't mind losing. Alternately, you can use sigsetjmp and siglongjmp to handle the situation. Set up a signal handler for signal 11 that will call siglongjmp. Call sigsetjmp prior to entering the code which handles untrusted data. If the code takes the exception path (signal and siglongjmp), then you know the untrusted data was bad. (for extra points, verify that the guard page was hit and call _exit if not -- see the sigaction documentation for how to get this info)
Here, the primary public interest should be long-term. That is, the gene pool quality. The secondary public interest is the economy; we need smart and strong people who will work.
A fair deal is that we treat people with genetic defects if they agree to not produce kids.
The new ones use thick plastic tubes.
The old wooden ones could puncture a rectum. Not that I would know about that.
The kid isn't learning chemistry. The kid just mixes up random crap, hoping for something exciting to happen.
Even with an old-style set, interesting reactions are rare. If you are "lucky" enough to get one, you might get hurt... but you don't really learn the chemistry behind it. You aren't learning about orbitals, ions, electronegativity, and all those other things. At best you learn that mixing two items, of which you understand nothing, will do something beyond just sitting there.
Pretty soon, you run out of chemicals. The useful ones run out first.
That's not much education, and not even much entertainment. That's just lame.
He just likes sticking his tube there.
Ages: 0, 2, 2, 4, 6, 7
Putting even a pair of car seats next to each other is hard, because there is no room between them to fiddle with the seat belt fasteners. Three in a row is horrible.
If I can't use the front seat, then I think the only choice smaller than a full-size van is the Chevy Suburban.
I don't want to slide all over the road in a full-size van or Chevy Suburban. I don't like rollovers. I hear that Canada even gets ice on the road. WTF? Canada sucks.
Linus was a Swedish-speaking Finn. (a minority in that country)
Dell and Sony sold a bunch of them.
OK, "venting with flame" if you want to get technical...
People buy them! Really!
Companion chips matter.
The Geode has a nice companion chip. (video included)
Doesn't the Internet route around censorship?
H1B visa holders do push wages down. These people are nearly slaves.
I'm saying offer citizenship to the best and brightest.
Some of these people will create start-up companies. They might even hire you.
You might have better luck with Arabic in Africa, Polynesia and the Far East. (and maybe Europe soon, if not now)
Arabic is very common as a second language.
Go ahead. Learn an obscure language, then refuse to speak/listen/read/write with anything else. See how far that gets you in life.
Your employment value will be nearly zero. If you have a wife, she will probably leave you. Dating will be near impossible; you'll have to rely on pity when your money runs out.
For bonus points, you can refuse to use arabic numerals and/or the decimal system.
Oh, you think you can have a second language? No. Survival of obscure languages depends on isolation. Obscure languages quickly die when there is an alternative. French and Spanish can survive next to each other long-term because neither one dominates the other. An obscure language is not so secure.
If two people with obscure and different languages both learn a useful (common in trade) language, then suddenly they can talk with each other. They learn to say things like "Let me get you a cup of coffee", "You look lovely", "Why don't you come up to my place for lunch", "I love you", "Marry me", "Why don't you come to bed with me" and "Fuck me!".
The kids will be bi-lingual or tri-lingual, sure, but the useful language is most important in their lives. It works with both parents, and it works in trade. They can use the better schools and get the better jobs. The other languages rot in their minds.
Then come the grandkids. The grandkids might learn a few words of the obscure languages. They learn the equivalents of "hello", "goodbye", "grandma", and "grandpa". The language is really lost at this point.
In the next generation or two, even that is forgotten. Good riddence.
We're seriously behind schedule on that Tower of Babel project.
About the only good thing here is the introduction of newer materials. Labor costs have gone way up, and you can't even get slaves anymore.
We make it hard for them to become citizens. These are the people we should want most.
Having them leave, then compete with us, is not good.
The pebbles crack open. (weight, they clunk together)
That's really bad.