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

Shadow passwords FTW

[strredwolf (532)]

This is why you should have shadow passwords, so that your encrypted password isn't stored in /etc/passwd.

Re:Shadow passwords FTW

[Bazman (4849)]

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

Re:your a queer

[JackieBrown (987087)]

Nice try,

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

Re:your a queer

[jlarocco (851450)]

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:your a queer

[utopianfiat (774016)]

Furthermore skype will try to install the firefox extension if you want it to, so reading your firefox profile isn't "unnecessary" as the article title claims...

Re:But...More Secure?

[NickFortune (613926)]

In fact, with all that open source, isn't it easier to see what is going on so I can write a better exploit?

That, sir, is a very good point. In fact it's such a good point, it makes me wonder why no one has ever suggested such a thing before, here on Slashdot.

Fortunately, there is a simple fix, readily suggested by the exemplary record set by The Microsoft Corporation. All we need to do is change the file "/etc/passwd" to be "/etc/.passwd". That way, the file will no longer show up on directory listings. And, since no one on earth is clever enough to think of running "ls -a", that means that no one will know where the password file is, so no one will be able to break in. Security Through Obscurity FTW!

Furthermore, if we apply this policy rigorously throughout the whole of the Linux operating system, I'm sure we can make Linux' security record every bit a good as Windows in no time at all.

Why..

[mikkelm (1000451)]

.. only closed source applications? I don't think most people read the entire sources of open source applications that they use.

Re:Why..

[lilomar (1072448)]

Not everyone has to, just one person.

When I use Open Source apps, I do so knowing that there are many developers and hobbyists that have looked over the code, so I know that there aren't any glaring security flaws.

Imagine this had been an Open Source product for a minute... instead of an article just saying that it read /etc/ files, it would have said this part of the code reads the files, this is why it is nessasary, or here is a patch to stop it from doing this.

Re:Why..

[mikkelm (1000451)]

Well, obviously it also only took one person to discover the same in a closed source application.

Of course it would be easier to see the hows and whys in an open source application, but once you know, you know, and that's really at the core of the matter.

Re:Why..

[optimus2861 (760680)]

Imagine this had been an Open Source product for a minute... instead of an article just saying that it read /etc/ files, it would have said this part of the code reads the files, this is why it is necessary, or here is a patch to stop it from doing this.

Interesting you should say that - did you read the linked thread on the Skype forum? Here's a later post (emphasis added):

i was a bit curious and tried strace on a few internet/network programs. it seems programs like skype, gaim, and perhaps other chat software all look in /etc/ passwd

Pidgin nee Gaim is GPL. A quick search on one of its mailing lists shows no useful hits for /etc/passwd. 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.

Re:Why..

[perlchild (582235)]

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

[jimicus (737525)]

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

[gtwilliams (738565)]

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.

Flawed logic

[Sycraft-fu (314770)]

First you assume that the person(s) that read it would catch anything evil in it. It's not like the evil code is necessairily going to be in a function called doEvil(), it could be very cleverly hidden among legit functions so that most people would miss it. With good obfuscation it wouldn't be hard to make something that people would have to play with a debugger just to figure out what is going on, and as such miss it on anything less than a really intense code audit.

Second, you assume the people who look at it aren't in on it. So maybe a couple people look at the code and find the evil bits. They contact the developer and ask what's up. The developer then lets them in to his cabal, who can use the evil bits for their own ends. The people decide they like this and don't tell anyone. The people who read the code have to be honest for this to work.

Third you assume that anyone other than the developer even bothers to look at the code. Not always a valid assumption, just because the code if you there doesn't mean anyone gives a shit. Maybe it is too complicated, maybe they just don't care, regardless the code being open is no guarantee that someone looked.

Fourth, you assume that the binaries are the same as the source. I'm betting at least some of the time, and probably more often than that, you install things from a binary package. It's easy and much faster than compiling everything. Great, but how do you know the source follows the binaries? It would be easy to release an untainted source, and then tainted binaries. That the checksums differed wouldn't be of any note, since it could just be that different compile options were used, or even a different compiler (for example using ICC since it generates more efficient binary code). As such no source audit would ever turn up the problems.

