Le 23/08/2015 10:38, Basil Chupin a écrit :

Need more?

yes. I know friends or family hit by viruses or malware on Windows, but I never met somebody having similar problem with Linux. The only hard problems I know of are problems with people having direct access to the keyboard (and there there is little to do) not to say this can't happen, but it's not common. I would like to hear such story, let only to know how to prevent them or recover from them eventually thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/22/2015 04:36 AM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2015-08-22 08:45, Lew Wolfgang wrote:

...

Hi Folks,

This is kind of a rhetorical question. Has there ever been a documented instance of malware being injected into either a base openSUSE release, or that was delivered by subsequent patch/application loads from repositories? How about the semi-official repositories? Not that I know.

...

And are there any controls in place to prevent manipulation of repository mirrors? I know that the repositories have signatures, but what about the individual rpm files? Is there a master SHA-256 hash database that downloaded files could be checked against before being installed? The files are PGP signed.

The problem, though, is that the signatures are not visibly published for verification. There is a bugzilla on this, nothing done.

I checked SLES-12-Server release notes (3.2.2) here: https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/ It "implies" that libzypp will check downloaded rpm package signatures. Is this true? Here's the first two sentences: libzypp-14.39.0 will per default check a downloaded rpm packages signature, if the corresponding repositories metadata are not gpg signed or the signature was not verified. Customers using unsigned repositories may experience that zypper/yast now ask whether to accept a package whose signature can not be checked because the signing key is not known [4-Signatures public key is not available]: This implies that each rpm will be checked "if" the repository metadata isn't signed. Would a valid repository signature turn off per-rpm checks? This led me to check openSUSE 13.2 zypper's man page and found: Zypp verifies the authenticity of repository metadata by checking their GPG signature. If the repository metadata are signed with a trusted key and and successfully verified, packages from that repository are accepted for installation if they match the checksum provided in the metadata. If the repository metadata are not signed, the signature of each downloaded rpm package is checked before accepting it for installation. This default behavior can be tuned by explicitly setting the variables r epo_gpgcheck and/or pkg_gpgcheck in the ZYpp configuration file (/etc/zypp/zypp.conf) to perform those checks always (if on) or never (if off). Disabling GPG checks is not recommended. Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise. This sounds like good news! I'll fiddle around with it a bit. I've got a local repository image that I can test. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 23.08.2015 um 16:42 schrieb greg.freemyer@gmail.com:

In one of the linux CMS cases, the bad guys injected a malicious control app to append all credit card data going through the shopping cart to an existing picture file on the server. Then they simply used apache to serve up the file anytime they wanted it. If the file was opened in a web browser / image viewer, you saw the image. If opened in a text editor, you saw all the confidential data at the end of the file.

Nice. Do you have any links for this attack? Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/23/2015 07:42 AM, greg.freemyer@gmail.com wrote:

On August 22, 2015 2:45:30 AM EDT, Lew Wolfgang wrote:

...

Hi Folks,

This is kind of a rhetorical question. Has there ever been a documented instance of malware being injected into either a base openSUSE release, or that was delivered by subsequent patch/application loads from repositories? How about the semi-official repositories? I remember the forums were compromised once upon a time. Lew, hating to be pedantic, but what is malware?

Good point! For this discussion we can say that any unauthorized modification of anything in a repository after it was published is suspect. The "authority" in this case would be the person/organization responsible for the publishing. Any modification of a package subsequent to being published must be assumed to be threatening. One of my customers is worried about malware injection in mirrored repositories, possibly located in bad neighborhoods. But it looks like zypper can be instructed to check each rpm's pgp signature. I'll try testing this later to see if it really flags a modified binary. Malware injection prior to authorized publication is another matter. How well does openSUSE check for this? Does SUSE do a more thorough job with SLES? How about RedHat? How about hardware vendors? I heard that Lenovo motherboards have a BIOS that detects a Windows install and if found, replaces a key Windows binary with one of it's own. It's basically a BIOS-resident root-kit that is completely invisible to the operating system. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On August 23, 2015 2:30:56 PM EDT, Xen wrote:

On Sun, 23 Aug 2015, Lew Wolfgang wrote:

...

(..) How about hardware vendors? I heard that Lenovo motherboards have a BIOS that detects a Windows install and if found, replaces a key Windows binary with one of it's own. It's basically a BIOS-resident root-kit that is completely invisible to the operating system.

That is actually pretty cool :D.

