Skype Linux Reads Password and Firefox Profile

mrcgran writes "Users of Skype for Linux have just found out that it reads the files /etc/passwd, firefox profile, plugins, addons, etc, and many other unnecessary files in /etc. This fact was originally discovered by using AppArmor, but others have confirmed this fact using strace on versions 1.4.0.94 and 1.4.0.99. What is going on? This probably shows how important it is to use AppArmor in any closed-source application in Linux to restrict any undue access to your files."

Comments

Re:Why..

[compm375]

Well, I just searched the source of Pidgin (because it is open source) and found it does indeed access /etc/passwd through getpwuid(getuid()) for use in Bonjour, Silc, and Zephyr protocols. There is no direct access to /etc/passwd and no use of getpwuid without using the current users uid through getuid. Skype may be doing the same thing, but there is really no way to know, is there?

The list

[DaleGlass]

Here's the list, reordered somewhat to group related things together.

/dev/snd/controlC0 rw, /dev/snd/pcmC0D0c rw, /dev/snd/pcmC0D0p rw, /dev/snd/pcmC0D1c rw, /dev/snd/timer r, /usr/share/alsa/** r,

ALSA sound devices. Perfectly normal given that skype uses sounds

/home/*/.Skype rw, /home/*/.Skype/** rw, /usr/bin/skype mr, /usr/share/skype/** r,

Skype's own files, ok

/home/*/.config/Trolltech.conf r, /home/*/.fontconfig/* r, /home/*/.fonts/* r, /usr/share/fonts/** r, /usr/share/icons/** r, /usr/share/locale-langpack/**r, /usr/share/X11/XKeysymDB r, /var/cache/fontconfig/* r, /var/lib/defoma/fontconfig.d/fonts.conf r, /etc/fonts/** r,

Seems harmless. Font stuff, icons, locales.

/home/*/.Xauthority r, /home/*/.ICEauthority r,

Needed to talk to the X server. X authorization info. Seems ok.

/home/*/.kde/share/config/kioslaverc r,

KDE integration? Probably not sensitive

/home/*/.mozilla r, /home/*/.mozilla/plugins r, /home/*/.mozilla/firefox r,

No clue what it's looking for there.

/tmp/** rw,

Temp directory, harmless

/etc/resolv.conf r, /etc/hosts r, /etc/nsswitch.conf r, /etc/gai.conf r,

DNS stuff, it needs to connect to servers after all

/etc/passwd r, /etc/group r,

Maybe harmless. No passwords here, only lists of usernames and home directories. And RL names, if specified. As other people suggested, may be just being used to find something like the home directory. Might be used to gather stats on number of users on the system, names, etc. Probably not a huge deal unless RL names are specified, but still interesting.

/proc/1/cmdline r,

Command line for init. On my system contains only the runlevel. Not sure what's interesting to look at here, but it is quite unusual.

/proc/interrupts r,

Interrupt statistics. This would allow determining the number of CPUs, hardware present (from listed module names), activity levels of various devices. Potential for gathering hardware statistics. Not sure what would a legitimate use for this be.

Re:Why..

[perlchild]

Seems like people don't understand unix at all, when they post to security lists...
Just checking your own identity in unix requires a call to getpwnam, getpwent or their equivalent, which means that a function call in glibc has to read the password file. Practically every unix program does that... It reads in the whole file in memory and looks for you, unless you're using the db source, yp, nis+ or an external module: nss_ldap, nss_mysql, nss_pgsql. It's doing that to find YOU out... That's normal, system-wide behaviour, and not sinister at all(that's also why there's a nscd daemon to cache those results, to prevent your machine from grinding to a halt if you have 200k+ entries in that file.

Now unless the legacy api gets redesigned to NOT do a line by line scan, anyone using strace/ltrace/dtrace/tusc needs to filter out these internal "housekeeping" calls, which are perfectly normal, needing to find out if _you_ can open up your own log file...

The /etc/passwd /etc/group files are public files precisely because they are referred to in this manner. That's why shadow passwords are so necessary.

Re:your a queer

[jlarocco]

not every distro of linux uses shadow passwords (think debian or netbsd)

First: NetBSD isn't a Linux distro.

Second: Debian uses shadow passwords.

Third: There's nothing wrong with reading /etc/passwd. POSIX even has an API for accessing it in user code. See the man pages for getpwuid, getpwnam, getpwent, setpwent and endpwent. For example, everytime you do "ls -l", it uses information from /etc/passwd.

In any case, there's really no excuse for not using shadow passwords.

Re:Why..

[gtwilliams]

The most common reason these applications and others read /etc/passwd is that they call getpwuid() to obtain a struct that contains the user's home directory. Now the application knows where to find its configuration files.