Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Skype Linux Reads Password and Firefox Profile

Posted by samzenpus on Sun Aug 26, 2007 10:40 AM
from the to-send-better-ads dept.
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 discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • Shadow passwords FTW (Score:5, Insightful)

    by strredwolf (532) on Sunday August 26, @10:42AM (#20362385)
    (http://stalag99.net/ | Last Journal: Tuesday August 14, @12:20PM)
    This is why you should have shadow passwords, so that your encrypted password isn't stored in /etc/passwd.
  • Why.. (Score:5, Insightful)

    by mikkelm (1000451) on Sunday August 26, @10:42AM (#20362389)
    .. only closed source applications? I don't think most people read the entire sources of open source applications that they use.
    • Re:Why.. (Score:5, Insightful)

      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.
      [ Parent ]
      • Re:Why.. (Score:5, Interesting)

        by mikkelm (1000451) on Sunday August 26, @11:05AM (#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.
        [ Parent ]
        • Re:Why.. by Tribbin (Score:3) Sunday August 26, @04:50PM
        • Re:Why.. by bit01 (Score:2) Sunday August 26, @05:07PM
      • Re:Why.. (Score:5, Interesting)

        by optimus2861 (760680) on Sunday August 26, @11:06AM (#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.
        [ Parent ]
        • Re:Why.. by Anonymous Coward (Score:1) Sunday August 26, @11:53AM
          • Re:Why.. (Score:5, Informative)

            by gtwilliams (738565) on Sunday August 26, @04:22PM (#20365289)
            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.
            [ Parent ]
            • Re:Why.. by dotgain (Score:1) Monday August 27, @02:25AM
              • 1 reply beneath your current threshold.
        • Re:Why.. (Score:5, Informative)

          by perlchild (582235) on Sunday August 26, @12:20PM (#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.
          [ Parent ]
          • Re:Why.. by Jartan (Score:2) Sunday August 26, @10:40PM
            • Re:Why.. by perlchild (Score:2) Sunday August 26, @11:44PM
          • Re:Why.. by fmaresca (Score:1) Monday August 27, @08:48AM
          • Re:Why.. by blz (Score:1) Tuesday August 28, @12:42AM
        • Re:Why.. (Score:5, Informative)

          by jimicus (737525) on Sunday August 26, @12:33PM (#20363311)
          (http://www.whitepost.org.uk/)
          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.
          [ Parent ]
        • Re:Why.. by mattpalmer1086 (Score:2) Sunday August 26, @04:20PM
      • Flawed logic (Score:5, Interesting)

        by Sycraft-fu (314770) on Sunday August 26, @11:20AM (#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.
        [ Parent ]
        • Re:Flawed logic (Score:5, Insightful)

          by DaleGlass (1068434) on Sunday August 26, @11:52AM (#20362943)
          (http://daleglass.net/)

          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
          [ Parent ]
          • Re:Flawed logic by nwbvt (Score:2) Sunday August 26, @01:54PM
            • Re:Flawed logic (Score:4, Insightful)

              by DaleGlass (1068434) on Sunday August 26, @02:23PM (#20364209)
              (http://daleglass.net/)

              Would it be difficult? Sure. But if you think it is impossible to hide an access to a file you are not supposed to see, you are obviously either new to writing software, or you lack imagination.

              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.

              Thats an example of why such activities should be rare in the commercial world, where the developer's name, address, social security number, etc., are all on record. But not in the world of many open source projects where it is perfectly possible for someone to be practically anonymous when they submit their patches.

              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.

              Considering how many software packages a person typically has installed on their machine, that extra 1% is pretty dangerous. Yes, the official packages you got straight from the distro may all be fine, what about that new upgrade you went to that great new rpm repository your buddy told you about?

              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.

              You honestly think the owners of the distros look at all the source of each package they include? You must think they have no lives whatsoever.

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

              I fail to see how that helps. How do you know the different compiler isn't the one with the Trojan? Its like if we were picking apples from a tree and I point out you have no way of knowing the one you just picked hasn't been poisoned, you throw that apple away and pick another one.


              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.

              I'm not saying don't use open source software. Just don't pretend it is immune to the problems that plague commercial software and forget about all precautions (like not running something like AppArmor, to tie this back to the original point) just because what you are running is under the GPL.


              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.
              [ Parent ]
          • Re:Flawed logic by Yoooder (Score:1) Sunday August 26, @02:33PM
          • 1 reply beneath your current threshold.
        • Re:Flawed logic (Score:4, Interesting)

          by SanityInAnarchy (655584) <ninja@slaphack.com> on Sunday August 26, @12:56PM (#20363507)
          (Last Journal: Tuesday October 30, @10:59AM)

          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.

          The more obfuscated it is, the more likely it is that the open source community would just rewrite that chunk of code for being too difficult to understand.

          The challenge is not only to make it impossible to see what the code is doing, but to make it possible to think you know what the code is doing, and still miss what it's really doing. And at the end of the day, it has to spell out /etc/passwd in the code somewhere, or it has to have code that generates it, and it would take a LOT of work to write code which generates '/etc/passwd' while also never spelling it and looks innocent.

          (Ditto for any other way you'd do this. There are standard library functions to access passwd, and those would be just as hard to hide.)

          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.

          You only need one whistleblower developer to end that charade. And that one whistleblower would bring in hundreds or thousands of developers who'd never bothered to look at the code, who would read it and say "Yep. Looks evil."

          Compare that to proprietary software -- it takes someone actively trying to reverse-engineer the software in some way; here, running it in a restricted environment. Even once you have someone doing that, it can be a lot less trivial than "just look at the source" for someone else to verify it.

          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.

          Well, this is Skype we're talking about. It's popular enough that someone would have looked.

          Also, consider the person making such "evil" software -- would they really be ballsy enough to assume no one would read the source? True, there could be some open projects with "evil" code in them that nobody's bothered to read, but anyone doing that is taking the chance that someone, somewhere, would read it and discover what they're doing.

          And then there's the question of what happens when they discover it. Like right now, no one has a clue why Skype would be reading passwd. We assume it's evil, but we don't really know. Were it open source, we could just go read the code, and instantly see if there's a legitimate reason. If there wasn't, we could patch the "evil" bits out and keep using Skype as if nothing happened.

          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.

          As the sibling post says, in general, most distros compile from source. So if you trust Ubuntu, say, you don't have to trust a hypothetically open source Skype in this respect -- the Ubuntu people would have compiled it from source themselves, and cryptographically signed the binaries.

          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 kind of rules out it being Skype's fault, then, for

          [ Parent ]
        • Hidden code... by Twisted64 (Score:1) Sunday August 26, @09:58PM
      • Re:Why.. by Score Whore (Score:1) Sunday August 26, @01:07PM
      • Re:Why.. by nwbvt (Score:2) Sunday August 26, @01:17PM
        • Re:Why.. by SL Baur (Score:2) Sunday August 26, @02:00PM
          • Re:Why.. by nwbvt (Score:2) Sunday August 26, @04:25PM
            • Re:Why.. by SL Baur (Score:2) Sunday August 26, @08:49PM
              • Re:Why.. by nwbvt (Score:2) Monday August 27, @12:18AM
        • Re:Why.. by Xabraxas (Score:2) Sunday August 26, @07:08PM
          • Re:Why.. by nwbvt (Score:2) Sunday August 26, @07:57PM
            • Re:Why.. by Xabraxas (Score:2) Monday August 27, @05:11PM
      • Re:Why.. by mjsottile77 (Score:2) Sunday August 26, @01:29PM
        • Re:Why.. by trewornan (Score:2) Sunday August 26, @06:16PM
      • Re:Why.. by OriginalArlen (Score:2) Sunday August 26, @02:28PM
      • Re:Why.. by nacturation (Score:2) Sunday August 26, @08:13PM
      • If we each think someone else checked the source? by KWTm (Score:2) Sunday August 26, @11:18PM
      • 2 replies beneath your current threshold.
    • Re:Why.. by gomiam (Score:1) Sunday August 26, @10:48AM
    • Well... by Attaturk (Score:2) Sunday August 26, @10:48AM
    • Re:Why.. by Ajehals (Score:3) Sunday August 26, @10:50AM
    • Re:Why.. by DaleGlass (Score:3) Sunday August 26, @10:57AM
    • 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.

      [ Parent ]
      • Re:Why.. by IWannaBeAnAC (Score:3) Sunday August 26, @11:28AM
        • Re:Why.. by jgrahn (Score:2) Sunday August 26, @12:05PM
          • Re:Why.. by gtwilliams (Score:1) Sunday August 26, @04:36PM
            • Re:Why.. by Nasarius (Score:2) Sunday August 26, @09:51PM
      • Re:Why.. by ciroknight (Score:2) Sunday August 26, @11:30AM
        • Re:Why.. by 19thNervousBreakdown (Score:2) Sunday August 26, @11:39AM
        • 1 reply beneath your current threshold.
      • Re:Why.. small reality check! by pjr.cc (Score:2) Sunday August 26, @11:47AM
      • Re:Why.. by SanityInAnarchy (Score:2) Sunday August 26, @01:04PM
        • Re:Why.. by MP3Chuck (Score:2) Sunday August 26, @05:46PM
      • Re:Why.. by TechwoIf (Score:1) Sunday August 26, @04:32PM
      • Re:Why.. by 19thNervousBreakdown (Score:2) Sunday August 26, @11:44AM
      • 2 replies beneath your current threshold.
    • Re:Why.. by cduffy (Score:2) Sunday August 26, @11:44AM
    • Re:Why.. by WilliamSChips (Score:2) Sunday August 26, @12:28PM
    • Re:Why.. by chubs730 (Score:1) Sunday August 26, @02:15PM
    • 2 replies beneath your current threshold.
  • /etc/password (Score:5, Insightful)

    by Colin Smith (2679) on Sunday August 26, @10:44AM (#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.

     
  • I am not suprised (Score:5, Interesting)

    We already knows that Skype records a lot of other information including your BIOS : http://www.pagetable.com/?p=27 [pagetable.com]
  • Uh oh (Score:1)

    by doyoulikeworms (1094003) on Sunday August 26, @10:48AM (#20362445)
    Russian hackers are getting your passwords!
  • by wangmaster (760932) on Sunday August 26, @10:48AM (#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 (Score:5, Insightful)

    by arivanov (12034) on Sunday August 26, @10:50AM (#20362459)
    (http://www.sigsegv.cx/)
    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 (Score:4, Interesting)

      by 11223 (201561) on Sunday August 26, @10:55AM (#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?
      [ Parent ]
    • Re:What a load of FUD by DaleGlass (Score:3) Sunday August 26, @11:01AM
      • 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.

        [ Parent ]
      • Re:What a load of FUD by arivanov (Score:2) Sunday August 26, @11:34AM
      • Re:What a load of FUD by gtwilliams (Score:1) Sunday August 26, @04:45PM
    • Re:What a load of FUD (Score:4, Funny)

      by mpeg4codec (581587) on Sunday August 26, @11:21AM (#20362701)
      (http://www.lacklustre.net/)

      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.
      [ Parent ]
    • Re:What a load of FUD (Score:5, Insightful)

      by mysidia (191772) on Sunday August 26, @12:58PM (#20363517)

      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.

      [ Parent ]
    • 2 replies beneath your current threshold.
  • hard to avoid (Score:2, Informative)

    by m2943 (1140797) on Sunday August 26, @10:50AM (#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 (Score:1, Informative)

    by Anonymous Coward on Sunday August 26, @10:51AM (#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.
    • 1 reply beneath your current threshold.
  • shadows (Score:2)

    by SolusSD (680489) on Sunday August 26, @10:52AM (#20362479)
    (http://www.solussd.com/)
    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 (Score:2, Insightful)

    by vfaded (1147805) on Sunday August 26, @10:53AM (#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.

  • by 11223 (201561) on Sunday August 26, @10:53AM (#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.
  • reading /etc/passwd is normal (Score:4, Informative)

    by harlows_monkeys (106428) on Sunday August 26, @11:03AM (#20362559)
    (http://www.tzs.net/)
    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.

  • by Anonymous Coward on Sunday August 26, @11:08AM (#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.
  • 1989 called... (Score:4, Interesting)

    by itsdapead (734413) on Sunday August 26, @11:12AM (#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).

  • by Kickstart70 (531316) on Sunday August 26, @11:13AM (#20362641)
    (http://www.gastips.com/)
    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.
    • 1 reply beneath your current threshold.
  • by PinkyGigglebrain (730753) on Sunday August 26, @11:15AM (#20362661)
    what does it do with the data it reads?
  • Will someone ... (Score:1)

    by Just_Buch (1088585) on Sunday August 26, @11:17AM (#20362677)
    finally, for one, welcome our new Skype Overlords?
  • The list (Score:5, Informative)

    by DaleGlass (1068434) on Sunday August 26, @11:25AM (#20362721)
    (http://daleglass.net/)
    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.

  • Skype may be NSA spyware (Score:1, Interesting)

    by mbkennel (97636) on Sunday August 26, @11:28AM (#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.
  • Skype... (Score:1)

    by JCWDenton (851047) on Sunday August 26, @11:46AM (#20362899)
    --Skype. The whole world can talk for free.-- Skype. The whole world can be spied on for $2 Billion
  • by Britz (170620) on Sunday August 26, @11:52AM (#20362955)
    Otherwise Skype ist dead for me. The outage was bad enough. There are many alternatives. Ekiga rulz for example.
    • 1 reply beneath your current threshold.
  • Please (Score:5, Informative)

    by joto (134244) on Sunday August 26, @12:00PM (#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...

  • by bl8n8r (649187) on Sunday August 26, @12:05PM (#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.
  • by bealzabobs_youruncle (971430) on Sunday August 26, @12:12PM (#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 (Score:2)

    by bcmm (768152) on Sunday August 26, @12:18PM (#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.
    • 1 reply beneath your current threshold.
  • Not an issue (Score:2)

    by gweihir (88907) on Sunday August 26, @12:23PM (#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.
  • 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
  • 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.

    It shows how important it is to secure your system, whether Linux, Windows, or any other, against trusting any app too much with resources not created by, or explicitly granted to, the trusted app.

    It also shows that it's too hard to trust closed source apps on any platform, even when closed source is the default status.

    It also shows that AppArmor can protect you from untrustworthy apps, unless it won't run on your platform (like Windows).

    It also shows why Linux is more trustworthy than is Windows, especially when Linux is used with open source apps, which are the default, which can be inspected by lots of people for trustworthiness.

    That kind of untrustworthiness also shows that Skype cannot be trusted not to spy on all your phone conversations and address books. I know I don't trust it. This latest "secret prying" behavior erodes any trust that's misplaced in giving it access to your personal data, including media (that includes your conversations).
  • Um... duh? (Score:1)

    by cylence (129937) <micah@cowan.name> on Sunday August 26, @01:15PM (#20363657)
    (http://micah.cowan.name/)
    Programs don't read /etc/passwd to get passwords (nobody stores 'em in there any more), they read /etc/passwd to map between user ids and user names. Chalk this up to the most overhyped nothing I've seen posted to /. for a while...
  • AppArmor - Ubuntu? (Score:1, Informative)

    by postmortem (906676) on Sunday August 26, @01:22PM (#20363715)
    (Last Journal: Sunday March 18 2007, @04:53PM)
    AppArmor isn't ubuntu's design to link to Ubuntu package. It is Novell's software, and like should have given them credit.

    Instead, we have again Ubuntu users claiming everything and not doing anything but copying (yes I know GNU)
  • Two small things. (Score:1)

    by Ed Black (973540) on Sunday August 26, @02:00PM (#20364041)
    1. A *LOT* of software looks in /etc/passwd because you can get uid, gid, homedir etc. from there (try grep $USER /etc/passwd - go on) 2. Passwords are very rarely stored in /etc/passwd these days. 3. I've written scripts that touch firefox profiles for stuff as innocuous as protocol handlers..yeah, erm. 4. Why is AppArmor a link to an ubuntu wiki? Are Ubuntu about to invent AppArmor like they invented networkmanager et al?
  • 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 [wikipedia.org]
  • One Too Many Hits (Score:2)

    by Nom du Keyboard (633989) on Sunday August 26, @02:16PM (#20364153)
    This is just one too many hits against Skype. I'd rather use Vonage.
  • by microbee (682094) on Sunday August 26, @02:38PM (#20364369)
    Reading /etc/passwd is necessary for a lot of things, like convert between uid and username, for example. It's not like there is only password in the file. Any person with a bit clue about Unix would know that.

    If the poster is not stupid, I'd think the only reason he posted this is because he wanted to promote apparmor. And it's still stupid.
  • all your passwd (Score:1)

    by yoprst (944706) on Sunday August 26, @02:54PM (#20364497)
    are belong to us!
  • why /etc/passwd? (Score:1)

    by abby.edwards (1147865) on Sunday August 26, @03:17PM (#20364711)
    man nsswitch.conf
  • Lame (Score:2)

    by SQLz (564901) on Sunday August 26, @05:06PM (#20365685)
    (http://www.linuxplatform.org/ | Last Journal: Tuesday December 16 2003, @04:31PM)
    There is a stanard libc library for reading in /etc/password you dolts, you shouldn't have passwords in there anyway. You need things like this to find out the users shell, home directory, etc. Cry me a river, dictionary attack? I mean, make a decent password and use one of the many tools available to notify you of that stuff. Nothing, is secure, security is just a means of slowing people down.
  • by flyingfsck (986395) on Sunday August 26, @05:13PM (#20365751)
    The passwd file stores hashes of the passwords. There is nothing sinister about reading the passwd file in order to do authentication - how the hell else must you do it?
  • Not worried (Score:2)

    by Tribbin (565963) on Sunday August 26, @05:14PM (#20365763)
    (http://tribbin.nl/)
    As long as there is no grand drop in network speed, I'm not worried.
  • This article is retarded (Score:2, Insightful)

    Guess what? The proper thing for any app which saves settings is to read /etc/passwd, and no, it's not to steal your files.
    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:

    struct passwd {
    char *pw_name; /* user name */
    char *pw_passwd; /* user password */
    uid_t pw_uid; /* user ID */
    gid_t pw_gid; /* group ID */
    char *pw_gecos; /* real name */
    char *pw_dir; /* home directory */
    char *pw_shell; /* shell program */
    };

    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 /etc/passwd. I have hundreds of programs on my machine like this.

    If you think a program reading /etc/passwd is automatically malicious, just remove all your binaries now.

    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.
  • How does closed-source program really affect the use of AppArmor? When was the last time the average Linux user had gone through code to make sure that it is doing things as advertised? When was the last time someone verified that the binary package they got from the distribution is the result of the open source code?

    You can't mix ideology with due diligence.
  • #0 0xf7ddc5b3 in getuid () from /lib32/libc.so.6
    #1 0x44a325d5 in _XimLocalOpenIM () from /usr/lib32/libX11.so.6
    #2 0x44a30f2a in _XimOpenIM () from /usr/lib32/libX11.so.6
    #3 0x44a30c70 in _XimRegisterIMInstantiateCallback () from /usr/lib32/libX11.so.6
    #4 0x44a16828 in XRegisterIMInstantiateCallback () from /usr/lib32/libX11.so.6

    #0 0xf7ddc5b3 in getuid () from /lib32/libc.so.6
    #1 0x44a325d5 in _XimLocalOpenIM () from /usr/lib32/libX11.so.6
    #2 0x44a30f2a in _XimOpenIM () from /usr/lib32/libX11.so.6
    #3 0x44a1687a in XOpenIM () from /usr/lib32/libX11.so.6

    The profile thing is a bit different though... The needle in the skype is much worse by comparison, =)
  • This is just a little bit reminding me of RealPlayer. Yet another reason to use free software and ONLY free software. When will people get it?
  • Sure, you could use AppArmor (tm, R, etc). ...or you could use SELinux...

    Let the flamewar begin!
  • by DarkHelmet433 (467596) * on Monday August 27, @12:18AM (#20368405)
    As has been stated 10 million times above, they're not reading /etc/passwd. They're calling the C/Posix API function getpwuid(). Why? Because it is the safest way to find the user's home directory - in order to locate a firefox profile. They probably check $HOME as well.

    Why check the firefox profile? Because they can look at your proxy settings, to see if it needs to use a socks4 or socks5 proxy at all.

    This is all part of their "just works" auto-configuration. It is far from the end of the world.

    Which is a more reasonable explanation?
    1) Skype is data mining stuff to create a giant database of user names and firefox profiles; or
    2) Skype is doing its best to "just work" with your network configuration if possible.

    Option #2 explains all of the "suspicious" activity quite nicely. #1 is absurd if you think about it.
    • 1 reply beneath your current threshold.
  • by risq (1042364) on Monday August 27, @08:41AM (#20370749)
    to keep it simple stupid: - /etc/passwd: almost every prog reads this to turn uid into username, etc.... - firefox profile: it is a read of the proxy settings (automatic proxy detection). i tested this, test it for yourself, change your proxy settings to something different and skype wont connect, on the right proxy settings it connects via http through the firewall (bad enough) so the article is almost complete nonsense, despite the fact that one thing is obviously true: closed source can do harm, dont use it ! the question is not what skype can and does read, but u can easily imagine what a bad program can do with your profile settings in your home directory (read plain text passwords / keys locally stored....) for skype there is still no evidence at all that it does something bad. but i wont use it just because it is closed source !
  • anyway (Score:1)

    by O. El Mekki (1148627) on Tuesday August 28, @08:35AM (#20383115)

    Ever if this alert was an error, I think it's good to have some of this kind sometimes : if anyone think about putting a trojan in a closed sources app for linux, he will think about it twice.

    So if that's really an error, I won't be one of those who blame its authors... :)

  • Incorrect (Score:4, Informative)

    by bakuun (976228) on Sunday August 26, @10:50AM (#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.

    [ Parent ]
  • by someone1234 (830754) on Sunday August 26, @11:26AM (#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.
    [ Parent ]
    • 1 reply beneath your current threshold.
  • SIP sucks (Score:2)

    by SanityInAnarchy (655584) <ninja@slaphack.com> on Sunday August 26, @01:12PM (#20363629)
    (Last Journal: Tuesday October 30, @10:59AM)
    SIP, if I remember, requires so many open ports you may as well not try unless you're sitting on a real Internet IP address, with no firewall, at both ends.

    I believe there's something else you can use instead, some Asterisk-specific but somewhat widely-supported protocol, a bit simpler, only requires one port. There's also Jabber/Gtalk -- I know Kopete supports that now, among other clients. I don't know exactly how the voice works, but it is nice to be able to have one or more central servers to connect to, so at least your endpoints can be behind whatever firewall/NAT people have set up.

    But Skype is actually the technically best solution I've seen, and I wish there was an open source alternative, or an open spec. It actually uses some UDP tricks to allow you to open a connection directly between the two endpoints, requiring no bandwidth from Skype, even if both endpoints are firewalled and NAT'ed. It does require at least one publicly-accessible server, but only for the initialization.

    Of course, for conferences, I'd have to recommend mumble [sourceforge.net], which looks to be intending to replace TeamSpeak and Ventrillo for voice chat in games.
    [ Parent ]
    • 1 reply beneath your current threshold.
  • by FudRucker (866063) on Sunday August 26, @01:45PM (#20363929)
    i was not trying to be a troll, i did not say what i meant to say though...

    let me re-phrase what i meant to say, "the people that put spyware in Kazaa are the people that manufacture Skype"...
    [ Parent ]
  • Re:Which versions? (Score:1)

    by philfr (89798) on Sunday August 26, @04:21PM (#20365275)

    Which versions of Skype, 1.4 or all of them?

    I just checked my 1.3.0.53 version with strings, and strace.

    It does read my passwd file (which is acceptable IMHO), but none of the other files mentioned.

    And the "passwd" string is not in the binary, so it merely uses a getpw* library call.

    Maybe people should stick to an older version ? I don't even know what 1.4 has more to offer (but, OK, I use skype 2 or 3 times a year...)

    [ Parent ]
  • 16 replies beneath your current threshold.