Bioconductor/BBS

libwebp security issue

Closed this issue · 1 comments

jwokaty commented

From Tomas's email:

my understanding is that the problem is present on all platforms. An attacker could create a crafted image (e.g. tiff) with webp encoded content, which would execute arbitrary code on a machine where it is viewed/decoded using an old version of libwebp. So we need to make sure that software using libwebp (and decoding images) has an updated version of libwebp.

With R packages, it depends where they get libwebp. If they link only against libwebp from Rtools, as is required on CRAN, it is just enough to rebuild (reinstall from source) packages using the new Rtools (and you can simply rebuild all not thinking about which uses libwebp for reading and which not). Some packages embed source code of external libraries or download it, and such would have to be updated to use the latest version. Some packages (on CRAN) download pre-compiled libraries, violating the CRAN policy, and they would also have to be updated to use the latest version if they don't yet.

On Windows, as the linking is static, unless package authors were very creative in obfuscating things, a quick way to find out which packages use directly libwebp may be "grep lwebp *.out" where *.out are installation outputs. I've done this on my subset of Bioconductor packages I am building and I didn't find any package linking to libwebp, maybe you are lucky and there is none.

A more sophisticated test on Windows can be done when you have built your packages without stripping DLLs. By default, DLLs are stripped, so one has to change that and reinstall (all) packages from source. Then, you can grep the DLLs looking for say "WebPGetDecoderVersion", which is an indication that the package links to webp.

If you build packages without stripping symbols, you can then also find out the WebP version this way via disassembly, e.g. for CRAN package webp, you get

objdump -dS webp.dll

00000001e68bd530 :
1e68bd530: b8 02 03 01 00 mov $0x10302,%eax
1e68bd535: c3 ret
1e68bd536: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
1e68bd53d: 00 00 00

in the above, the $0x10302 is the webp version. The constant is formed this way:

int WebPGetDecoderVersion(void) {
return (DEC_MAJ_VERSION << 16) | (DEC_MIN_VERSION << 8) | DEC_REV_VERSION;
}

and so 0x010302 corresponds to the current version

// version numbers
#define DEC_MAJ_VERSION 1
#define DEC_MIN_VERSION 3
#define DEC_REV_VERSION 2

which is ok. But if you find any older version, it is a problem.

When one doesn't know if a package could actually decode an image (with webp codec) or not, it is probably best to be conservative and rebuild/upgrade webp there as well.

For CRAN packages for Windows you use, I would recommend you re-install them with the new Rtools (or as binaries from CRAN).

Re macOS, please check with Simon for the latest. But in principle it should be the same: once you have libwebp >= 1.3.2 (I see the recipes have been already updated, but it seems not the binary builds), you rebuild all packages (reinstall from source). The tricks above to find out WebP in a binary build (with symbols) would have to be adapted if one wanted to do it on macOS (or aarch64), but, likely packages would be using webp on all or no platform.