[conspire] Security holes fixed in SVG, CUPS

[Rick Moen]

Quoting Edward Mokurai Cherlin (mokurai at sugarlabs.org):

> Debian and thus Ubuntu have sent out security patches this week for
> ways to execute arbitrary code in SVG interpretation and in CUPS
> printing. 


This is a gross exaggeration.  The SVG vulnerability is in librsvg,
another piece of spaghetti code from the GNOME Project.  Sauli Pahlman's
bug report said:

  eg/librsvg crashes when attempting to call NULL while opening the
  attached reproducer. Marking initially as vuln since i did not check
  whether the call address can be changed to something else than just
  NULL.

More at:  https://bugs.launchpad.net/ubuntu/+source/librsvg/+bug/825497


Being able to feed public data to a badly written lib and make it segfault
is obviously A Bad Thing and _could theoretically, eventually_ be coaxed
into doing something other than causing a graphics viewer to fall over,
but the current news is _nothing_ like 'ways to execute arbitrary code'.

The two bugs against CUPS are a similar story:  

1.  A fuzzed and LZW-compressed GIF triggers buffer overflow in
gif_read_lzw() in filter/image-gif.c, leading to heap corruption.
Submitter says 'This should not have any bad security implications for
CUPS beyond filter crash, as this keeps looping until some unmapped
memory is hit, without trying to use corrupted memory.  I'm tagging this
as security so you can review and decide how you want to handle this.'

http://cups.org/str.php?L3867

2.  A similar malformed GIF can cause that same routine to do buffer
over-read (which is a bug with potential security implications, but, in
brief testing, couldn't even be induced to crash the print filter.

http://cups.org/str.php?L3869


I've been a bit wary of code parsing SVG files from public data, because
it's new and because SVG is an insanely complex image format.  However, 
(1) you grossly exaggerate the current problem, and also (2) eschewing
cruddy GNOME software avoids even that much completely.

> However, the actual comedy section,
> 
> http://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html#s10.5
> 10.5 Genius/Paranoia Ideas — what you could do
> 
> seems to be beyond parody.
> 
> After a clean install and initial configuration, use the chattr
> program with the +i attribute to make files unmodifiable...Note that
> this strategy also prevents you from upgrading your system's
> packages...

If you insist on trying advanced ideas, expect to deal with obstacles.
That particular one's easy to deal with:  Just put a few
'DPkg::Pre-Invoke' commands into /etc/apt/apt.conf to remove the
immutable bit before package operations and a matching
'DPkg::Post-Invoke' line to put it back.  That's the way to have /tmp
non-executable or /usr read-only, etc., on .deb-based distributions.
Examples here:

http://www.debian-administration.org/articles/57

If you're not up for that, don't try to implement advanced notions of
system hardening, especially when the author warns you in advance about
an ancillary problem you'll have to solve.