Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can't guarantee that, can you? Say you run it as non-root and it sits there waiting for 'sudo * \n' and captures whatever you type after. Your non-root software could then execute itself with sudo using the password that it's captured.


It's even easier. You can alias sudo and grab the password that way.


Don't you need root to read keystrokes not being sent to you?


Not under X11. See `xev -id $WINDOW_ID` for a demonstration.

There's the XACE (X11 Access Control Extension) that tries to make it harder to snoop, but I don't believe that it's enabled by default in most distributions.


I tried this, I started gedit then xwininfo to get the window id then xev -id and then started typing in gedit. I saw event information but didn't see what characters were being typed so what's the point you're trying to make?


I do see what characters are getting typed when I do the same thing. For example:

    KeyPress event, serial 28, synthetic NO, window 0x2000003,
        root 0x2b7, subw 0x0, time 322414662, (225,283), root:(1057,269),
        state 0x0, keycode 26 (keysym 0x65, e), same_screen YES,
        XLookupString gives 1 bytes: (65) "e"
        XmbLookupString gives 1 bytes: (65) "e"
        XFilterEvent returns: False


I barely see half that information so something's different about how we're doing it. I'm Ubuntu 12.04 btw.


Do you see all the information when you let xev make its own window rather than look at a different window?


I think what he is trying to say is that it could just emulate the terminal and read whatever is coming to it after it's executed. "Listening" for when the user types in sudo...


The easier way would likely be to add a "sudo" script somewhere in $PATH, ideally before /usr/bin – incidentally, this gets much easier on a development machine where people have a ruby path, a perl path, a python path and their own $HOME/bin.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: