I though it might be interesting to see if it could be possible to execute code via escape codes sent to a victims terminal, by getting them to view a file with cat or less -r, or via some other application (mua[1], or tail'ing syslog messages, for example) that doesn't filter escape sequences (see [1] for lots of examples if you're interested). H.D. Moore discovered some interesting oddities in his paper[2] , although he was more interested in abusing legitimate functions, I'm interested in finding bugs that might lead to a compromise. I briefly checked aterm, xterm and Eterm. Eterm's developer has obviously been working hard since H.D. Moore's criticism, I couldn't spot any way to do anything strange with the latest version, and it was easily the most resilient, I couldnt get it to dump core or stop responding, which is trivially easy with the others I tested. I had a little more success with xterm, getting it to hang is fairly trivial, but one thing that jumped out at me was you could bypass the margin sanity checks by using some of the more obscure escape sequences, for example: $ printf "%b" \\x9B\\xBB\\x32\\x72\\x0A\\x1B\\x5B\\x32\\x34\\x3B\\x31\\x48\\x1B\\xEC\\x0A\\x8D * use set scrolling region to set bottom margin to 0 * move the cursor to row 23 (tput cup 23) * use HP_MEM_LOCK to set the top margin to the current position * use Reverse Index (tput ri) to trigger a line insert * using various positions or sequence variations you can overflow an integer and control a malloc/realloc. * I know the general rule is if a malloc() uses a user-specified argument it's gameover security-wise, perhaps someone on the security team with a little more expertise can take a look, i think it might be promising. Regardless, it's an easy fix, and probably worth the one line of code to add a sanity check to the HP_MEM_UNLOCK case, closing the loop. I also spotted an oddity in aterm, a race condition that results in a double free(), I don't know whether this is exploitable or not, but I suspect it might be in the right (unlikely, but perhaps possible) conditions. Basically, if a child process exits during a scroll operation, aterm is sometimes interrupted while rearranging the elements of an array (the text buffers that an attacker can send), which can result in a double free() (you can start aterm with a huge buffer to improve the chances of beating the race condition if you want to experiment, aterm -sl 5000, for example). Again, someone from the security team might like to take a look, but I think it's worth being proactive and applying these patches rather than waiting for a PoC :) Patches attached, feel free to disregard if appropriate :) [1] http://www.digitaldefense.net/labs/papers/Termulation.txt
Created attachment 46846 [details, diff] xterm patch
Created attachment 46847 [details, diff] aterm patch
Created attachment 46857 [details, diff] xterm patch (fixed typo)
I can't really do anything about this right now, because I'm away from my Gentoo box and sorta half on vacation. Unfortunately, the rest of the Audit team is similarly disposed. The patches *look* semi-reasonable, but perhaps the xterm and aterm source could both be reviewed a bit more by one of us in the future. In the meantime, I'm going to CC X11 and aterm's maintainer and hope that they'd be willing to check out these patches (or, perhaps someone else on the security team could do us the favor). If nobody else deals with this soon, I'll be able to get to it in about two weeks. Thanks, Tavis
Adding Thomas Dickey so that we can get his opinion on this stuff.
I'll add it to my to-do list (am expecting to work on xterm on Thursday). Perhaps a list of the "trivially easy" issues would be useful.
Hi Thomas, although causing a hang seemed easy during my testing I didnt make a note of how I accomplished it and unfortunately cannot seem to reproduce it! Please disregard that comment and I'll make a proper report if I can get a testcase. Incidentally, I hope you accept this report in the "many eyes" spirit it was intended and not whining, I think I could have worded the report a little better :)
Thanks anyway - I'm interested in fixing things like that, of course. I'm working right now on issues related to the margins. That's really part of a larger problem (as you may see by adding -Wconversion to the compiler warnings). Patch #198 will have a lot fewer of those, and make some additional checks.
see http://invisible-island.net/xterm/xterm.log.html#xterm_198
Added xterm-199, which fixes this. Thanks Thomas.
OK, if someone could fix aterm, I'll CC the archs and try to get them marked stable. I suppose we could investigate the exploitability more, but realistically, I won't have time. Security Team, care to vote on issuing a GLSA for these matters (once they're cleared up)>
I had a look at the aterm code. Please correct me if I'm wrong, but from what I can see in the scroll_text() function, the elements in the buffer are shifted by <count> elements, not by 1. Therefore, your patch would only prevent the double free in case count == 1.
Fixed in aterm-0.4.2-r12 and aterm-1.00_beta2.
Thanks Michal, as I mentioned on irc you were right about the scroll count :)
thanks everyone, resolving.
