One thing I don't understand is the seemingly common paranoia towards "executable code" in the discussions here.
First, there's no fundamental difference between "code" and "data". It's all binary blob. The.text section in any of your ELF programs is understood as "executable code" by the interpreter (ld.so) but as plain document by objdump. The point is to always interpret the data as how it is intended to be used, and this is hard. This Adobe fiasco is caused by a buffer overflow in the program (which is not even in a function responsible for JavaScript). Buffer overflows are known to be useful for exploits because they allow an attacker to "cheat" the program so that it misinterprets what intended to be document data as executable code. It just happens that the flawed code can be attacked with greater rate of success using JavaScript. (According to this security advisory http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090219)
Second, embedding executable code in a document is not inherently evil or stupid. It's just an idea that can be either utilized or abused, varying from implementation to implementation. I don't like scripting in PDF either but not for the reason of its alleged insecure nature, but because it bloats the file format.
No mention of SSH in the abstract? I thought that was quite obvious a choice. Oh wait, you'll have to get a shell access to a server outside the wall in the first place.
Basically there's no difference between executable code and non-executable data by nature. The problems is caused by a buffer overflow error in the program, which allows arbitrary code execution, bypassing the usual, intended input validation (if any).
So, this has nothing to do with the document format standard. Even if the standard forbids executable code (whatever that means), a coding error could render this kind of protection futile.
Supposedly Debian (from Sid onwards) also does not allow 'rm -rf/'.
This is not Debian-specific. Just RTFM of rm(1) from GNU Coreutils and you'll see the option --preserve-root is enabled by default. To override it use --no-preserve-root. Mine's coreutils-6.12 here.
Of course you can see this as another disadvantage of GNU.
But if the word "game" is broadened to include all kinds of games not necessarily video games, I say it's chess. Chess has become part of history in both the West and the East (China, Korea and Japan all have traditional board games originated from the same root with chess and they remain very similar to each other to this day). In China it's even part of the language -- there are many idiomatic phrases that originated as game terms. And after all these years it's still fun to play.
(I can imagine using a photo application for JPEGs alone, but they will still pull in every image library using the dynamic linker, at load time.. and all these plugins will be spread across by disk)
I don't think this is how it's done... In your example, the functions in a imaging library only have their stubs in the PLT (procedure linkage table) loaded into the process. A stub is replaced by the real code once it gets called. If a non-JPEG backend is not used, it will not be loaded into the memory. The argument of disk usage remains valid, though.
I'm afraid the boost of kernel code won't help you much. Since you're doing fluid physics, I guess the hotspots are in the floating point math computation, and your code doesn't do context switching often. In that case, kernel speed isn't that important.
I can't judge because my experience with ICC is minimal. GCC is constantly improving, but I feel it concentrates more on platform support than performance. The GCC team has to work on ARM/MIPS/SPARC/whatever while ICC only need to work on x86.
So I'm not surprised to see GCC falling behind Intel in x86 performance. In fact, only recently did GCC began to support local variable alignment on the stack, which I think is a basic optimization technique. (See the 4.4 pre-release notes http://gcc.gnu.org/gcc-4.4/changes.html, search for the phrase "align the stack" in that page)
The Mac OS X kernel is based on the Mach microkernel (so does GNU HURD). Many basic system tools (ps, kill, ls, top, etc...) are inherited from BSD Unix and some are from GNU (such as BASH). Of course Apple has made a lot of their own contributions e.g. most of the GUI.
I am feeling very left out, I can't seem to find Conficker B++ or even Conficker B in my yum repository. sigh... It is such a shame that linux is always behind the curve as far as new and exciting features are concerned.
'Coz the distro maintainers refused to include non-opensource binary blob in their repo.
Make yourself heard. Chances are the malware author is considering opensourcing it too but no one's asking for it so far.
It's a whole new arena from which the Chinese hackers can continue to launch their lame--but oh, so annoying--port scans and root login attempts)
Don't think so. These servers mostly appear to be virtual hosts managed by Tencent (operator of QQ) for its blogging service. Kinda like the _____.blogspot.com hostnames. I understand you point --- these crappy servers are likely to be exploited or even rooted for malicious purposes due to sloppy QA, but I think the actual number of those machines are not that high hence not that big deal of a "threat".
Of course I may be wrong about it. But given that there's almost nobody except Tencent themselves actually deploying the server, I guess it's just some in-house quick-and-dirty project specially tailored for their business.
Oh by the way, as a Chinese, I feel kinda sorry for your frustration. I can understand that, 'coz I have similar experiences with those nasty hackers (I'm not an admin, but I know it from some experimentation involving a SSH honeypot). I don't know whether this idea will help, but think in this way: you can think of "blocking the whole country", while it's unimaginable for some honest guy in China who operates a website targeting at Chinese markets. Try looking on the bright side -- at least these hackers are making you tougher and more experienced.
On a large directory structure it will actually (partially) fail in a nasty heap, since you probably won't be able to fit the list of all files (and directories and...) into the command line space.
I figured it out that too after I posted the reply. The new glob is a nice feature though, when the directory tree is not too high or crowded.
The ** glob is expanded only when the option "globstar" is set. If backward compatibility is a key issue for you, be sure not to set it when running old scripts.
Re:Ant-style ** globbing
on
BASH 4.0 Released
·
· Score: 4, Interesting
The scary thing "rm -f/**", when used with the new shopt "globstar", removes all non-directory files while preserving the directory skeleton. It's kinda like vaporizing everyone in the town while leaving all the empty buildings and cars intact...
Slashdot Mirror
One thing I don't understand is the seemingly common paranoia towards "executable code" in the discussions here.
First, there's no fundamental difference between "code" and "data". It's all binary blob. The .text section in any of your ELF programs is understood as "executable code" by the interpreter (ld.so) but as plain document by objdump. The point is to always interpret the data as how it is intended to be used, and this is hard. This Adobe fiasco is caused by a buffer overflow in the program (which is not even in a function responsible for JavaScript). Buffer overflows are known to be useful for exploits because they allow an attacker to "cheat" the program so that it misinterprets what intended to be document data as executable code. It just happens that the flawed code can be attacked with greater rate of success using JavaScript. (According to this security advisory http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090219)
Second, embedding executable code in a document is not inherently evil or stupid. It's just an idea that can be either utilized or abused, varying from implementation to implementation. I don't like scripting in PDF either but not for the reason of its alleged insecure nature, but because it bloats the file format.
Just my 2c..
No mention of SSH in the abstract? I thought that was quite obvious a choice. Oh wait, you'll have to get a shell access to a server outside the wall in the first place.
Basically there's no difference between executable code and non-executable data by nature. The problems is caused by a buffer overflow error in the program, which allows arbitrary code execution, bypassing the usual, intended input validation (if any).
So, this has nothing to do with the document format standard. Even if the standard forbids executable code (whatever that means), a coding error could render this kind of protection futile.
This is not Debian-specific. Just RTFM of rm(1) from GNU Coreutils and you'll see the option --preserve-root is enabled by default. To override it use --no-preserve-root. Mine's coreutils-6.12 here.
Of course you can see this as another disadvantage of GNU.
Of course not! It's Evolution 2.0!
And how is it different from any other kind of selective breeding?
Heck, not "basement". I meant to type "base"! Now cue the jokes of "your mom's basement" ...
On the console, I choose Tetris.
But if the word "game" is broadened to include all kinds of games not necessarily video games, I say it's chess. Chess has become part of history in both the West and the East (China, Korea and Japan all have traditional board games originated from the same root with chess and they remain very similar to each other to this day). In China it's even part of the language -- there are many idiomatic phrases that originated as game terms. And after all these years it's still fun to play.
</off-topic>
Shanzhai in Chinese refers to a camp or basement of mountain bandits in the original meaning.
I don't think this is how it's done... In your example, the functions in a imaging library only have their stubs in the PLT (procedure linkage table) loaded into the process. A stub is replaced by the real code once it gets called. If a non-JPEG backend is not used, it will not be loaded into the memory. The argument of disk usage remains valid, though.
This is called "deniable encryption". However, there's debate regarding whether TrueCrypt's implementation is really effective.
I'm afraid the boost of kernel code won't help you much. Since you're doing fluid physics, I guess the hotspots are in the floating point math computation, and your code doesn't do context switching often. In that case, kernel speed isn't that important.
Well, I'm just saying it. I hope I'm wrong :)
hmm, you are right, I was using the term "x86" rather loosely..
I can't judge because my experience with ICC is minimal. GCC is constantly improving, but I feel it concentrates more on platform support than performance. The GCC team has to work on ARM/MIPS/SPARC/whatever while ICC only need to work on x86.
So I'm not surprised to see GCC falling behind Intel in x86 performance. In fact, only recently did GCC began to support local variable alignment on the stack, which I think is a basic optimization technique. (See the 4.4 pre-release notes http://gcc.gnu.org/gcc-4.4/changes.html, search for the phrase "align the stack" in that page)
How can a poll be without CowboyNeal? BOYCOTT NASA!!!11!1
udftools is included in most distros. You don't even need to download from SF directly.
The Mac OS X kernel is based on the Mach microkernel (so does GNU HURD). Many basic system tools (ps, kill, ls, top, etc...) are inherited from BSD Unix and some are from GNU (such as BASH). Of course Apple has made a lot of their own contributions e.g. most of the GUI.
But is it an European or an African flying car?
I am feeling very left out, I can't seem to find Conficker B++ or even Conficker B in my yum repository. sigh... It is such a shame that linux is always behind the curve as far as new and exciting features are concerned.
'Coz the distro maintainers refused to include non-opensource binary blob in their repo.
Make yourself heard. Chances are the malware author is considering opensourcing it too but no one's asking for it so far.
It's a whole new arena from which the Chinese hackers can continue to launch their lame--but oh, so annoying--port scans and root login attempts)
Don't think so. These servers mostly appear to be virtual hosts managed by Tencent (operator of QQ) for its blogging service. Kinda like the _____.blogspot.com hostnames. I understand you point --- these crappy servers are likely to be exploited or even rooted for malicious purposes due to sloppy QA, but I think the actual number of those machines are not that high hence not that big deal of a "threat".
Of course I may be wrong about it. But given that there's almost nobody except Tencent themselves actually deploying the server, I guess it's just some in-house quick-and-dirty project specially tailored for their business.
Oh by the way, as a Chinese, I feel kinda sorry for your frustration. I can understand that, 'coz I have similar experiences with those nasty hackers (I'm not an admin, but I know it from some experimentation involving a SSH honeypot). I don't know whether this idea will help, but think in this way: you can think of "blocking the whole country", while it's unimaginable for some honest guy in China who operates a website targeting at Chinese markets. Try looking on the bright side -- at least these hackers are making you tougher and more experienced.
Good luck :)
I'd rather say "think of the penguins." We'll have to wait a few more years for Linux on the desktop due to this...
I figured it out that too after I posted the reply. The new glob is a nice feature though, when the directory tree is not too high or crowded.
The ** glob is expanded only when the option "globstar" is set. If backward compatibility is a key issue for you, be sure not to set it when running old scripts.
The scary thing "rm -f /**", when used with the new shopt "globstar", removes all non-directory files while preserving the directory skeleton. It's kinda like vaporizing everyone in the town while leaving all the empty buildings and cars intact...
http://tiswww.case.edu/php/chet/bash/CHANGES
Not a summary but a listing of incremental changes i.e. changes between 4.0 and 4.0-rc1, rc1 and beta2, beta2 and beta1, etc.
... and thanks for all the fish.