Skype Linux Reads Password and Firefox Profile 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."
Shadow passwords FTW (Score:5, Insightful)
Why.. (Score:5, Insightful)
/etc/password (Score:5, Insightful)
What's it doing? Well, what libraries is it linked with? Perhaps it's converting your UID into a name among other things.
Re:Why.. (Score:5, Insightful)
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
What a load of FUD (Score:5, Insightful)
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
Why /etc/passwd access is benign (Score:2, Insightful)
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:/etc/password (Score:2, Insightful)
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:Why.. (Score:3, Insightful)
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:What a load of FUD (Score:3, Insightful)
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 (Score:5, Insightful)
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:Flawed logic (Score:5, Insightful)
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.
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.
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.
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:/etc/password (Score:3, Insightful)
Re:What a load of FUD (Score:5, Insightful)
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:your a queer (Score:4, Insightful)
Response to another idiot (Score:0, Insightful)
Linux users are nowadays just as stupid as mainstream.
Re:your a queer (Score:5, Insightful)
Re:Flawed logic (Score:4, Insightful)
Ok, if you're so clever, provide an example of code that reads a file without making it easy to tell what it's doing, while avoiding looking suspicious.
Don't change subject. The original post was about a developer releasing "evil" code, then turning somebody who finds it to their side. Now you're talking about people submitting patches with somethind hidden in them. Completely different scenarios.
Most OSS projects don't blindly accept patches. Certainly not the ones in widespread usage. You might sneak a buffer overflow in, but to sneak an outright trojan would be seriously challenging. The submitter's anonymity isn't a problem if source is being examined.
Stupidity exist everywhere of course, can't be eliminated 100%. But while for Linux users perhaps 1% of all software comes from unverified sources, for Windows users it's 99%. Just why exactly do you trust that say, Trillian isn't doing anything strange? Nobody but its developers really knows what's there.
Not all of it, but there are many distributions, which each look at different parts of the source. To sneak something in you'd need to be really sure that part won't get looked at by anybody, and that's hard. Developers watch mailing lists, talk to people who work on the project and use 'svn diff'.
First you build gcc with icc. This is icc_gcc.
Then you build another copy of gcc with gcc. This is gcc_gcc.
Now you have two gccs with different code generated by different compilers.
So now you take both of those, and build the gcc source with both icc_gcc and gcc_gcc. Both should generate the same code. If they don't, something's fishy.
You can easily this with more compilers and multiple versions.
Well, I still think it can't be defined that the OSS approach is superior. It's not impossible to sneak something in. But in doing so you must take a very high risk of being found out, and if somebody tracks that back to you, well, chances are you're going to have to look for a new carreer. People with a known record of coding nasty things aren't very liked in the software world.
Re:Flawed logic (Score:3, Insightful)
Right. And that bit of code looks obviously harmless. You'd obviously scroll right by it if you saw it in some package's source, because there's absolutely no chance anything odd would be going on in a piece of code like that.
I mean seriously, that SCREAMS that there's something odd there.
Here's the same challenge for you as for the other poster: Write some code that accesses some file it shouldn't, and does something with the data in it (writing it to a socket say) in such a way that you can't tell what's it doing without looking really well at it, and it looks harmless or to be doing something else.
This obviously excludes clear obfuscation, horrible formatting, encoding the filename in any way, hiding the file open by doing the syscall by calling int 80, etc.
Re:But...More Secure? (Score:3, Insightful)
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.
Re:your a queer (Score:2, Insightful)
Readable to all.
Re:Shadow passwords FTW (Score:3, Insightful)
As for the Firefox jazz, did they allow the default install of the Skype Firefox plugin? If so, why wouldn't it poke around in ~/.mozilla?
There's lots of information we don't have, and sensationalist crap ensues. If someone is really worried, why bother using Skype? It's a service, not a $DEITY-given right, to use.
This article is retarded (Score:2, Insightful)
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.
Re:Shadow passwords FTW (Score:4, Insightful)