Since I don't have any material for a bigger post, I decided to make another 'random thoughts' one, with a couple of smaller things discussed...

Table of Content for today:
1. Bugs in terminal emulators; new PuTTy - minor stuff
2. Compiler optimization & bugs - I found this topic truly amazing (but I feel there is more research to be done in this area)
3. From-Origin: header in HTTP - just another HTTP header (which may or may not render X-Frame-Origin obsolete)

Bugs in terminal emulators; new PuTTy

Reading through the history of hacking (previous century stuff mostly) I've encountered some interesting tricks with the terminal control sequences (aka ANSI escape codes).
The idea is similar to XSS I guess - when you printf() or puts() something on the console you don't usually expect anything weird to happen. While that is true in case of stdout being redirected to a file, that's not really true in case of displaying the text on a terminal (or actually, a terminal emulator). The terminal itself looks for certain sequences of characters which have special meaning (for example \033[1;33;40m) and in case it finds them, it executes additional functionality (e.g. changes text color to hackish-green).
And guess what... you actually could break stuff using these codes. Of course, bugs in control sequence handling implementations made things even more interesting.

I found a cool write up by H.D. Moore about the state of things in 2003, and some other bits and pieces of information at random places (btw, please leave any interesting links in this topic in the comments, thanks!).

Anyway, I decided to take a look at the current state of things some time ago, and reviewed some implementations of the control sequences. I was really amazed on what can you to in a simple text terminal using these sequences! I mean, I knew about changing colors (8 colors + 8 brighter versions of them + 8 background colors), making text blink (old DOS terminal), or moving the cursor around the screen - I've used these while playing with Turbo Pascal years ago. But... I had no idea about some terminals supporting:
- 88 and 256 colors,
- simple graphics (drawing lines, etc),
- changing the content of terminal window's menu
- changing the background image of the window
- inline wide characters (wide as in taking two cells instead of one)
- set tab (\t) offsets
- etc...
Well, most of these are actually disabled by default (yes, you guessed - for security reasons), but they're still fun once re-enabled.

To the point - I didn't really find too much, just two minor DoS'es, one in PuTTY (fixed in newest release), and one in aterm/rxvt (not developed any more). Though I'll probably look a little more later.

As for the PuTTY bug, it was fixed in r9027 (uncredited). The details are provided here, but in short: you need to transfer 2GB of data to achieve an integer overflow which you cannot really do much with, just crash PuTTY. The 2GB are actually semicolons in the \033[param;param;...;m color changing sequence.

As for the aterm/rxvt, the details are here. It's a simple stack exhaustion due to the fact a series of \033[\033[... was handled recursively for some reason. So a simple perl -e 'print "\033["x100000' resulted in terminal crashing.

By the way...
On 22nd Nov'24 we're running a webinar called "CVEs of SSH" – it's free, but requires sign up: https://hexarcana.ch/workshops/cves-of-ssh (Dan from HexArcana is the speaker).

Well, that's that for terminals.

Compiler optimization & bugs

Long story short: in C or C++ if something is considered undefined by the standard, the compilers are free to treat is as they like. And for optimization reasons, the compilers assume they don't know how to treat undefined stuff, so they mostly ignore it (i.e. the undefined-behavior code is not present in the compiled version).
Anyway, I've received a link to awesome write up on this topic from Unavowed (thanks!), and the author quotes one interesting (and, as I was told, well known) example:
void contains_null_check(int *P) {
(1)  int dead = *P;
(2)  if (P == 0)
(3)    return;
(4)  *P = 4;
}
So, since the standard says that dereferencing a NULL is undefined, then it will never happen in a well written code. So, if the compiler sees (1), it assumes that P cannot be NULL, because it would be undefined, and undefined things never happen (again, it's OK to assume this for optimization reasons). At (2) we have a check - "is P NULL", but, the compiler already knows that P cannot be NULL because it was dereferenced at (1), so lines (2) and (3) are unnecessary. And we end up with lines (1) and (4). And of course, P might be NULL at runtime after all, and we'll either end up with a crash, or (in case of different kernel level code) with a null pointer dereference into code execution because of a missing check that is present in the code.
Nasty little surprise I would say.

On a related note... do you remember that the sequence of completion of operations is not always well defined in C/C++? There was an interesting bug in webp because of that (discovered by guys from Opera btw).
In short, it was a situation like this:
x = (GetByte() << 8) | GetByte();
And the question is... which GetByte() will be called first? The obvious, but incorrect answer, is "the first one". Well, the standard doesn't really says which one will be called first, and the compilers implement it differently (see my linked above blog post). So the bottom line is: do not write it like that; make sure you complete the first GetByte before calling the second (e.g. x = GetByte() << 8; x |= GetByte();).

It would be cool to make a write-up/collection of such 'nasty little surprises' ;>

From-Origin: header in HTTP

Just two links:
http://www.w3.org/TR/2011/WD-from-origin-20110721/ - The From-Origin Header
http://tools.ietf.org/html/draft-ietf-websec-origin-02#section-7.1 -  The Web Origin Concept
The header seems to address quite a few problems, and personally I like it more than X-Frame-Options. I'm interested too see how it plays out :)

And that's that :)