104 ms·

Massive Number of Vulnerabilities Found in X.Org

197 points by chrisdotcode 13y ago

EvilLook 13y ago
These seem like such basic errors. Not validating responses because you trust the software you interact with to behave is such a basic mistake that you'd think the people that work on the X server from X.Org would have learned not to do that long ago.
- jerf 13y ago
  It sounds like these errors predate X.Org qua X.Org. A lot of people have had some responsibility for this code at some point without noticing this. Bear in mind X11 is pretty old, and these are some of the oldest libraries in the whole X constellation. That isn't an "excuse", but it's a reason.
  - anonymouz 13y ago
    And when the stuff was originally written, this was probably not considered to be a "security boundary" in the sense that the client will have higher privileges than the server. As the email notes, this happens rather rarely.
    - lawnchair_larry 13y ago
      Actually it was more common back then. Remember, "client" and "server" are backwards in the context of X. A "thin client" actually runs an X Server, and you remotely launch an xterm on the central server as an "x client", exported to your display. However, as the email states, this only gets you the same access your user already had on the remote system, unless it's a setuid program. The canonical example and only one I can think of off the top of my head is xscreensaver or xlock. There are now GUI versions of su/sudo that would also be targets, but I don't think variants of these were used back when this topology was common.
      - mprovost 13y ago
        This is a good read about how jwz coded xscreensaver to be secure and the pitfalls of using GUI toolkits: http://www.jwz.org/xscreensaver/toolkits.html http://www.jwz.org/xscreensaver/toolkits.html
  - mikeash 13y ago
    I'd wager that many of these errors predate many of the commenters on this site. X is pretty old.
    - MostAwesomeDude 13y ago
      I was an X.org hacker a few years ago. X predates me. X is (very) roughly the size of GCC. It's massive and it's nearly entirely C, with a few modern Python scripts to generate some of the more onerous tables. There are many old libraries, and they are horrifying. Eldritch, cyclopean, etc.
      - rjsw 13y ago
        A lot of the libraries listed are relatively new though.
      - jevinskie 13y ago
        An macros to rival, but not beat (they can't be!!!) Perl's!
allenbina 13y ago
Today's HN is sponsored by MIR
DiabloD3 13y ago
Has anyone done a security analysis on Weyland/Weston yet?
lysium 13y ago
Wow, that's huge! I'm wondering how this has not been noticed before. I know, X11 is pretty old, but still, with the increasing awareness for security in the past, it's kind of funny nobody has ever checked such a prominent piece of software, not even in a Master's class. Glad to see they are responding quickly.
- rbanffy 13y ago
  > Wow, that's huge! I'm wondering how this has not been noticed before. Most likely it's not huge. If it were, it would have been noticed before. As to why it's not huge... That's a very interesting question.
  - willvarfar 13y ago
    Because usually you trust the x server. This is saying that most client libraries are exploitable by a malicious x server. A vulnerability in the x server itself, allowing a client to take control of it, would be rather more worrying to most people.
    - rbanffy 13y ago
      Yes, but how likely it is for your X server to get compromised? How often do you connect to your machine using an untrusted X server? This is like saying your car can be stolen by anyone who has its key. Yes, it most likely can. Or that your house is vulnerable to anyone who's inside it.
      - mwill 13y ago
        This is likely why it's not been noticed before, I'd imagine the practical consequences of this are sort of moot: If the X Server is untrustworthy, you've likely got bigger problems. I'll admit, my first thought was X11 Forwarding, as I understand you could have a bogus X server to cause junk to happen on clients on a remote server with X11 Forwarding enabled, which you'd already need credentials for. Again, if this was viable, the attacker having SSH credentials is a bigger problem. I can't see any way for this to be really damaging in the wild, but I'm not a security guy so I could be totally off the mark.
krakensden 13y ago
He did a presentation on it that's much better reading: http://cansecwest.com/slides/2013/Assessing%20the%20Linux%20Desktop%20Security%20-%20Ilja%20van%20Sprundel.ppt http://cansecwest.com/slides/2013/Assessing%20the%20Linux%20...
- contingencies 13y ago
  PDF version? I would post one myself but https://bugs.gentoo.org/show_bug.cgi?id=471112 https://bugs.gentoo.org/show_bug.cgi?id=471112
  - wooptoo 13y ago
    https://docs.google.com/viewer?url=http%3A%2F%2Fcansecwest.com%2Fslides%2F2013%2FAssessing%2520the%2520Linux%2520Desktop%2520Security%2520-%2520Ilja%2520van%2520Sprundel.ppt https://docs.google.com/viewer?url=http%3A%2F%2Fcansecwest.c...
    - contingencies 13y ago
      Cheers. I will use that URL next time. The comments about package managers ring true; I have a bug open on that right now for Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=453620 https://bugs.gentoo.org/show_bug.cgi?id=453620
asveikau 13y ago
The fact that one must watch out for integer overflow on a buffer size calculation for malloc, realloc, etc. should be no surprise to a thoughtful C programmer. It sounds like somebody just did an audit of an old code base looking for bad patterns and this is what came out of it. It sounds like great work on the part of the people doing audits/fixes but I'm not sure it's freakout material ("massive" seems a bit sensationalist).
- tptacek 13y ago
  The only reason this isn't worth a freakout is that nobody running Linux in a graphical desktop configuration could ever have assumed that the machine was multiuser-safe to begin with. The reality is probably that no Linux (or FreeBSD) system in any configuration is secure from an attacker that can run native code in an unprivileged process. But with X11 running, you never had a chance. I'm always amused by the dismissive tone programmers take to findings like this --- "oh, any thoughtful C programmer could avoid these problems". No, they can't. How many billions of dollars does it take to prove this point? The very best secure programmers in the world, building C (and C++) codebases from scratch specifically to address these problems, almost invariably fail to do so: memory corruption bugs get found in these systems just like they do in '90s-vintage X11 code. C is my very favorite language and I'm not saying people shouldn't use it (well... they should avoid it, actually), but people should work in it with their eyes open.
  - javert 13y ago
    > C is my very favorite language and I'm not saying people shouldn't use it (well... they should avoid it, actually), Could you elaborate on this? Particularly "you should avoid it, but I'm not saying you shouldn't use it" (what exactly do you mean?), although I'm also curious why it's your favorite. This is coming from someone who is spending more and more time with C, so genuinely interested.
    - Groxx 13y ago
      I suspect it's something like "don't use it unless you need to".
swdunlop 13y ago
It is easy to dismiss these vulnerabilities from a perspective of a common desktop user. "I already have privileges on this box" or "any desktop user already has a way to escalate privileges." But X11 is also used in process control settings where crappy ancient programs run on decrepit old machines with modern X.org servers used for displays. Would we be so dismissive if someone revealed a host of major vulnerabilities in VNC or RDP clients? (Probably. :))
AaronFriel 13y ago
> The X.Org security team would like to take this opportunity to remind > X client authors that current best practices suggest separating code > that requires privileges from the GUI, to reduce the attack surface of > issues like this. A naïve reading of this statement seems to suggest that no "modern operating system" built on X can be secure should they follow the X.Org team's advice because no privileged clients can exist. Perhaps this is a gross misunderstanding of mine with respect to how distros use X, but is it not possible to display to the user a privileged password input window that can't be tampered with? And, if said window can be made, wouldn't it be privileged and thereby susceptible to this attack unless they displayed it without using an X server? Or would the X.Org security team suggest that operating systems run dual X servers, or many X servers, one for each privilege level, and then render one on top of another? This mess has me quite confused as to the security model surrounding X.
- aidenn0 13y ago
  I think the recommendation is to have a non-privileged X client that invokes a privileged non-X program.
