rocker-org / rocker

R configurations for Docker
https://rocker-project.org
GNU General Public License v2.0
1.45k stars 273 forks source link

xz-utils backdoor #547

Closed korrelate-vc closed 4 months ago

korrelate-vc commented 4 months ago

Hi,

I am using the latest version of the r-base docker image (FROM rocker/r-base:latest). I'm not sure if you're aware of the exploit in debian version of xz v5.6.0/v5.6.1 (liblzma). I noticed that the latest version I pulled contained the afflicted library:

image

The recommendations I have read are to update the library or revert to a stable version. For my OS (ubuntu) I have v5.2.1 which is not compromised.

Sincerely, Kevin

eddelbuettel commented 4 months ago

But I presume you not running sshd (which is how the exploit was aiming to do damage) in that container? If I do an apt update -qqq; apt install -y procps then ps -aux shows nothing is running as docker is, after all, by default a single process:

root@a90632d4c6ba:/# ps -aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0   7216  3840 pts/0    Ss   17:39   0:00 bash
root         236  0.0  0.0  10740  4224 pts/0    R+   17:41   0:00 ps -aux
root@a90632d4c6ba:/# 

(The hostname is AFAIK entirely random so no need to obfuscate / hide in the screenshot. Also textual quotes work great here thanks to markdown and code formatting....)

korrelate-vc commented 4 months ago

Thanks for the tips, I don't comment on issues often so I appreciate the feedback. Yes, I am not running sshd (and therefore it's not a risk). I was just checking through my containers with different base images and this was the only one with the vulnerability. Seems like you are aware of the issue, thanks for taking the time to respond :).

All my best, Kevin

eddelbuettel commented 4 months ago

Yes, I'd be happy to rebuild but I just want to clarify that it is a bit of a non-issue. Also rocker/r-base famously becomes r-base (ie a core Docker container) and we treat those as immutable.

Maybe with R 4.3.3 coming to end of life a rebuild is fine, on other other hand we are having a bit trouble right now with testing because of the 64 bit time_t transition which may pull more in than we like from unstable. Come to think about it that was the case already for the 4.3.3 build so maybe I just rebuild.

Typing from a happy Ubuntu workstation with an updated xz etc (as I am surely running sshd here...) ...

eddelbuettel commented 4 months ago

I just rebuilt (and pushed) them (for tags 4.3.3 and latest).

It moves packages xz,liblzma{5,-dev} package from 5.6.0-0.2 to 5.6.1+really5.4.5-1. It should not matter for the container providing R, but it does not hurt and we all sleep better that way.