Slashdot Mirror
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."
This is why you should have shadow passwords, so that your encrypted password isn't stored in /etc/passwd.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
.. only closed source applications? I don't think most people read the entire sources of open source applications that they use.
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.
Deleted
We already knows that Skype records a lot of other information including your BIOS : http://www.pagetable.com/?p=27
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.
/etc/passwd you should not claim that it does something illegitimate.
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
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
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.
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.
Second: Any modern Linux system will use a shadow password file, its been years since I've seen a system use a regular password file.
It is via /etc/passwd that you convert a UID to a user name.
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.
They want their critical Unix vulnerability back.
Darn - all I have to do is cat /etc/passwd from a regular account... let's see... gee, the sysadmin on this machine is a dumbass - what sort of root password is "x"?
OMG its on Mac OS as well - the root password here is '*' - well, at least they've used a non-alphabetic character.
What's that you say Mr Sock... /etc/passwd is a public file and no security-conscious distro has actually stored passwords in there since the encryption was cracked (at least for dictionary words) sometime in the 80s?
Wake me up if Skype actually emails a readable copy of /etc/passwd to the black hats - even then, it shouldn't be enough to compromise a system (although a list of usernames might be handy).
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
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.
I seem to be able to confirm this. When I run skype, it does not read /etc/password, I expect because my user information is distributed using LDAP. Therefore, it instead connects to nscd.
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. 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.
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...
Nice try,
Debian uses shadow passwords. It's one of the questions in the installer.
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
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
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.
Maybe not
> not every distro of linux uses shadow passwords (think debian or netbsd)
/etc/debian_version /etc/shadow /etc/shadow
leen@debian64:~$ cat
4.0
leen@debian64:~$ ls -lA
-rw-r----- 1 root shadow 1171 2007-08-17 01:41
New things are always on the horizon
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.
Don't let THEM immanentize the Eschaton!
"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.
He mentioned the libc calls already. Those calls will use whatever method is appropriate for obtaining user information. On a default installation, this will be reading /etc/passwd.
This is like a blast of deja vu...in the early 1990's the ISP Prodigy was accused of stealing information from their users, based on bits of personal information that some users found in their cache files (due to the client using uninitialized disk space, reclaimed from previously deleted files by the OS). Much paranoia and very little enlightenment followed in online discussions. See e.g. http://en.wikipedia.org/wiki/Prodigy_(ISP)#Spyware -like_behavior
Have you read my blog lately?
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...
+5, Truth
But, linux is more secure. These things are protected. No one is writing exploits for linux.
Oh, wait, it isn't, they aren't, and they are.
Wait, who said no one is writing exploits for Linux? People write exploits for everything. No software is 100% secure, and anyone who claims the opposite is a fool.
In fact, with all that open source, isn't it easier to see what is going on so I can write a better exploit?
Open code allows anyone to do security audits to patch vulnerabilities before they can be exploited. Patches also tend to propagate faster because of their public nature, and the fact that anyone with sufficient knowledge about the issue can write and apply those patches himself. On the other hand, when a vulnerability is found in closed software, you have no choice but to patiently wait for the vendor to fix it, which may take some time depending on various factors such as PR and the perceived priority of the vulnerability to the vendor's eyes.
Isn't it easier for me to, say, sneak a corporate or national spy into the development team and compromise the project?
You seem to imply that it would be harder to do the same in a non-open project. At least in an open project the code can be audited by anyone. When you get proprietary software you can't inspect it yourself unless you're a member of the project. And if said project is compromised, you can't do anything.
With millions of lines of code, do you think we could keep an Iranian or Chinese spy from getting malicious code into the project?
Chinese spy? I'm not even going to bother replying to this one.
Hypothetical:
- Start a project for a civilian equivelent of a military application
- Form a project team
- Accept a programmer from a country that has very specific ideology driven agendas against much of the western world
- Wonder why the government won't switch to the OS of your desire
Again, the same thing could happen for a closed project, and with greater repercussions, so your argument is meaningless.
Now, the REAL reasons why some governments don't switch to open source:
- Lack of understanding of the movement
- Switching technologies is expensive, especially when the vendors of the current one has made sure it would be difficult to switch by disregarding standards
- Misinformation from corporate interests that see open source as a threat to their current business model instead of embracing it, or people like you
But, wait, linux is more secure. These things are protected. Nobody is writing exploits.
Made-up bullshit again.
And to add to that: if /etc/passwd was supposed to be soooo guarded, it wouldn't be 644.
Readable to all.
The saddest poem
The proper way to get information about the user, such as his name, his home directory, etc is to call the function getpwuid() in a manner like: getpwuid(getuid()), it returns the following struct:
Sure it has the user's password listed there (in some format), but this is the proper way to retrieve all the other data also found here. All good applications which save settings per user or try to be more friendly towards the user will call getpwuid() and in turn end up reading
If you think a program reading
As for reading Firefox files, I'm not sure what it's doing, but Skype does offer Firefox integration right? Surely it's not too hard to imagine it's trying to figure out your configuration and check for conflicting plugins, and the like.
You can be an insane coder too, read: Insane Coding
There's nothing wrong with reading /etc/passwd.
Is there? Is there not? How should I know?
In an open source project, one could take the source and if it's FUD, debunk it immediately. Maybe there is a legit reason to read the passwd, maybe there is not. Do I know? No. Can I find out? No. It's closed source. I just know that it does. But what does it do with my passwords? Nobody knows but Skype's makers.
That's the core problem with closed source. I cannot trust it. Maybe it has a good reason to access the passwd file. But do you expect the best or worst? As a security expert, I expect the worst by default until proven wrong. Everything else is playing russian roulette with your system security. You can't just trust a program intrinsically until proven wrong, because when you're proven wrong, it usually is too late.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
No, no, no! That wont do at all. Then everybody could make changes to all the files. It should be "chmod -R 774 /", and then you add every user to the admin group, except for the guest user.