vacri 13y ago
On a parallel note, I remember several years ago seeing Microsoft spruiking its 'Windows 2008 Server Headless'. Running a windows server without the gui was mentioned right there in the MS-generated marketing material as reducing the attack surface, as 70% of all discovered Windows exploits couldn't be done without the GUI components.
- RandallBrown 13y ago
  spruik [ sprook ] promote: to promote goods, services, or a cause by addressing people in a public place I had no idea that was a word. I thought it was a typo until I couldn't figure out what it was supposed to be. Thanks for teaching me something new today!
  - thejosh 13y ago
    You know people who have those speakers and a microphone in stores and stand outside a store and try to sell? They are known as spruikers.
    - marshray 13y ago
      I don't recall ever having seen that in the US.
      - kivikakk 13y ago
        Common enough in AU!
    - kghose 13y ago
      Also known as hawkers, eg. street hawker.
      - singingfish 13y ago
        No, a street hawker is selling you stuff off the street. A spruiker is enticing you to enter a location where stuff is being sold.
tanglesome 13y ago
X.org? Still vulnerable!? I am shocked, shocked, to see these holes still there. There's nothing really new here, what needs to be new is the will for programmers to finally go and fix this stuff.
caf 13y ago
The original title is clearer, because it's germane that the vulnerabilities are in the X client libraries rather than the X.Org server.
dlitz 13y ago
These are actually vulnerabilities in Xlib, which is already well known to be pretty crufty. X11 security has always been a joke anyway, since basically any client can keylog the session at any point. There is some X security policy stuff, but it was never fully developed. The interesting part here is that there's revived interest in fixing Xlib. And for the people talking about Wayland being the future: Let's not forget that client-side window decorations are not exactly going to be a security improvement.
- VMG 13y ago
  > Let's not forget that client-side window decorations are not exactly going to be a security improvement. Why would it have anything to do with security?
  - derleth 13y ago
    The golden rule is that everything has something to do with security.
  - dlitz 13y ago
    If we care about giving applications restricted access to the display and input devices, then we need to prevent those applications from fooling the user. Otherwise, a rogue application can basically do phishing, clickjacking, etc. If we don't care about restricting access, then it doesn't make sense to call these bugs security vulnerabilities at all.
