Inkscape possible domain compromise

Development Security
1

https://github.com/NixOS/nixpkgs/blob/c7623219fccf46b36370140d777ba61c85c9bb8d/pkgs/applications/graphics/inkscape/default.nix fetches from https://media.inkscape.org/dl/resources/file/inkscape-${version}.tar.xz, but visiting https://media.inkscape.org/dl/resources/file/ serves some sort of html page containing spam unrelated to Inkscape (excerpt below):

<!DOCTYPE html>
<html>

<head>
    <title>DAFTAR 1 AKUN UNTUK SEMUA JENIS GAME SLOT ONLINE</title>
    <meta charset="utf-8">

Is there a process to mark a package as possibly insecure without any existing CVE?

4 Likes
2

I think the source sha256 would prevent it from being downloaded in this case wouldn’t it? Unless the sha256 was obtained from a bad file.

2 Likes
3

Yep, the reason the package builds now is that the tar is cached in cache.nixos.org.

4 Likes
4

was inkscape’s site hacked? If that is true - is there some official news on that? What else is compromised in that case?

judging from the text it does seem to be related to some shady “slot machine” apk …

5

My concern is that there is a PR to bump version (inkscape: 1.2.2 -> 1.3, lib2geom: 1.2.2 -> 1.3 by leiserfg · Pull Request #245431 · NixOS/nixpkgs · GitHub), and I don’t know how we establish that this is “safe” code, as even the GitLab release (Releases · Inkscape / inkscape · GitLab) points back to the Inkscape domain (see the link “tarball from Inkscape website” which they consider to be the actual release).

The tarball does at least match the sha256 checksum posted on GitLab, so maybe this concern is superfluous, but I figured better report it than not.

3 Likes
6

Reporting is great, but I rather think it should be done upstream in this case.

7

That’s already been done, the question is what should be done in the meantime in nixpkgs. Do we simply wait on the version bump then until they make some public statement? And how do we handle if someone has overrides set and don’t know about this issue?

1 Like
8

I think that’s prudent.

What override would get them a potentially malicious update without spotting this themselves? If they rely on older versions they’re still protected by the hash, and if they deliberately upgrade to 1.3 they’re in the hands of upstream.

9

It seems like the version we have was secure? If that’s so, it’s secured by sha256 like others, so I don’t see any issue here. And in the meantime I expect upstream to resolve the situation.

10

Sorry about the index.html file, that was placed on our server a long while ago, and while the resource database entry was cleared out a long time ago, the file hung around on the file system and the fastly cache dutifully continued to mirror it.

I’ve cleared out the html file, reset the fastly cache (for both / and index.html) and done sanity checks on all the files, the web server and various intrusion possibilities which are all negative. This file was uploaded via the gallery uploads on the website which anyone could do. An index file now stands in the way to prevent it happening again.

If you want to verify the source tarball, I always recommend checking against the gpg signature uploaded to the releases app here Inkscape 1.3 - Source : Archive : xz tarball | Inkscape and verify it against the gitlab sha which you’ve already done for extra paranoia points.

Sorry about the issue.

  • Martin Owens, Volunteer Website Administrator and Inkscape programmer
16 Likes
11

Wasn’t aware of the gallery upload feature, glad it’s sorted!