keylogger to interferret SUDO

[mike acker]

thinking again ( oh no )

could a keylogger grab the administrator password when SUDO is used ...

this supposes the malware is carried in an HTML document -- active in an app e.g. Firefox, Chrome, Thunderbird, LibreOffice ...

to my thinking the answer is no: any app such as those mentioned here should be running in a separate storage key and hence will not be able to "see" the memory used when you open TERMINAL to run SUDO

we would hope SUDO deletes the administrator password from memory -- as soon as authentication has been requested... otherwise as memory is reallocated...

[daslinkard]

thinking again ( oh no )

could a keylogger grab the administrator password when SUDO is used ...

this supposes the malware is carried in an HTML document -- active in an app e.g. Firefox, Chrome, Thunderbird, LibreOffice ...

to my thinking the answer is no: any app such as those mentioned here should be running in a separate storage key and hence will not be able to "see" the memory used when you open TERMINAL to run SUDO

we would hope SUDO deletes the administrator password from memory -- as soon as authentication has been requested... otherwise as memory is reallocated...

Interesting questions that you pose here....I did a little surfing around the Net and saw where one Ubuntu Poster felt that someone who obtained a keylogger on their Windows machine would be prone to eventually get a keylogger on their Linux machine. I'm not for certain how much I agree with that statement being everything is seen as a file in Linux.

With that said there is logkeys in the Software Center which is available for download so you could put the keylogger on your Ubuntu machine.

[MG&TL]

thinking again ( oh no )

could a keylogger grab the administrator password when SUDO is used ...

this supposes the malware is carried in an HTML document -- active in an app e.g. Firefox, Chrome, Thunderbird, LibreOffice ...

to my thinking the answer is no: any app such as those mentioned here should be running in a separate storage key and hence will not be able to "see" the memory used when you open TERMINAL to run SUDO

we would hope SUDO deletes the administrator password from memory -- as soon as authentication has been requested... otherwise as memory is reallocated...

Yes, assuming one is used and it is working.

Err...nope. Not unless it managed to install itself. To log keys, or indeed access memory from another process is very difficult.

I don't know exactly how sudo manages its memory (feel free to check out the source code and tell us!), but I would think it would scrub its sensitive segments of memory before releasing them.

[1clue]

A well-written key logger will pull any key press on the system, or possibly even from a networked login depending on whether the remote session uses the keyboard event handler.

Google for 'javascript keylogger' and see what you get. As to whether an html page could catch your password from sudo, it depends on whether you inadvertently type it into the browser.

If the logger is in the event chain for whatever app, yes it can read the keyboard.

You've had the first spark of fear, now it's time for you to do some research and find out for sure...

[Hungry Man]

Yes, easily. Any compromised process can read another processes keystrokes. If they share a UID they can use ptrace or other methods.

SVG filters can be used for keylogging within a website.

[mike acker]

thanks for all the thoughtful replies!!

we talk about an "event chain" in this thread. I take that as meaning: when a program is launched from the launcher then the "event chain" that results will include all of the subroutines, libraries, and processes that are called pursuant to that initial launch ... these would all be operating under the same storage key. Except of course library code which is scheduled to run in "userland" -- so that a rogue program cannot modify the library code -- which will be regarded as "trusted".

when i launch a second event chain -- from the launcher -- e.g. terminal -- then that event chain should be in another storage key (remember I'm an old MVS guy ) -- and nothing in the first event chain will have any means of "seeing" anything that the second chain has in memory ...

now if the one event chain stores something in the user libraries... eg a key log file -- then -- any program running under the current USER ID -- would have access to the files from disk -- but not to steal from the other event chain's memory

~~
I do have a working knowlege of "C" but I'm not sure about trying to read the source code for SUDO,-- yet. I think what I'll do is just run SUDO by itself if I use it -- which isn't often anyway .

[Hungry Man]

If they're within the same UID they can both see and interact with any other processes address space running on the same UID. This is the Windows, Linux, and OSX Security model. You can ptrace any process of the same UID as well as well as a few other things to read system calls and keylog.

Beyond that they can simple use X to keylog across UIDs, which makes the whole thing much simpler. There's no real protection against this without SELinux.

As for libraries they're just code and a rogue program probably could modify them given proper access rights but by default it would only have read and mapping access - can't be sure about that one though. There are ldso userland rootkits.

[albandy]

When you type sudo, you're invoking a setuided file. This means that sudo runs under root user and you don't have acces to root user page memory unles you're root.

Only a keylogger executed under root can read the keyboard when executing sudo.

[Hungry Man]

When you type sudo, you're invoking a setuided file. This means that sudo runs under root user and you don't have acces to root user page memory unles you're root.

Only a keylogger executed under root can read the keyboard when executing sudo.

This is the case for any separate UID. X bypasses this.