drivebyacct2 13y ago
Shocker. Protocol issues. Time for another extension! Or to just shoot X.org in the head and quell the FUD surrounding Wayland.
- _pmf_ 13y ago
  > Or to just shoot X.org in the head and quell the FUD surrounding Wayland. Yes, we should stop being so critical and automatically embrace everything new as much better than what came before it, due to being developed by agile superstar developers.
  - drivebyacct2 13y ago
    Are you kidding me? Or do you just make assumptions and accusations about technologies you don't know about? "Super star agile developers"? That's the best FUD you can put in my mouth? By the way, you might look up the "superstar" developers behind Wayland: Ctrl+F "The developers": http://en.wikipedia.org/wiki/Wayland_(display_server_protocol) http://en.wikipedia.org/wiki/Wayland_(display_server_protoco... ..... Huh, that's sure interesting. Nowhere did I imply that Wayland was better than X simply because it was newer. That's the exact kind of FUD I'm talking about from the X.org crowd that fears Mir and Wayland because they don't understand: the current technologies, the future technologies, the evolution of Wayland, the DEVELOPERS behind Wayland AND the HUGE list of flaws in X. Stop spreading uninformed FUD, do not put words in my mouth and don't accuse me of being a hipster.
    - pfortuny 13y ago
      This is not helping either of you or any of us. Stay clam, take some time out and reflect.
mtgx 13y ago
Let's bring Mir and Wayland already.
epo 13y ago
The headline is inflammatory and probably misleading, I thought it was regarded as poor form to editorialize by rewriting headlines. Yet again, in threads like this there are lots of "never done anything" armchair quarterbacks pontificating about how to write "massive" (correct use of the word) software libraries without regard to the age of the software in question. X is really old, security concerns were different then. X preceded Linux by a long way and it was the increasing usage of Linux which made X itself achieve widespread adoption. Yes, it is kind of shocking that no one has scoured it for vulnerabilities so far but having looked at the code a long while ago I wouldn't want to have done it, it is awful.
fafner 13y ago
Ilja van Sprundel, the guy who found these vulnerabilities, gave an interesting talk about "unusual bugs" at the CCC conference a couple of years ago. Might be interesting to some of you: Video http://media.ccc.de/browse/congress/2006/23C3-1456-en-unusual_bugs.html http://media.ccc.de/browse/congress/2006/23C3-1456-en-unusua... Slides https://dspace.it.su.se/dspace/bitstream/10102/316/1/Unusual+bugs+23c3.pdf https://dspace.it.su.se/dspace/bitstream/10102/316/1/Unusual...
peterwwillis 13y ago
Lame attempt to find setuid/setgid files which link to an X library: find /bin/ /sbin/ /lib* /usr/ /var/ /root /home -type f \( -perm -4000 -o -perm -2000 \) -exec /bin/sh -c 'ldd {} | grep -q X && echo exists in {}' \; Tools that have to read the shadow file (like xlock and xscreensaver) are sometimes setuid root. Apparently this is not necessary though: http://www.shmoo.com/mail/bugtraq/nov98/msg00087.html http://www.shmoo.com/mail/bugtraq/nov98/msg00087.html (My slack box is set up this way) kppp is setuid root to perform operations only root can do, but supposedly does it in a thread separate from GUI operations. Perhaps Linux Capabilities could be used instead and setuid can finally be thrown out the window?