I would not quickly be interested as an attacker to start injecting malware into repositories. Considering that it is probably only useful if you have a specific target in mind (supposing a large business or organisation uses openSUSE and I want to compromise it) I would start thinking of compromising the business directly because it would be hard to tell if any modification of a really public place (like a repository) would make it through unscathed. I would have to duplicate the server setup and apply my modifications there, and then think about how likely it is to be discovered within a sensible amount of time. I would probably need to modify a binary (supposing a single binary) at the precise interval between a new version of that package being uploaded to the mirror and the time when clients everywhere are going to download it for installation. Moreover, I either need to ensure I compromise.... you see it is hard to direct the attack at a specific target.

What is left is non-specific targets, but if I compromise only a single

repo, I might not be sure where my exploits end up. It would be pretty random, perhaps geographically located. I would need to ensure that my modification propagates itself to other less suspect binaries before wiping itself out. This is the only way for me (at least) to ensure a stable presence on the remote system. Ideally it would open a backdoor for further code injection or manual intervention. The timeframe is limited in any case on most systems. You would consider that you need to pull off what you want to do in days, not weeks.

Supposing I were that kind of attacker, it would take me weeks (if being in the position) to develop an automated system that can pull it off without much to do for myself. As a corporation I would be afraid of targeted attacks. There would be people interested in obtaining secrets or retrieving data. Keys, email addresses, not necessarily accounts. I guess particularly server certificates (private keys) and the like would be of interest; not that I know anything of it. The setup would probably be to build towards a larger attack that can obtain real moneys.

Myself would be most interested in encryption secrets. Whatever they have encrypted; I want to have it ;-).

Just my two cents of worthless thinking ;-).

Probably not worthless, but also not informed by the reality what is happening out there. In reality bad guys often blindly infect hundreds/thousands of machines at time, then over a period of weeks or months they evaluate their successes to see what they have. When they find out random chance got them a pot of gold, they start to explore the penetrated machine and/or network to figure out the best way to leverage it. Each repository serves thousand of end user machines. Some of those will be valuable machines. Definitely a target worth trying g to penetrate so Lew's customer is very correct in wanting to make sure the chain of trust extends as far back as possible. Greg -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2015-08-23 19:07, Lew Wolfgang wrote:

How about hardware vendors? I heard that Lenovo motherboards have a BIOS that detects a Windows install and if found, replaces a key Windows binary with one of it's own. It's basically a BIOS-resident root-kit that is completely invisible to the operating system.

No, not exactly. The code is triggered by the Windows operating system, which can run certain code in the UEFI memory. It is documented by Microsoft. This is (guessing) intended so that you can install a vanilla copy of Windows (≥8, I think), Windows will run this code in the hardware, and this will run things that installs customizations for that hardware. It could be drivers specific for it, thus safe. Or "safe". Linux would not trigger this, but it might if wanted. Not this particular code which is designed for Windows. Some other code in the bios (not bios, but UEFI) designed for Linux. Given that there is no such thing as a single "Linux", it can't be done. I think. The problem is that the Lenovo code does not check that the site that it connects to for downloading pieces is not verified. It could be hijacked, and install something else very different than what was intended. That was the security risk found. Of course, there is the issue that your installation is modified without your explicit permission. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 08/23/2015 01:40 PM, Marcus Meissner wrote:

On Fri, Aug 21, 2015 at 11:45:30PM -0700, Lew Wolfgang wrote:

...

Hi Folks,

This is kind of a rhetorical question. Has there ever been a documented instance of malware being injected into either a base openSUSE release, or that was delivered by subsequent patch/application loads from repositories? Not to our knowledge.

...

How about the semi-official repositories? I remember the Not to our knowledge.

...

forums were compromised once upon a time.

...

And are there any controls in place to prevent manipulation of repository mirrors? I know that the repositories have signatures, but what about the individual rpm files? Is there a master SHA-256 hash database that downloaded files could be checked against before being installed? Yes. The root trust is the openSUSE GPG Key, which signs the repomd.xml in the officialy YUM repositories. This key is on the installation medium.

...

From the repomd.xml sha256 hashes are used to confirm the correct sub-xml files of the YUM repository and also the RPMs.

If one part (xml file or rpm) is exchanged, prominent warnings will appear.

There is no master SHA256 database.

Ciao, Marcus

Thanks Marcus. Is this documented anywhere? A link would be great! I have a feeling I'm going to have to explain all this to a customer. I'm sure the SUSE Enterprise repositories work the same way, right? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org