Finally, even if you compile your own, you assume that nothing else is in on it. I'll refer you to the classic Ken Thompson story http://cm.bell-labs.com/who/ken/trust.html [bell-labs.com]. Some other program, and not just the compiler, could be in on inserting a trojan. It might never exist in source form, yet always get compiled in. Thus even a build from a verified source isn't a defense.

Really, what it comes down to is open source may give you a warm, fuzzy feeling but it isn't actually proof everything is on the level. Really, you have to test what the software actually does when it is run. You can't say "Well the source is open so it can't do anything evil," because you just don't know that. It's far more useful to analyze how the program acts on a system, than to look over the code.

After all, if looking at the code revealed everything, OSS would never have any bugs. You'd look at the code, see all the bugs, they'd all get fixed. Yet it does, nasty ones. My favourite is the BIND flaw discovered back around 2000 that was in essentially every version of BIND ever. Despite the fact that many people had looked at the code, nobody had ever noticed this. There was no ill intent, no conspiracy, it just wasn't something people saw.

As such the same could be done for something evil. Hide it well enough in the code, and nobody will notice it.

Re:Flawed logic

[DaleGlass (1068434)]

First you assume that the person(s) that read it would catch anything evil in it. It's not like the evil code is necessairily going to be in a function called doEvil(), it could be very cleverly hidden among legit functions so that most people would miss it. With good obfuscation it wouldn't be hard to make something that people would have to play with a debugger just to figure out what is going on, and as such miss it on anything less than a really intense code audit.

This sort of "evil" is very transparent. You can code a hidden buffer overflow/exploit/backdoor in such a way that it's not obvious (= instead of == for example, caught in the Linux kernel once). But how do you hide an access to say, /proc/interrupts? You need to spell out the filename, and there's got to be an open or fopen for it somewhere. Any attempt to encode the filename is going to be weird and suspicious. Plus, file parsing would be quite a bit than a single line of code, so it's hard not to notice something is being read, stored, etc.

Second, you assume the people who look at it aren't in on it. So maybe a couple people look at the code and find the evil bits. They contact the developer and ask what's up. The developer then lets them in to his cabal, who can use the evil bits for their own ends. The people decide they like this and don't tell anyone. The people who read the code have to be honest for this to work.

Uh huh. Such a thing would be an outright admission of evildoing. Depending on what is being done it might be enough for a lawsuit, and definitely enough for mass publication all over the web to ruin the developer's name. Slashdot had a story on some Mac developer who claimed there was an anti-piracy check that'd delete the user's documents folder. Just the claim (which the developer says wasn't real and intended to scare people off) resulted in such outrage he's probably unemployable for years now.

No, anybody with any brains would deny any wrongdoing and claim a hacked server, or pretend that no mail is arriving at all.

Fourth, you assume that the binaries are the same as the source. I'm betting at least some of the time, and probably more often than that, you install things from a binary package. It's easy and much faster than compiling everything. Great, but how do you know the source follows the binaries? It would be easy to release an untainted source, and then tainted binaries. That the checksums differed wouldn't be of any note, since it could just be that different compile options were used, or even a different compiler (for example using ICC since it generates more efficient binary code). As such no source audit would ever turn up the problems.

But 99% of Linux software is delivered by the distribution, with the package maintainer often being completely unrelated to the developer. While it's not impossible for something weird to be going on, those distribution maintainers do things like patching the source and dealing with its bugs. You can bet that eg, the Debian maintainer of Firefox looked at the source.

Finally, even if you compile your own, you assume that nothing else is in on it. I'll refer you to the classic Ken Thompson story http://cm.bell-labs.com/who/ken/trust.html [bell-labs.com]. Some other program, and not just the compiler, could be in on inserting a trojan. It might never exist in source form, yet always get compiled in. Thus even a build from a verified source isn't a defense.