197 points by chrisdotcode 13y ago

These seem like such basic errors. Not validating responses because you trust the software you interact with to behave is such a basic mistake that you'd think the people that work on the X server from X.Org would have learned not to do that long ago.

jerf 13y ago
It sounds like these errors predate X.Org qua X.Org. A lot of people have had some responsibility for this code at some point without noticing this. Bear in mind X11 is pretty old, and these are some of the oldest libraries in the whole X constellation. That isn't an "excuse", but it's a reason.
- anonymouz 13y ago
  And when the stuff was originally written, this was probably not considered to be a "security boundary" in the sense that the client will have higher privileges than the server. As the email notes, this happens rather rarely.
  - lawnchair_larry 13y ago
    Actually it was more common back then. Remember, "client" and "server" are backwards in the context of X. A "thin client" actually runs an X Server, and you remotely launch an xterm on the central server as an "x client", exported to your display. However, as the email states, this only gets you the same access your user already had on the remote system, unless it's a setuid program. The canonical example and only one I can think of off the top of my head is xscreensaver or xlock. There are now GUI versions of su/sudo that would also be targets, but I don't think variants of these were used back when this topology was common.
    - mprovost 13y ago
      This is a good read about how jwz coded xscreensaver to be secure and the pitfalls of using GUI toolkits: http://www.jwz.org/xscreensaver/toolkits.html http://www.jwz.org/xscreensaver/toolkits.html
- mikeash 13y ago
  I'd wager that many of these errors predate many of the commenters on this site. X is pretty old.
  - MostAwesomeDude 13y ago
    I was an X.org hacker a few years ago. X predates me. X is (very) roughly the size of GCC. It's massive and it's nearly entirely C, with a few modern Python scripts to generate some of the more onerous tables. There are many old libraries, and they are horrifying. Eldritch, cyclopean, etc.
    - rjsw 13y ago
      A lot of the libraries listed are relatively new though.
    - jevinskie 13y ago
      An macros to rival, but not beat (they can't be!!!) Perl's!

allenbina 13y ago

Today's HN is sponsored by MIR

DiabloD3 13y ago

Has anyone done a security analysis on Weyland/Weston yet?

lysium 13y ago

Wow, that's huge! I'm wondering how this has not been noticed before. I know, X11 is pretty old, but still, with the increasing awareness for security in the past, it's kind of funny nobody has ever checked such a prominent piece of software, not even in a Master's class. Glad to see they are responding quickly.

rbanffy 13y ago
> Wow, that's huge! I'm wondering how this has not been noticed before. Most likely it's not huge. If it were, it would have been noticed before. As to why it's not huge... That's a very interesting question.
- willvarfar 13y ago
  Because usually you trust the x server. This is saying that most client libraries are exploitable by a malicious x server. A vulnerability in the x server itself, allowing a client to take control of it, would be rather more worrying to most people.
  - rbanffy 13y ago
    Yes, but how likely it is for your X server to get compromised? How often do you connect to your machine using an untrusted X server? This is like saying your car can be stolen by anyone who has its key. Yes, it most likely can. Or that your house is vulnerable to anyone who's inside it.
    - mwill 13y ago
      This is likely why it's not been noticed before, I'd imagine the practical consequences of this are sort of moot: If the X Server is untrustworthy, you've likely got bigger problems. I'll admit, my first thought was X11 Forwarding, as I understand you could have a bogus X server to cause junk to happen on clients on a remote server with X11 Forwarding enabled, which you'd already need credentials for. Again, if this was viable, the attacker having SSH credentials is a bigger problem. I can't see any way for this to be really damaging in the wild, but I'm not a security guy so I could be totally off the mark.

krakensden 13y ago

He did a presentation on it that's much better reading: http://cansecwest.com/slides/2013/Assessing%20the%20Linux%20Desktop%20Security%20-%20Ilja%20van%20Sprundel.ppt http://cansecwest.com/slides/2013/Assessing%20the%20Linux%20...

contingencies 13y ago
PDF version? I would post one myself but https://bugs.gentoo.org/show_bug.cgi?id=471112 https://bugs.gentoo.org/show_bug.cgi?id=471112
- wooptoo 13y ago
  https://docs.google.com/viewer?url=http%3A%2F%2Fcansecwest.com%2Fslides%2F2013%2FAssessing%2520the%2520Linux%2520Desktop%2520Security%2520-%2520Ilja%2520van%2520Sprundel.ppt https://docs.google.com/viewer?url=http%3A%2F%2Fcansecwest.c...
  - contingencies 13y ago
    Cheers. I will use that URL next time. The comments about package managers ring true; I have a bug open on that right now for Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=453620 https://bugs.gentoo.org/show_bug.cgi?id=453620

asveikau 13y ago

The fact that one must watch out for integer overflow on a buffer size calculation for malloc, realloc, etc. should be no surprise to a thoughtful C programmer. It sounds like somebody just did an audit of an old code base looking for bad patterns and this is what came out of it. It sounds like great work on the part of the people doing audits/fixes but I'm not sure it's freakout material ("massive" seems a bit sensationalist).

tptacek 13y ago
The only reason this isn't worth a freakout is that nobody running Linux in a graphical desktop configuration could ever have assumed that the machine was multiuser-safe to begin with. The reality is probably that no Linux (or FreeBSD) system in any configuration is secure from an attacker that can run native code in an unprivileged process. But with X11 running, you never had a chance. I'm always amused by the dismissive tone programmers take to findings like this --- "oh, any thoughtful C programmer could avoid these problems". No, they can't. How many billions of dollars does it take to prove this point? The very best secure programmers in the world, building C (and C++) codebases from scratch specifically to address these problems, almost invariably fail to do so: memory corruption bugs get found in these systems just like they do in '90s-vintage X11 code. C is my very favorite language and I'm not saying people shouldn't use it (well... they should avoid it, actually), but people should work in it with their eyes open.
- javert 13y ago
  > C is my very favorite language and I'm not saying people shouldn't use it (well... they should avoid it, actually), Could you elaborate on this? Particularly "you should avoid it, but I'm not saying you shouldn't use it" (what exactly do you mean?), although I'm also curious why it's your favorite. This is coming from someone who is spending more and more time with C, so genuinely interested.
  - Groxx 13y ago
    I suspect it's something like "don't use it unless you need to".

swdunlop 13y ago

It is easy to dismiss these vulnerabilities from a perspective of a common desktop user. "I already have privileges on this box" or "any desktop user already has a way to escalate privileges." But X11 is also used in process control settings where crappy ancient programs run on decrepit old machines with modern X.org servers used for displays. Would we be so dismissive if someone revealed a host of major vulnerabilities in VNC or RDP clients? (Probably. :))

