0

From what I understand, the biggest and probably only line of defense against unauthorized software (viruses and worms) from being installed on the system is to simply not allow it unless an admin password has been given.

But what about trojan horses? Let's say a human manages to hack into a trusted PPA repository, and infects various legit packages with viruses (for the sake of the point - someone infects f.lux or wine with a virus that plays a huge looping Nyan Cat on the top layers of the screen with extra loud music). The next user who downloads the package gets infected, because they allowed the program to be installed. They never thought of the possibility of a trojan horse.

The trojan is likely removed quickly by one of the many thousands of eyes watching the Linux community, but chances are good that at least some users get infected. The definition of a virus is something that installs itself on a computer system without consent of an authorized human, and reproduces itself by infecting more systems in that manner. If this happens, they have a virus.

Is that an argument against the supposedly impenetrable security of Linux?

Improve this question

2 Answers 2

Reset to default
3

First, anyone who claims Linux (or any other non-toy OS) is impenetrable is foolish, at best. Some are harder to penetrate than others (OpenBSD is famous for being one of the harder ones); many (including Linux, and even Windows Server) can be secure if maintained by competent admins with sufficient organizational support (enough time, resources, etc.). The amount of effort/time/expense varies between platforms; reasonable claims are about which ones take more or less. Many security issues, by the way, come from the applications installed on the system—not the OS.

Apt repositories nowadays should be GPG-signed, which creates a cryptographic proof of integrity from the repository's maintainer. If someone breaks into the server and tampers with one of the packages, then its checksum won't match the Packages file (and if they change that to, that won't match the Release file, and if they tamper with that, the signature will fail).

Of course, if an attacker manages to steal the maintainer's private key, the attacker can put malicious packages in the repository. There should be (for a trustworthy repository at least!) a few defenses that make this hard:

  • The private key should be encrypted with a secure passphrase, known only to the maintainer(s).

  • The private key should be stored on a secure machine with limited access—not the publicly-accessible web server. Even better is to store it in tamper-resistant hardware (e.g., a smartcard).

Finally, if the repository is compromised, and you install a malicious package, your machine is compromised. Do not use repositories you do not trust.

Improve this answer
0

I believe that one of the defence mechanism against that, is that there is a checksum on these packages, and if a package was changed, the checksum indicated would not match the computed one, then of course you could imagine that the hacker could modify the checksum to reflect the new fraudulent package, but first it would be difficult, and second, no system is perfect...

Improve this answer
1
  • The hacker cannot modify the checksum. Or rather, the hacker can modify the checksum, it's easy, but then the signature will become invalid. And the attacker cannot modify the signature so that it both remains valid and remains consistent with the checksum. Commented Mar 9, 2015 at 22:45

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.