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."

Incorrect

[bakuun]

put the spyware in Kazaa...

It is true that the same people were the main creators of Kazaa and Skype. However, those creators had nothing to do with the introduction of spyware into Kazaa. They are not to blame for what others did. The introduction of the spyware was included in Kazaa first after the program was sold from the creators.

hard to avoid

[m2943]

Many of those files are perfectly legitimate for any application to read.

In any case, you don't need AppArmor to find what files something opens, just use strace.

Re:Why..

[Ajehals]

Not to take away from your message - because you have a point, I think in the context of the summary it would be because you *can* find out what is happening if you realise something strange is going on and if you have the source. If you don't have the source, you may be able to figure out what is going on, and to a certain degree why, but you wont be clear until the company tells you what its doing (and you trust them). In the end it comes down to trust though (as with most things). I only use software that I trust, and ensure it comes from a source I am happy with, (in my case Debian), it doesn't get rid of all the issues but it does reduce the risks ( as I perceive them anyway).

GECOS field

[Anonymous Coward]

/etc/passwd is likely accessed to lookup the full name of the user in the GECOS field [wikipedia.org].

But why Skype wants to access all firefox settings remains a mystery. But it might look for proxy information.

reading /etc/passwd is normal

[harlows_monkeys]

It's quite common for programs to read /etc/passwd. For example, use strace on "ls -l", and you'll see it reading /etc/passwd.

It is via /etc/passwd that you convert a UID to a user name.

Re:Why..

[19thNervousBreakdown]

This is somewhat silly anyway. The Firefox plugins, OK, I don't know why they'd read that, maybe they're checking for a Skype plugin, but who cares? As for /etc/passwd, it's not /etc/shadow. Not only that, but they don't even have to write code that reads /etc/passwd. Try changing the "passwd: compat" line in /etc/nsswitch.conf to "passwd: nis" or something like that, chances are your read of /etc/passwd will go away. It's probably just doing something like getting your real name. Calm down and get some real evidence of wrongdoing like a packet capture of private information going out over the wire before you cry wolf.

Re:/etc/password

[JosefAssad]

That, and this [skype.com]

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?

Re:Shadow passwords FTW

[Bazman]

True, but if your list of usernames leaks out it saves remote attackers having to try non-existent usernames in a dictionary attack...

Corollary: dont use passwords vulnerable to dictionary attacks...

"/etc/passwd" is a misnomor

[iamacat]

It stores your username, home directory, default shell. Most applications read it at least once, to display your username based on current user id. Shadow passwords are usually in effect, so it's only rarely that this file contains encrypted passwords.

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..

[IWannaBeAnAC]

Or most likely, getting the user's home directory so it knows where to find $HOME/.Skype to get the user's configuration settings. Virtually any program will do this, via the getpwnam function, section 3 of the Linux man page.

Re:"/etc/passwd" is a misnomor

[AaronW]

The standard APIs for obtaining this information read /etc/passwd. Passwords are no longer stored there, however, but are in /etc/shadow which is not accessable by users other than root.

Re:Why..

[Anonymous Coward]

A later comment on this thread shows that something as innocuous as an ls command will trigger reads of /etc/passwd. Sounds like this is being overblown.

No idea why gaim does it, but ls has to read /etc/passwd in order to match uids to usernames when you do ls -l. There may be equally viable reasons for skype and gaim to do it, for instance discovering where the user's home directory is to store downloaded files, etc rather than trusting $HOME.

Please

[joto]

Please, before you submit (or accept) an article about security to (or on) slashdot, make sure you understand rudimentary unix programming. There is no way any non-trivial unix program is going to NOT read /etc/passwd. /etc/passwd needs to be read for almost any trivial thing to be accomplished, such as finding out your home-directory so that .skype can be read, or for displaying ownership of files in a file-dialog.

Now, as to why skype needs to read firefox configuration files, I have no idea. I haven't used skype, so I don't know what it does. But most likely this is done, because some users asked for a certain "integration" feature, whether it's bookmarks or plugins, or whatever...

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

[JackieBrown]

Nice try,

Debian uses shadow passwords. It's one of the questions in the installer.

Skype is due to be replaced

[RealBorg]

I stopped using Skype just a short time ago, mainly because of eBay's attitude toward AMD64 support:
http://forum.skype.com/index.php?showtopic=93068 [skype.com]

Since then I have found that there are already standards based open source replacements for Skype, mainly SIP and Ekiga. In contrast to Skype they got video conferencing and you can get a public telephone number for free.

Also I started to think about what would be needed for the german "Bundestrojaner" and compare it to Skype:
- it is installed on a majority of systems
- it is protected against decompilation / debuggers
- it bypasses almost any firewall
- it uses encryption for network traffic
- it may send lots of data even when not making a call
- it might have already been deployed by the NSA
- eBay has a history of cooperating with federal agencies

Tom

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..

[jimicus]

Of course an ls command can trigger a read of /etc/passwd. ls -l shows owners as username rather than numeric UID - where do you think it gets that information from?

This is why a shadow password file was invented in the first place.

Re:your a queer

[Lennie]

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

leen@debian64:~$ cat /etc/debian_version
4.0
leen@debian64:~$ ls -lA /etc/shadow
-rw-r----- 1 root shadow 1171 2007-08-17 01:41 /etc/shadow

Re:You idiots:

[Anonymous Coward]

Install them, yes.

Run them, no.

Retard troll, at least get the terminology right.

AppArmor - Ubuntu?

[postmortem]

AppArmor isn't ubuntu's design to link to Ubuntu package. It is Novell's software, and like should have given them credit.

Instead, we have again Ubuntu users claiming everything and not doing anything but copying (yes I know GNU)

Re:your a queer

[Znork]

"Third: There's nothing wrong with reading /etc/passwd."

Actually, there is, but for the entirely opposite reason. If you read passwd you'll miss any network based users, such as users authorized over LDAP, kerberos, or others.

getpwent and company, on the other hand, will get you those. As would getent or similar command line utility.

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.

Underhanded C contest

[gr8dude]

Here's the same challenge for you as for the other poster: Write some code that accesses some file it shouldn't, and does something with the data in it (writing it to a socket say) in such a way that you can't tell what's it doing without looking really well at it, and it looks harmless or to be doing something else.

Take a look at the Underhanded C contest [brainhz.com].

Re:Shadow passwords FTW

[Phisbut]

So they download /etc/shadow too. Not a problem.

Except that /etc/shadow is only readable by root. A userland application can't access it.