AaronFriel 13y ago

> The X.Org security team would like to take this opportunity to remind > X client authors that current best practices suggest separating code > that requires privileges from the GUI, to reduce the attack surface of > issues like this. A naïve reading of this statement seems to suggest that no "modern operating system" built on X can be secure should they follow the X.Org team's advice because no privileged clients can exist. Perhaps this is a gross misunderstanding of mine with respect to how distros use X, but is it not possible to display to the user a privileged password input window that can't be tampered with? And, if said window can be made, wouldn't it be privileged and thereby susceptible to this attack unless they displayed it without using an X server? Or would the X.Org security team suggest that operating systems run dual X servers, or many X servers, one for each privilege level, and then render one on top of another? This mess has me quite confused as to the security model surrounding X.

aidenn0 13y ago
I think the recommendation is to have a non-privileged X client that invokes a privileged non-X program.

vacri 13y ago

On a parallel note, I remember several years ago seeing Microsoft spruiking its 'Windows 2008 Server Headless'. Running a windows server without the gui was mentioned right there in the MS-generated marketing material as reducing the attack surface, as 70% of all discovered Windows exploits couldn't be done without the GUI components.

RandallBrown 13y ago
spruik [ sprook ] promote: to promote goods, services, or a cause by addressing people in a public place I had no idea that was a word. I thought it was a typo until I couldn't figure out what it was supposed to be. Thanks for teaching me something new today!
- thejosh 13y ago
  You know people who have those speakers and a microphone in stores and stand outside a store and try to sell? They are known as spruikers.
  - marshray 13y ago
    I don't recall ever having seen that in the US.
    - kivikakk 13y ago
      Common enough in AU!
  - kghose 13y ago
    Also known as hawkers, eg. street hawker.
    - singingfish 13y ago
      No, a street hawker is selling you stuff off the street. A spruiker is enticing you to enter a location where stuff is being sold.

tanglesome 13y ago

X.org? Still vulnerable!? I am shocked, shocked, to see these holes still there. There's nothing really new here, what needs to be new is the will for programmers to finally go and fix this stuff.

