Hi, I wrote an exploit for xorg (more by exident than by plan), which makes it possbile that one user can read "screen data" of an other user, which is running xorg on the system. (It seems to be a xorg bug but maybe it's even a problem with Linux itself). xorg-X11: 6.8.2-r1 Linux: 2.6.12-rc1 (I know i,... ;) These small "photo story" should explain the problem well enough: http://img292.imageshack.us/my.php?image=strangestory04nk.png http://img292.imageshack.us/my.php?image=strangestory18xh.png Please ask for more information, i don't want to write too much now.
well chances are good we're going to need a lot more info here for starters, how can we reproduce it locally
Ajax, would appreciate your input on this.
Ok, here comes a short version of my code, the orginal one is a bit complexer and seems to give other (better) data aswell (subjective): #########################CODE############################## #include <iostream> #include <QApplication> #include <QLabel> #include <QPixmap> int main(int argc, char *argv[]) { QApplication app(argc, argv); int x,y; std::cout << "(Sep. 2005) Aurel \"DustyDingo\" Wildfellner, use this only for fixing the bug! \n"; std::cout << "This is an exploit for xorg (written by exident), it will display randomly some image data even from other users, who run xorg at the same time. It's a bit like lotto, type in two numbers (0-1000 are ok, but try what you want), they are more for the size, but sometimes they influence the result too. \n"; std::cout << "type in an integer number (x)# "; std::cin >> x; std::cout << "type in an integer number (y)# "; std::cin >> y; QLabel label; QPixmap pixmap(x,y); label.setPixmap(pixmap); label.show(); return app.exec(); } ############################CODE############################## You need Qt4 to build this code: # qmake -project # qmake # make and run it Tested with: Gentoo Linux (of course) Linux 2.6.12rc1 xorg-X11 6.8.2-r1 (which is stable btwn.) Qt for this exploit: Qt-Copy from kdesvn trunk Qt linked from kde: 3.3.4-r5 KDE 3.4.1 Fluxbox The best way to reproduce it is to make the same things as in my screenshots before. Try it several times also with restarting xorg or even the whole system, because it is not for sure, if it works immediately. Try to produce many imagedata before running the code, like watching a movie, serving the web or browse your personal photos. Also try to run it with an different user under the same wm (open a shell, su - otheruser, and run it).
without knowing qt too well, it's hard to say what this code is actually doing. however: X makes no effort to zero out framebuffer memory on VT switch. i believe pixmaps are initially created with "undefined" contents. so on switch, the first server leaves the old pixmap data in place; and the second server allocates some offscreen range that happened to be used by the first server. in some sense this is a non-issue, because the attack requires both that you have two servers running on the same card and that the attacker has essentially physical access to the machine, in which case you're pretty well boned already. but if we decide it's a real issue we can just put a memset in the right place.
i let this image speaking for me: http://img75.imageshack.us/my.php?image=snapii0zackawatztllsssaaal0kl0.png Ok it's a successful atack. So, now we are all in complete agreement that it is a issue, we should be very careful, and those who are able to fix it should start. ;)
I dont see how this could possibly be an issue, If two servers are running on the same physical machine, user A can simply switch to B's server and do whatever he likes. This is no more a security issue than user A logging in on vt1 and user B logging in on vt2 and then user A switching over to user B's terminal when he's not looking. Unless anyone has anything to add, I think this one is INVALID.
What if you consider the multiple monitors/keyboards/mice case, where they're both simultaneously not just running, but using, X?
Spyderous: why would there be a vt switch in that case?
(In reply to comment #8) > Spyderous: why would there be a vt switch in that case? there wouldn't. the attack can only happen when you have two users running on the same card (though perhaps not at the same time: first user logs out, second user logs in is also a valid attack path).
You don't need two running x-servers at the same time for that. It also works, when there was a user who runs xorg before and loggs out (also shut down the xsrver). After that an other user can logg in and see screendata from the previos user. This is a security problem on boxes with severall users, like temrinals in schools, universities or some office pcs. I thought that this was clear, and at least a probleme which should be fixed.
no, the problem with this bug is that there really wasnt a whole lot of explanation anywhere
it's slightly more general than just "between restarts".
Has anyone actually confirmed this works after restart? Regardless, I'm not convinced it's a security issue, when you logout from a vt the screen isnt explicitly cleared, you can still use shift-pgup, etc. You also still require physical access, so this is the least of your worries. I'm tempted to mark this INVALID/WONTFIX and suggest you report it to the freedesktop.org folks who might be interested in changing this behaviour.
Okay, after discussing it with security team, if someone can confirm this works after an X server restart (ie, user A logs out, then user B logs in and can obtain uninitialized memory that can be used to discern what user A was doing), I'll move it into Vulnerabilities.
for what it's worth, that code just creates a black window here. Can someone who can reproduce this please check if it works after logout.
ping
closing as WORKSFORME, reporter you may want to report this to freedesktop.org if you still have concerns.
