lxc-pve_7.0.0-1_amd64.deb compromised?

[wire2hire]

i saw on reddit a thread with a upload to virustotal, for the packages , flags as linux trojan.

https://www.reddit.com/r/Proxmox/comments/1tge2n9/lxcpve_7001_amd64deb_compromised/

https://www.virustotal.com/gui/file/bba98be326313bfb0ac4eb86229e427f74068c9a4c5bfc665f63109feb6ac21b

is this a false positiv?

Greets

 

[leesteken]

I expect that you to trust virustotal (since you use it) more than the random strangers from the internet on this forum. If Proxmox did this on purpore then you should not trust their answer either. Do you see anything suspect in those shell code snippets on the virustotal website?

EDIT: Regarding dh_installsystemd: https://man7.org/linux/man-pages/man1/dh_installsystemd.1.html

 

[wire2hire]

i dont believe the devs make it on her own . but only the devs can look into the code if this are right or compromised.

 

[leesteken]

In that case, check this with @wbumiller and @fabian: https://git.proxmox.com/?p=lxc.git;...d5837bfa2ce7df3487b0793f9b350bb00e718;hb=HEAD

 

[fabian]

It does look like a false-positive to me.

The file that gets flagged is the statically linked init executable of LXC (/usr/bin/init.lxc.static), which can probably trip up some scanners. Unfortunately, there are no details other than "something detected" to know what causes the detection.

If I rebuild the package using today's build env (with Trixie 13.5 as baseline) and on a different machine then the one in the repository was built on, that binary does no longer trip the scanner, despite being the exact same size with just build-id and structure of the binary (offsets/..) changed.

 

[wire2hire]

on the reddit thread. another scan comes up:

https://metadefender.com/results/fi...lJaRkJVVFUwM09FbHZjM0JqX21kYWFzMjM3OTRmMmMyNA

thanks for your lookup!

looks like since 3 days:

https://www.reddit.com/r/Proxmox/comments/1tdjn28/sophos_firewall_marked_an_update_for_my_proxmox/

 

[allum.skulls]

Thanks for looking into this, @fabian.

Any plans to release the rebuilt package?

Even if a false positive, this is likely to hold users from updating, potentially missing other important security fixes like the recent kernel ones.

 

[t.lamprecht]

We decided against it intitally as doing so is IMO suspicious on it's own. If you're a customer of those services, you could report it as false positive though, which could avoid false-positives in other executables and help more overall.

That said, those vendors seldomly care and policy often requires these things, so we might indeed do the bogus rebuild.

 

[allum.skulls]

Thanks! I can see the logic of reporting the false positive to the vendors too.

I understand it is confirmed this is indeed a false positive and a possible supply chain attack has been ruled out?

 

[t.lamprecht]

I understand it is confirmed this is indeed a false positive and a possible supply chain attack has been ruled out?

Yes, you can even confirm that yourself by rebuilding the same lxc-pve repo state twice, namely:

1. rebuilding with Debian baseline frozen on May 1st -> binary is bit-wise identical and gets flagged.
2. rebuilding with Debian baseline from today (Trixie 13.5 has been released in the meantime, so some core packages got updated) -> binary is no longer bit-wise identical and no longer gets flagged.