caf 13y ago

The original title is clearer, because it's germane that the vulnerabilities are in the X client libraries rather than the X.Org server.

dlitz 13y ago

These are actually vulnerabilities in Xlib, which is already well known to be pretty crufty. X11 security has always been a joke anyway, since basically any client can keylog the session at any point. There is some X security policy stuff, but it was never fully developed. The interesting part here is that there's revived interest in fixing Xlib. And for the people talking about Wayland being the future: Let's not forget that client-side window decorations are not exactly going to be a security improvement.

VMG 13y ago
> Let's not forget that client-side window decorations are not exactly going to be a security improvement. Why would it have anything to do with security?
- derleth 13y ago
  The golden rule is that everything has something to do with security.
- dlitz 13y ago
  If we care about giving applications restricted access to the display and input devices, then we need to prevent those applications from fooling the user. Otherwise, a rogue application can basically do phishing, clickjacking, etc. If we don't care about restricting access, then it doesn't make sense to call these bugs security vulnerabilities at all.

drivebyacct2 13y ago

Shocker. Protocol issues. Time for another extension! Or to just shoot X.org in the head and quell the FUD surrounding Wayland.

_pmf_ 13y ago
> Or to just shoot X.org in the head and quell the FUD surrounding Wayland. Yes, we should stop being so critical and automatically embrace everything new as much better than what came before it, due to being developed by agile superstar developers.
- drivebyacct2 13y ago
  Are you kidding me? Or do you just make assumptions and accusations about technologies you don't know about? "Super star agile developers"? That's the best FUD you can put in my mouth? By the way, you might look up the "superstar" developers behind Wayland: Ctrl+F "The developers": http://en.wikipedia.org/wiki/Wayland_(display_server_protocol) http://en.wikipedia.org/wiki/Wayland_(display_server_protoco... ..... Huh, that's sure interesting. Nowhere did I imply that Wayland was better than X simply because it was newer. That's the exact kind of FUD I'm talking about from the X.org crowd that fears Mir and Wayland because they don't understand: the current technologies, the future technologies, the evolution of Wayland, the DEVELOPERS behind Wayland AND the HUGE list of flaws in X. Stop spreading uninformed FUD, do not put words in my mouth and don't accuse me of being a hipster.
  - pfortuny 13y ago
    This is not helping either of you or any of us. Stay clam, take some time out and reflect.

mtgx 13y ago

Let's bring Mir and Wayland already.

epo 13y ago

The headline is inflammatory and probably misleading, I thought it was regarded as poor form to editorialize by rewriting headlines. Yet again, in threads like this there are lots of "never done anything" armchair quarterbacks pontificating about how to write "massive" (correct use of the word) software libraries without regard to the age of the software in question. X is really old, security concerns were different then. X preceded Linux by a long way and it was the increasing usage of Linux which made X itself achieve widespread adoption. Yes, it is kind of shocking that no one has scoured it for vulnerabilities so far but having looked at the code a long while ago I wouldn't want to have done it, it is awful.

fafner 13y ago

Ilja van Sprundel, the guy who found these vulnerabilities, gave an interesting talk about "unusual bugs" at the CCC conference a couple of years ago. Might be interesting to some of you: Video http://media.ccc.de/browse/congress/2006/23C3-1456-en-unusual_bugs.html http://media.ccc.de/browse/congress/2006/23C3-1456-en-unusua... Slides https://dspace.it.su.se/dspace/bitstream/10102/316/1/Unusual+bugs+23c3.pdf https://dspace.it.su.se/dspace/bitstream/10102/316/1/Unusual...

peterwwillis 13y ago

Lame attempt to find setuid/setgid files which link to an X library: find /bin/ /sbin/ /lib* /usr/ /var/ /root /home -type f \( -perm -4000 -o -perm -2000 \) -exec /bin/sh -c 'ldd {} | grep -q X && echo exists in {}' \; Tools that have to read the shadow file (like xlock and xscreensaver) are sometimes setuid root. Apparently this is not necessary though: http://www.shmoo.com/mail/bugtraq/nov98/msg00087.html http://www.shmoo.com/mail/bugtraq/nov98/msg00087.html (My slack box is set up this way) kppp is setuid root to perform operations only root can do, but supposedly does it in a thread separate from GUI operations. Perhaps Linux Capabilities could be used instead and setuid can finally be thrown out the window?