Underhanded C 2015(blog.mattbierner.com)
blog.mattbierner.com
Underhanded C 2015
http://blog.mattbierner.com/underhanded-c-2015/
11 comments
"These are the stakes. We must trust in C, or we must die."
Dear God... lol
Dear God... lol
"All your base are belong to us" post, but the contest looks interesting :-D
P.S. my English is also terrible.
P.S. my English is also terrible.
What insane compiler/platform sets string data as executable memory?
Gcc with default options does. I was curious about this and tested it, expecting to get a segmentation fault, but to my surprise string constants are executable. A mutable string, however (char data[] instead of char *data), is not executable. I don't think this is a totally insane vulnerability or anything, since no memory is both writeable and executable at once.
You may be interested to know that there has recently been a notable movement in systems security research to push for an "execute-only" permission, that makes executable data unreadable in addition to unwriteable. This has come in response to certain attacks (i.e. http://www.ieee-security.org/TC/SP2013/papers/4977a574.pdf) that use scripting languages (such as JS or Flash's actionscript) to read all of memory at exploit time and use this knowledge to craft a payload that bypasses ASLR.
So, works such as http://www.ics.uci.edu/~sjcrane/papers/sjcrane15_readactor.p... (and several others) are attempting to come up with systems that can prevent this type of attack by preventing executable memory from being read in the first place. This is made difficult not only by the fact that even if processors could support such permissions (many generally can't in any efficient fashion), but also due to the fact that many compilers frequently mix together executable code and static data, such as strings. The second paper I linked is about instrumenting LLVM to ensure that it always outputs readable data and code in separate sections.
Having been involved in such research myself, I can confidently respond to the parent's question too by saying that, if anything, a majority of modern compilers freely mix code and data. In addition, there is often data that is directly related to code, such as tables of addresses used in a switch statement, but is never intended to be directly executed. Even if it would work just fine to place such tables in a read-only section, it may make logical sense to the compiler authors to place it in the vicinity of where it is used (that is, in the executable data section).
So, works such as http://www.ics.uci.edu/~sjcrane/papers/sjcrane15_readactor.p... (and several others) are attempting to come up with systems that can prevent this type of attack by preventing executable memory from being read in the first place. This is made difficult not only by the fact that even if processors could support such permissions (many generally can't in any efficient fashion), but also due to the fact that many compilers frequently mix together executable code and static data, such as strings. The second paper I linked is about instrumenting LLVM to ensure that it always outputs readable data and code in separate sections.
Having been involved in such research myself, I can confidently respond to the parent's question too by saying that, if anything, a majority of modern compilers freely mix code and data. In addition, there is often data that is directly related to code, such as tables of addresses used in a switch statement, but is never intended to be directly executed. Even if it would work just fine to place such tables in a read-only section, it may make logical sense to the compiler authors to place it in the vicinity of where it is used (that is, in the executable data section).
What does 觬巂 actually, if anything, mean?
Based on [0], I would say that it is Bobspeak for error :). For those to lazy to look, the first result for "觬巂" in google is this article. Of the remaining first page results, the string "觬巂" never appears.
[0] https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...
[0] https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...
Based on the article it should mean _something_ in Chinese but you won't fool the Chinese with that and the English wouldn't use Chinese error messages.
I couldn't find any dictionary that could find that word. Google translate lists it as "Nijuan", which I would assume is just Google using a phonetic system on the assumption that it is a name.
Yes, I'm a Chinese and to me this is just two rare Chinese characters placed together. It doesn't have any meaning.
Also fortunately, it is standard in the glorious nation of Bob to represent text as an undifferentiated mixture of big-endian UTF-16 and ASCII.
(The floating-point hack is clever, but I find the string quite unconvincing and an obvious place to hide something malicious, and trying to explain it as Unicode doesn't hold up.)