That's a tricky one, but you can use a different compiler. Compile gcc with icc for instance. For OSS I think this approach is unlikely due to the frequence with which somebody decides "let's rewrite this part". It's easy to make a compiler that hiddenly changes some well known part of the source, but it's much harder to deal with a complete reorganization of it. To keep it up would need updates

Re:Why..

[19thNervousBreakdown (768619)]

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

[compm375 (847701)]

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?

/etc/password

[Colin Smith (2679)]

Is a public file, as are virtually all the others in /etc.

What's it doing? Well, what libraries is it linked with? Perhaps it's converting your UID into a name among other things.

 

I am not suprised

[figleaf (672550)]

We already knows that Skype records a lot of other information including your BIOS : http://www.pagetable.com/?p=27 [pagetable.com]

What a load of FUD

[arivanov (12034)]

Dunno about AppArmour, but there is no way in hell to distinguish between legitimate getpwnam, getpwuid, etc calls and reading the whole passwd file on a linux system using strace.

Example:

strace on ls -laF immediately gives

open("/etc/passwd", O_RDONLY) = 4

Followed by quite a few reads out of it. So by the logic of the poster ls -laF is a horrible application doing horrible things to your system.

Unless you have read the source or single-stepped trhough the app with a debugger, examined the data and found that it does something nefarious like sending skype the whole of your /etc/passwd you should not claim that it does something illegitimate.

Re:What a load of FUD

[mysidia (191772)]

This article looks like guerilla advertising for SuSE/AppArmor, a Novell product.

It's a fine example of why people who don't understand the C Library and Linux/BSD/POSIX SDK and how to disassemble the application should not be relying much on AppArmor to tell them what's good and evil.

The trouble is the library does it, not the application, and a few reads of some files can't tell you the application's intent, or show whether the information is being encrypted and sent out to the software maker or not.

This reminds me of folks that spend day and night reading firewall logs and mailing out hundreds of complaints to networks if a host so much as pinged them or tried to make a port 25 connection.

Sure, they could be a spammer or hacker, but just because you set alarms -- a connection attempt doesn't say that anything evil is being attempted. I'd be far more concerned if someone said Skype read something from /etc/shadow, then the very next thing it did was to make a port 80 connection to Skype's servers and send a HTTP POST submission with lots of binary jibberish.

Any program that needs to do so much as lookup the user's shell, home directory, username attribute, or real name needs to examine /etc/passwd.

Most non-trivial applications need the user's home directory to load their user preference files. Some internal shell script of Skype may even need the user and group names, in order to establish appropriate file permissions.

Sure, there are environment variables that popular distributions' shells use; however for an application like Skype to be portable, it may not be able to rely on a particular environment variable like 'HOME' being set -- it may be safest just to getpwuid() the user and lookup their home directory that way.

In any case, the SOFTWARE DEVELOPER would have the option of using getpwuid() instead of getenv("HOME"). It's the developers' choice.

Applications can accomplish things in fairly boneheaded ways sometimes, but that doesn't indicate anything malicious or evil.

Re:What a load of FUD

[DavidTC (10147)]

Um, because it wanted to refer to you as using real name, which is the entire damn point of having the field in /etc/passwd? Or even your username?

Without looking in /etc/passwd all it would know is your UID.

Or perhaps it's not even the thing doing it, perhaps it's using a shell script to see if the skype: handler is registered in Skype, and that script does 'ls -l' to check file sizes.

What I'd be interested in figuring out is exactly the fuck confidential information people think is hanging out in /etc/password? We all know that there are actually no passwords in that file, right?

And everyone know that programs access it all the time, right? Which is why it's deliberately world-readable?

Seriously, this entire article was made by someone who knows how to use strace but hasn't bothered running it on other programs, and has no idea what /etc/passwd is for.

I've discovered even worse Linux privacy problems

[by Anonymous Coward]

In the research I did for my doctoral thesis, I found the shocking secret that getty and login and even init both read /etc/password and other files in /etc. My research has not yet found a valid reason for this. I am left feeling that Linux itself is spyware. My proposed solution is to only mount filesystems when a user is not logged in.

The list

[DaleGlass (1068434)]

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.

Please

[joto (134244)]

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