Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Skype Linux Reads Password and Firefox Profile

samzenpus posted more than 7 years ago | from the to-send-better-ads dept.

Privacy 335

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

Sorry! There are no comments related to the filter you selected.

Shadow passwords FTW (5, Insightful)

strredwolf (532) | more than 7 years ago | (#20362385)

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

Re:Shadow passwords FTW (4, Informative)

Bazman (4849) | more than 7 years ago | (#20362675)

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

your a queer (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#20362911)

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

Re:your a queer (4, Informative)

JackieBrown (987087) | more than 7 years ago | (#20363229)

Nice try,

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

Re:your a queer (5, Informative)

jlarocco (851450) | more than 7 years ago | (#20363271)

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.

Why.. (5, Insightful)

mikkelm (1000451) | more than 7 years ago | (#20362389)

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

Re:Why.. (-1, Troll)

Anonymous Coward | more than 7 years ago | (#20362415)

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

Microsoft troll. You know as well as I do that Open Source would never do anything like this. Hows the weather in Redmond? Crawl back under your rock.

Re:Why.. (-1, Troll)

Anonymous Coward | more than 7 years ago | (#20362615)

Yes, call anyone who tells the truth a 'troll'. Typical zealot behavior.

Re:Why.. (5, Insightful)

lilomar (1072448) | more than 7 years ago | (#20362435)

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.. (4, Interesting)

mikkelm (1000451) | more than 7 years ago | (#20362569)

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.. (4, Interesting)

optimus2861 (760680) | more than 7 years ago | (#20362581)

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.. (1, Informative)

Anonymous Coward | more than 7 years ago | (#20362959)

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.

Re:Why.. (5, Informative)

perlchild (582235) | more than 7 years ago | (#20363205)

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.

Flawed logic (5, Interesting)

Sycraft-fu (314770) | more than 7 years ago | (#20362695)

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 (5, Insightful)

DaleGlass (1068434) | more than 7 years ago | (#20362943)

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 to the evil compiler.

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.

Obviously it's not perfect, but it can't be denied it's better.

If Skype was open source we wouldn't be having this discussion at all. Either the author of the post would have looked at the source and came to the conclusion that it's all legitimate and not made a post at all, or we'd have something to look at, and be able to quickly decide whether there's anything to worry about or not.

Re:Why.. (1)

gomiam (587421) | more than 7 years ago | (#20362439)

Unfortunately, you seem to be wrong, if we are to trust what this user [skype.com] says on the thread: he cites Gaim acting the same way (among "other programs"). Then again, he's not too explicit.

Re:Why.. (5, Informative)

compm375 (847701) | more than 7 years ago | (#20362607)

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:Why.. (1)

jguthrie (57467) | more than 7 years ago | (#20363011)

Of course there's a way to know. Not to the point of certainty, but to a fairly high confidence level. At least, there's a way to know if it's calling getpwnam. It's a dynamically-linked executable and getpwnam is in one of those libraries so the name "getpwnam" is going to appear, in plain text, in the executable itself. A simple check with "strings" show getpwuid_r, getuid, getcwd, getpwnam_r, getgrid_r and others are in the executable. To be sure, you'd have to check the executable using tools that know about the parts of an ELF file (you know, like those that are in the Debian elfutils package) and see where those names show up.

Re:Why.. (0)

Anonymous Coward | more than 7 years ago | (#20363097)

...but there is really no way to know, is there?
An strace should show getpwuid() as opposed to open(), no?

"/etc/passwd" is a misnomor (2, Informative)

iamacat (583406) | more than 7 years ago | (#20362679)

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.

Re:"/etc/passwd" is a misnomor (1)

CastrTroy (595695) | more than 7 years ago | (#20362799)

Is this the standard way of accesssing such information in Linux? I'm not a linux programmer, so I really haven't looked into it. Isn't there (shouldn't there be) better ways of accessing information such as username, home directory, shell, etc. without reading the file which also contains the passwords? Isn't this located in some environment variable? From reading the other posts, it seems like many applications "read /etc/passwd" mostly indirectly, by doing some system calls to get this kind of information. However, I think that this information should be available without reading the password file, as it may not be a good idea to give all users (especially on large multi-user systems) access to this file. It just seems like an unnecessary risk.

Re:"/etc/passwd" is a misnomor (2, Informative)

AaronW (33736) | more than 7 years ago | (#20362885)

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:"/etc/passwd" is a misnomor (1)

CastrTroy (595695) | more than 7 years ago | (#20362973)

Thanks for clearing that up. I wasn't exactly sure of how the whole thing worked. It seems that this is just another sensationalist article written by someone who doesn't know what they are talking about. And the editors let it slip through, and be published. Never mind that they wouldn't publish real news like the fact that the Wii has recently beat the XBox 360 in sales [vgchartz.com] . But such is life on Slashdot.

Re:"/etc/passwd" is a misnomor (1)

mikael (484) | more than 7 years ago | (#20362933)

'struct passwd * getpwuid(uid_t uid )' and 'struct passwd *getpwnam(const char *pname)' are the standard function calls for retrieving a users password details, default shell, home directory etc...

They work by reading the password file sequentially and then returning the corresponding data structure.

You could try obscufating this information under some kernel or system method (eg. windows registry) but that would just make it easier for someone to hide a root kit.

Re:"/etc/passwd" is a misnomor (1)

cduffy (652) | more than 7 years ago | (#20362981)

There is a better way (the getpwent() call through the standard C library -- which will use LDAP or whatnot instead of /etc/password as appropriate); further, /etc/passwd doesn't actually contain passwords on any halfway modern system.

Well... (1)

Attaturk (695988) | more than 7 years ago | (#20362443)

[Why...] only closed source applications? I don't think most people read the entire sources of open source applications that they use.
And not everyone will use a tool to check what their closed source application is actually doing either. When using popular open source software there's a good chance that someone has already scanned the entire source and therefore a good chance that mischief would have been uncovered.

With closed source the chance that someone will uncover mischief, which they can only do by analysing the application's actual operation, is therefore much slimmer.

In summary, it's not that you can always trust open source above and beyond the equivalent closed source - it's just that it's generally much easier to do so. :)

Re:Why.. (2, Informative)

Ajehals (947354) | more than 7 years ago | (#20362467)

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

Re:Why.. (2, Insightful)

DaleGlass (1068434) | more than 7 years ago | (#20362519)

Because for something as well known as Skype, somebody would be bound to read it at some point if it was open.

For example, I work on the Second Life source, and I and other people read quite big chunks of it. You can bet that the moment somebody noticed something fishy there'd be blog entries about it all over the web, and dozens of people looking at that and other parts of the source. And it'd have happened much earlier than if it was found by chance by some admin stracing or checking the logs.

In fact pretty much the first thing that people did when the source was opened was starting to think of interesting things to grep the source for.

Now that people like me have forks of the Second Life source, there are people who check the diffs for every new LL release when they merge the changes with their own. You can bet it would be pretty hard to sneak something into it in this situation.

Now how do you do that for a closed source program? You can't. You either need to be an uber-hacker who disassembles and decompiles things for fun, a paranoid sysadmin (unlikely too, who runs skype on a server?), or happen to notice something weird by chance and have the skill and knowledge to be able to figure out what a closed program is up to.

Re:Why.. (4, Informative)

19thNervousBreakdown (768619) | more than 7 years ago | (#20362563)

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.. (2, Informative)

IWannaBeAnAC (653701) | more than 7 years ago | (#20362753)

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:Why.. (1)

jgrahn (181062) | more than 7 years ago | (#20363085)

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.

It's probably better to simply getenv("HOME") to find $HOME. It's already in your process; why bother asking a file (or possibly a remote database)?

But yes, there are other mundane and valid reasons for reading /etc/passwd.

Re:Why.. (1)

ciroknight (601098) | more than 7 years ago | (#20362771)

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

Because it's not at all possible if they're being sneaky enough to read files they really shouldn't be reading in the first place, they wouldn't ever dare encrypt it before they sent it back to a central server. Oh no, that'd be faaar too clever.

Possible rational reasons for stupidity and violation of trust don't cut it when it comes to privacy. "Oh, the government's reading your mail? Well, that's probably because they think you're a terrorist. Don't worry, they'd never do anything evil with what they read."

Re:Why.. (1)

19thNervousBreakdown (768619) | more than 7 years ago | (#20362837)

This is more like, "Oh, the government can get look op your name from your social security number. Don't worry, that's one of the reasons the social security number exists. Well, no, I can't say that the government hasn't used that information to also find my address and dispatch a highly trained team of assassins to brutally slay me, my family, everyone with a drop of my blood in their veins, and everyone I've ever loved or has loved me."

Re:Why.. (0)

Anonymous Coward | more than 7 years ago | (#20363063)

Because it's not at all possible if they're being sneaky enough to read files they really shouldn't be reading in the first place

What files are those?

Re:Why.. (0)

Anonymous Coward | more than 7 years ago | (#20362807)

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

Convenient that those are encrypted...?

Re:Why.. (1)

19thNervousBreakdown (768619) | more than 7 years ago | (#20362875)

So decrypt it. What? You don't have the keys? Well, that's what you get for using closed source. I don't use Skype, but if I did I wouldn't worry about it. If you're that paranoid, maybe you should stick with GPL-3 software.

Re:Why.. small reality check! (1)

pjr.cc (760528) | more than 7 years ago | (#20362907)

There are in reality many very reasonable reasons why a program might read your passwd file. There are in fact innumerable standard unix function calls that do just that (this has already been pointed out). Now, if I could be bothered looking at the strace its very easy to tell if its doing this via a libc/glibc function call or whether its implementing such a call internally. Even if its internal it could be because they've statically linked in a library that does getpw* calls - who knows.

However, the point I WANTED to make was that just because /etc/passwd is world-readable doesn't mean you should share with the world! Just having usernames provides a hacker with tonnes of information about your systems for an attack point. "Oh look the user blah appears, that means he installed package x - i bet its the one with the security flaws". Or any number of other things that can be gleaned from /etc/passwd. I hope all your users set passwords that are non-predictable for example.

Re:Why.. (1)

cduffy (652) | more than 7 years ago | (#20362877)

Most people don't need to. One person needs to. That's a much lower bar.

Additionally (and perhaps more importantly) -- in the case of OSS, the individual programmer is putting their public reputation on the line. In the case of proprietary software, the credit and blame generally goes to a faceless corporation.

Re:Why.. (1)

WilliamSChips (793741) | more than 7 years ago | (#20363267)

Because if an open-source app did it then there would be a big media storm followed by a fork if the change isn't rescinded.

This is a lie (0)

Anonymous Coward | more than 7 years ago | (#20362399)

It's impossible to compromise teh Lunix's security. This is a known fact. Thus... the story must be false.

And you are a troll (1)

someone1234 (830754) | more than 7 years ago | (#20362731)

It is hard to compromise Linux security, but only if the user knows what he does.
You cannot deny the user to give away his own password in any system.

it was the authors of Skype that... (0, Troll)

FudRucker (866063) | more than 7 years ago | (#20362403)

put the spyware in Kazaa...

Incorrect (4, Informative)

bakuun (976228) | more than 7 years ago | (#20362461)

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.

Re:it was the authors of Skype that... (0)

Anonymous Coward | more than 7 years ago | (#20362623)

the pope was also a member of hitler's youth!

/etc/password (5, Insightful)

Colin Smith (2679) | more than 7 years ago | (#20362405)

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.

 

Re:/etc/password (2, Insightful)

Anonymous Coward | more than 7 years ago | (#20362503)

No kidding. If you go over the list of files it reads, it seems pretty clear it's just a normal running GUI program, nothing evil.

The only thing that stands out is when it checks the Mozilla profile, but I'll bet that it's doing that to make sure that the "skype:" URL handler is enabled and adding it if it isn't.

In other words, this is a complete non-story.

Re:/etc/password (0)

Anonymous Coward | more than 7 years ago | (#20363129)

getenv( "USER" );

Why would you need to read /etc/passwd again?

I'm not saying there's no valid reason, just that getting a username is not a valid reason.

Re:/etc/password (4, Informative)

JosefAssad (1138611) | more than 7 years ago | (#20362593)

That, and this [skype.com]

I, for one, (0)

Anonymous Coward | more than 7 years ago | (#20362419)

Welcome our new password-reading spyware overlords

I am not suprised (4, Interesting)

figleaf (672550) | more than 7 years ago | (#20362423)

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

Which versions? (0)

Anonymous Coward | more than 7 years ago | (#20362429)

Which versions of Skype, 1.4 or all of them?

I think it is time to use SIP and force the 2 people I talk to to use SIP as well.

Uh oh (1)

doyoulikeworms (1094003) | more than 7 years ago | (#20362445)

Russian hackers are getting your passwords!

Nyet. Estonian. (1)

mrmcwn (566272) | more than 7 years ago | (#20362853)

Incorrect. Estonian hackers are stealing your passwords.

Linked in libraries? (1)

wangmaster (760932) | more than 7 years ago | (#20362447)

It'd be interesting to see what libraries skype links in. If it has anything built against mozilla libraries, or perhaps something else that might legitimately need to check user IDs for access information (say to /dev/whatever) or something like that.

What a load of FUD (5, Insightful)

arivanov (12034) | more than 7 years ago | (#20362459)

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 (3, Interesting)

11223 (201561) | more than 7 years ago | (#20362507)

Oh my God! ls -laF is looking at my .mozilla directory! In fact, it's looking at every file in my home directory! GNU binutils is teh spywarez! ... what do you mean, it's supposed to do that?

Re:What a load of FUD (2, Insightful)

DaleGlass (1068434) | more than 7 years ago | (#20362545)

Heh, but ls has a perfectly legitimate reason for it: Looking up account names. You can see that plain 'ls' doesn't open it, because the short format doesn't show usernames (now if it did in this case that'd be interesting as well). And if you still think it's suspicious you can get the source and look at it.

Now what exactly does skype need to know my or anybody else's account name for? I've got no clue, but I'd be very interested to find out.

Re:What a load of FUD (5, Insightful)

DavidTC (10147) | more than 7 years ago | (#20362689)

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.

Re:What a load of FUD (1, Troll)

DaleGlass (1068434) | more than 7 years ago | (#20362781)

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?

Why would it need to? Skype has its own accounts, if it wants to refer to me by name it can use whatever I entered in my account info.

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.

That'd be a stupid way of doing it, and I think AppArmor would have logged bash in that case. Or at least I hope it can tell the difference between what a program is doing, and what a program launched by another is doing.

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?

More than confidential, it's interesting why it's looking there. Especially the much stranger mozilla directories and /proc/interrupts. Add those things together and it's not hard to imagine that skype might gathering something from /etc/passwd like everybody's real names and reporting them. Now I have no clue if it actually does that, but given that Skype is already well known for doing strange things, some paranoia seems justified.

Re:What a load of FUD (1)

FooBarWidget (556006) | more than 7 years ago | (#20363021)

"Why would it need to? Skype has its own accounts, if it wants to refer to me by name it can use whatever I entered in my account info."

So that it can fill in sensible defaults in the 'register account' dialog. Having sensible defaults is good usability.

Re:What a load of FUD (1)

DaleGlass (1068434) | more than 7 years ago | (#20363157)

So that it can fill in sensible defaults in the 'register account' dialog. Having sensible defaults is good usability.


But it doesn't do that. I just made a new user account, ran skype, and starting creating a new skype account. Skype leaves the full name field blank.

Re:What a load of FUD (1)

arivanov (12034) | more than 7 years ago | (#20362793)

It has no other legtimate means of getting your GECOS. As a result, I would expect it to do a /etc/passwd read via the getpw family of calls during initial registration. Doing it later on is not strictly necessary, but not very "nefarious" either.

Re:What a load of FUD (3, Funny)

mpeg4codec (581587) | more than 7 years ago | (#20362701)

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

Try ltrace, which is similar to strace but lists library calls [man section 3] instead of system calls [section 2]. Running your same example with ltrace, one will see:
getpwuid(1000, 0xbfaa1073, 0xbfaa0d08, 1000, 0x805c088) = 0xb7f8c9b8
where 1000 is my uid and the rest of the params are pointers to memory locations.

So yes, it's possible to distinguish, just not using strace. Proper tool for the job and all that.

Of course all this would be moot if we had access to the source, which is the underlying issue being debated here.

Re:What a load of FUD (1)

DaleGlass (1068434) | more than 7 years ago | (#20363301)

Well, I just tried to ltrace it, it's interesting.

Lots of output, but no getpw or open in it, and before starting skype says "Binary file corrupted. Please reinstall skype". So can't get very far with ltrace.

Either ltrace screws something up, or skype intentionally makes it not work.

Re:What a load of FUD (1)

ojs (93878) | more than 7 years ago | (#20363257)

Oh oh ... you have a compromised computer!

Well, anyways, I dont see this in my strace of ls -laF :-)

hard to avoid (2, Informative)

m2943 (1140797) | more than 7 years ago | (#20362465)

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.

GECOS field (1, Informative)

Anonymous Coward | more than 7 years ago | (#20362475)

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

Re:GECOS field (0)

Anonymous Coward | more than 7 years ago | (#20362659)

Which is stupid. Proxy information is stored in /etc/sysconfig/proxy and/or the $http_proxy environment variable.

shadows (1)

SolusSD (680489) | more than 7 years ago | (#20362479)

virtually *any* linux distribution uses shadowed passwords s oour encryted password is kept in a separate file. Anyone "rolling their own" should have the forsight to do the same.

Why /etc/passwd access is benign (2, Insightful)

vfaded (1147805) | more than 7 years ago | (#20362485)

First: The reason why most applications want to access the /etc/passwd file is to get your home directory. man getpwent for how this works.

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.

Re:Why /etc/passwd access is benign (1)

MichaelJ (140077) | more than 7 years ago | (#20362595)

And let's be clear on this... The application itself, per se, is not what's reading /etc/passwd ... it's libc, when the application calls getpwent() or getpwuid(). And it depends on /etc/nsswitch.conf's settings, which it reads first. Pure FUD. And if the idiot blocks application access to those files, things are NOT going to work correctly. Oh, and as for reading the Mozilla profile ... could it be looking for the Skype Toolbar?

Er, maybe it's getpwent or getpwnam? (1)

11223 (201561) | more than 7 years ago | (#20362487)

I can't speak to the Firefox profile access, but if an application wants to look at the GECOS field to find your real user name, the only way to do that on a non-NIS (or other network authentication scheme) system is to look at /etc/passwd. This is also why shadow passwords should always be used, because /etc/passwd can't be locked down.

Paranoia without understanding how UNIX works is inappropriate.

Re:Er, maybe it's getpwent or getpwnam? (2, Interesting)

jguthrie (57467) | more than 7 years ago | (#20362683)

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.

Halfway legitimate (0)

Anonymous Coward | more than 7 years ago | (#20362547)

And of course it phones home too. Voilà. Result: Either you are ok with that and you are one of these people that say "I have nothing to hide" (there's been a /. article about that too, more or less often), or you are not ok with it and should stop using it immediately.

But technically, anything that uses getpwuid(getuid()) uses /etc/passwd. This is how programs finds out your GECOS (real name) and or home directory, though I'd say that the latter should be done using getenv("HOME"), so as to change it temporarily (export HOME=~/somewhere_else).

reading /etc/passwd is normal (3, Informative)

harlows_monkeys (106428) | more than 7 years ago | (#20362559)

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.

I've discovered even worse Linux privacy problems (5, Funny)

Anonymous Coward | more than 7 years ago | (#20362601)

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.

AppArmor. Hilarious. (0)

Anonymous Coward | more than 7 years ago | (#20362605)

Worst attempt to pimp AppArmor ever. SELinux FTW.

Ka-Zaam! (0)

Anonymous Coward | more than 7 years ago | (#20362629)

what else did you expect from the shop that brought you kazaa?

1989 called... (3, Interesting)

itsdapead (734413) | more than 7 years ago | (#20362639)

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

But what's going out? (1)

Kickstart70 (531316) | more than 7 years ago | (#20362641)

Yeah, it's not quite kosher that the program reads this stuff, but what's more important is tracking what goes from the program back to Skype headquarters. Has anyone tried reading the traffic from it while not connected to a voice call, etc.? Want to get mad about something? Then at least ensure there's a valid and serious reason to do so.

Skype is History (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#20362649)

Why would i even both downloading a closed source product when i can video chat directly from the browser without any downloads using TokBox [tokbox.com] [tokbox.com]

The real question is ... (1)

PinkyGigglebrain (730753) | more than 7 years ago | (#20362661)

what does it do with the data it reads?

Will someone ... (1)

Just_Buch (1088585) | more than 7 years ago | (#20362677)

finally, for one, welcome our new Skype Overlords?

The list (5, Informative)

DaleGlass (1068434) | more than 7 years ago | (#20362721)

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.

This is a realtime app (1)

l2718 (514756) | more than 7 years ago | (#20362939)

Skype is a realtime app (in both a2d and d2a directions). Interrupt statistics, CPU loads etc are vital for the app to decide what quality of encoding/decoding it can afford to do.

Regarding /etc/{passwd,group} others have pointed out this is probably for the GECOS info of the current user. Should be easy to check using a debugger - just need to recompile the C library.

To me, the oddest part is the wholesale reading of mozilla and firefox profiles.

Re:This is a realtime app (1)

DaleGlass (1068434) | more than 7 years ago | (#20363025)

Skype is a realtime app (in both a2d and d2a directions). Interrupt statistics, CPU loads etc are vital for the app to decide what quality of encoding/decoding it can afford to do.


Why isn't it looking in /proc/cpuinfo then? /proc/interrupts doesn't contain any indication of how many interrupts can be serviced, nor the time it takes to service one, or the load caused by the interrupt, so it seems quite pointless performance-wise.

Best harmless use that comes to mind: Skype knows that device X and device Y create problems when sharing IRQ, and contains some sort of message to the user in that case.

It's "ensuring contract compliance" (1)

DingerX (847589) | more than 7 years ago | (#20363123)

Skype has some pay features that come with interesting provisions. For example, you can buy a SkypeIn phone number cheaply for personal use. If you're a business, you pay a different rate for a number that you can use, say, from multiple sites (for example, for follow-the-sun customer service). Temp directory and hardware information are two things that are very rarely the same...

Skype may be NSA spyware (1, Interesting)

mbkennel (97636) | more than 7 years ago | (#20362747)

I have a modest suspicion that skype is more than it seems. I don't believe in 98% of conspiracy theories (like 9/11 'it was a inside job bomb' crap), but this one is not entirely crazy.

I do know that the Intelligence Community people in the US and elsewhere were very concerned about declining abilities to track and trace communications used by their targets, as compared to conventional telecom, where they have quasi-official backdoors installed directly with the telecom companies.

Notice the extraordinary anti-decompiling and self-modifying nature of the skype code---even manages to thwart many popular *hardware debuggers* and virtual machine strategies. The protocol itself is extremely obscure and apparently encrypted. I don't have a link but I think this can be easily verified, as I saw a presentation online which detailed some attempts to understand skype. This was not just good 'ordinary' hackers, but appeared to be the work of very serious and very professional full time computer security people, i.e. state-supported grey hats.

The level of self-security and the investment necessary to pursue this seems totally disproportionate to any commercial needs. This reflects a very serious investment of talent and money.

So why is it there?

But the really unusual fact to ponder is this: Why did eBay buy skype, and at such a high price?
It makes no sense commercially for skype or eBay. I believe the reason is simple: to bring skype development and download servers and most importantly connection servers under U.S. jurisdiction. Once it is so, the government can now (thanks to our now imperial enabling acts) simply order eBay/skype to put in spyware and order them to never talk about it. Most probably the government approached US companies with this proposal and shopped around until it found one who would say yes.

A financial analyst might see something funky in eBay financials if they were clever, there no doubt has to be some payment or other compensation to eBay.

Now the reason for the hypersecurity is clear---to mask whatever data are going *OUT* from skype and whatever it is installing. For some reason I have the suspicion that uninstalling won't completely uninstall quite everything.

There is probably some kind of Manchurian Daemon ability too---if They find somebody they really want to track. Why? Because it makes sense that they'd want to do so.

Re:Skype may be NSA spyware (1)

datapharmer (1099455) | more than 7 years ago | (#20362903)

Wouldn't it be easier to just go straight to hardware manufacturers? This sounds like an ton of work for a software wiretap that *might* get installed compared to say asking Intel to install some microcode on their processor or Bios makers to add a little something something to the boot code. With most computers having integrated ethernet controllers with OnWake commands and soft off power it would be trivial to do something at the machine code level and it would end up on EVERY machine with few ways to detect it.

Re:Skype may be NSA spyware (1)

bcmm (768152) | more than 7 years ago | (#20363221)

There would be few ways to detect NETWORK TRAFFIC which doesn't seem to belong to any process? WTF? If you're gonna get routers to forward this you're gonna need to use normal networking protocols... That means making sure no one is using that port already and so on. Skype would be useful because it has an incomprehensible distributed network protocol in which a few extra kilobytes of data transfer would easily go totally unnoticed.

Re:Skype may be NSA spyware (0)

Anonymous Coward | more than 7 years ago | (#20362995)

Oh come on. Really?

"Why did eBay buy skype, and at such a high price?"

Why did they buy them? Well, it doesn't take a genius. Because they might want to integrate Skype calling into eBay stores. Because it's a good investment. Because they plan to develop ecommerce facilities over Skype. Any number of reasons.

Why at such a high price? How about, because that's what the market valued them at, or because that's how much they thought someone else would pay, and they could afford it? Or if you don't buy either of those, how about 'because it is overvalued and they got poor advice'. Weren't you around in the 1990s?

Prime example of something else seemingly ridiculously overvalued: MySpace.

And as for: 'there no doubt has to be some payment or other compensation to eBay', of course there is. It's called: their stock gaining more interest in the market. Besides that, have you never heard of loss leaders?

You should stick to conspiracy theories about 9/11 and Iraq. In an issue of such serious consequence, there is almost a guarantee that there will be some conspiracy, somewhere, to use it for political gain. "Wes, you gotta say it was Iraq".

But this? Just because the market doesn't always make sense, doesn't mean it is being directed by outside hands whose motives can be divined, but whose actions cannot be detected.

Skype... (1)

JCWDenton (851047) | more than 7 years ago | (#20362899)

--Skype. The whole world can talk for free.-- Skype. The whole world can be spied on for $2 Billion

Skype reads your Skype passwords! (0)

Anonymous Coward | more than 7 years ago | (#20362923)

News at 11

I really hope this turns out to be wrong (1)

Britz (170620) | more than 7 years ago | (#20362955)

Otherwise Skype ist dead for me. The outage was bad enough. There are many alternatives. Ekiga rulz for example.

Please (4, Informative)

joto (134244) | more than 7 years ago | (#20363037)

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

Not a big deal - /etc/passwd is local public info (1)

bl8n8r (649187) | more than 7 years ago | (#20363087)

The firefox profile is a little weird, but programs read /etc/passwd all the time to get the running user ID and groups. If you are not using shadow passwords, you should be, and all normal Unix distros are. Want to know a secret? If you use LDAP, it will query LDAP to find out your UID and GID also. It's normal. /etc/shadow is a different story. Root is the only one that can read that file, and if you are running skype as root, you're foolish.

I'd suggest that anyone with concern about skype on linux simply add a user to the system called "xskype" or similar. Run skype as that user, and it will be contained to only what that user has access to. Problem solved.

Non-issue really... (1)

bealzabobs_youruncle (971430) | more than 7 years ago | (#20363141)

as /etc/passwd can be read by a regular issue, probably just poking for *IDs and ~home. Is there likely a more elegant/less intrusive way for Skype to find what it's looking for? Probably so, but we'll never know as long that they only make binary blobs available. It's a tough call to break down and used closed source, but sometimes functionality trumps the politics. I don't like using the blobs nVidia provides, but I want my eye candy. I don't care for Adobe Flash, but so much content is based on it I chose to make my life easier. I'm not a Skype user so I can't judge, but doesn't Ekiga do ths job pretty well? Does the Skype client only accept calls from other Skype clients?

Firefox (1)

bcmm (768152) | more than 7 years ago | (#20363195)

There is an official Skype Firefox extension. IIRC it recognises phone numbers in web pages and makes them into links so that you can call them more easily. Skype is probably looking for it's extension.

Not an issue (1)

gweihir (88907) | more than 7 years ago | (#20363223)

Any application may read /etc/passwd and other files there. In fact Skype may just read it to find its own UID/GID and doing it in this way is prefectly acceptable. There are two things that every halfway secure Unix system does to secure /etc/passwd 1) shadow-passwords, i.e. that actual encrypted passwards are in /etc/shadwo, which is not readable except for root and 2) salting, which makes dictionary attacks against encrypted passwords much, much harder.

Symmary: Nothing to see here, except some people that do not undertsand Unix security.

Skype is due to be replaced (2, Informative)

RealBorg (549538) | more than 7 years ago | (#20363249)

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
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?