Re: status of the gdm3 security update

[Antoine Beaupré]

Oh, and I forgot to mention the test packages are available here:

https://people.debian.org/~anarcat/debian/jessie-lts/

Cheers,

A.

status of the gdm3 security update

[Antoine Beaupré]

Hi!

After asking Markus the status of the gdm3 security upgrade for jessie,
he nicely offered me to take it over since he got stuck.

Using his patches, however, I wasn't able to reproduce the
problems. Sure, it *looks* like gdm is "crashing", but I /think/ it's
actually doing what it's asked. The reproducer issues those two
commands:

display_path=$(dbus-send --system --dest=org.gnome.DisplayManager 
--type=method_call --print-reply=literal 
/org/gnome/DisplayManager/LocalDisplayFactory 
org.gnome.DisplayManager.LocalDisplayFactory.CreateTransientDisplay)
dbus-send --system --dest=org.gnome.DisplayManager --type=method_call 
$display_path org.gnome.DisplayManager.Display.GetId

ie. it's calling `CreateTransientDisplay`. I am not very familiar with
the gdm3 D-Bus API, but a quick search online seems to indicate this is
used to create a "transient" session, also known as "fast user
switching".

When running the patched gdm3 under Vagrant / VirtualBox, the reproducer
seems to "crash" the display - but what it's doing is actually trying to
create that secondary display. There is no actual segfault the Linux
kernel can detect, and an attached gdb process happily goes through
without detecting anything faulty.

I would therefore assert that the patch does what it's designed to do
and everything is actually good.

Just out of curiosity, I've actually tested the reproducer in Debian
buster, which is supposed to be fixed. It could be because I have an
exotic session (i3 window manager), but it doesn't work very well
either. The display seems to completely crash and return to some virtual
terminal. (Just for good measure, all volumes are maxed up as well,
bringing down my hearing a few more dBs. :p) But gdm3 doesn't segfault
and if I login with my regular user, my session actually returns
untouched.

So I think this flickering and reset is actually normal.

(One thing I *did* find in buster is that
gnome-session-check-accelerated segfaults during the procedure:

Aug 27 19:34:57 curie kernel: [446832.229288] gnome-session-c[28820]: segfault 
at 0 ip  sp 7fff2cd46d08 error 14 in 
gnome-session-check-accelerated
[5606b821b000+2000]
Aug 27 19:34:57 curie kernel: [446832.308946] gnome-session-c[28824]: segfault 
at 0 ip  sp 7fffcd6fb1b8 error 14 in 
gnome-session-check-accelerated
[5589f17d9000+2000]
Aug 27 19:34:57 curie gnome-session[28817]: gnome-session-binary[28817]: 
WARNING: software acceleration check failed: Le processus fils a été tué par le 
signal 11
Aug 27 19:34:57 curie gnome-session-binary[28817]: WARNING: software 
acceleration check failed: Le processus fils a été tué par le signal 11

This is likely an unrelated problem, however, so I am ignoring that.)

So long story short: apo, your patches were fine! Should I upload the
result or do you want to do the honors?

If I got no reply tomorrow, I'll complete the DLA.

Thanks for the hard work!

A.

-- 
In a world where Henry Kissinger wins the Nobel Peace Prize,
there is no need for satire.
- Tom Lehrer

[SECURITY] [DLA 1479-1] twitter-bootstrap3 security update

[Antoine Beaupré]

Package: twitter-bootstrap3
Version: 3.2.0+dfsg-1+deb7u1
CVE ID : CVE-2018-14040
Debian Bug : 907414

The Bootstrap framework was found to have cross-site scripting
vulnerabilities in the "collapse" plugin.

For Debian 8 "Jessie", this problem has been fixed in version
3.2.0+dfsg-1+deb7u1.

We recommend that you upgrade your twitter-bootstrap3 packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS


signature.asc
Description: PGP signature

Re: Missing dependency on latest jessie-security release of linux-image-4.9-amd64

[Ben Hutchings]

On Mon, 2018-08-27 at 16:23 +0200, Shaun Bugler - Hetzner (Pty) Ltd wrote:
> Hello, we have shifted a number of servers using linux-image-4.9-amd64 
> from backports to the jessie-security release, with great success. Today 
> however, we see the package was bumped to 4.9+80+deb9u6~deb8u1, which 
> has a dependency on:
[...]
> This doesn't seem to be available on the jessie security mirrors yet 
> (linux-image-4.9.0-0.bpo.7-amd64 is still available), was this an 
> oversight and being fixed or have we made a mistake in out apt 
> configuration?

Unlike most uploads for LTS, this update of the linux source package
requires approval by the FTP team.  This should be resolved soon.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS teams


signature.asc
Description: This is a digitally signed message part

Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042

[Antoine Beaupré]

On 2018-08-08 17:35:52, Brian May wrote:
> If I got this right, we cannot use $(xyz) unless the value of xyz is
> trusted. Otherwise executing $(xyz) can result in the execution of code
> if xyz is something like "". This
> happens immediately, and even if you don't use the return value.
>
>
> I believe this fixes CVE-2018-14040 in Jessie:
>
> --- twitter-bootstrap-2.0.2+dfsg.orig/js/bootstrap-collapse.js
> +++ twitter-bootstrap-2.0.2+dfsg/js/bootstrap-collapse.js
> @@ -26,7 +26,7 @@
>  this.options = $.extend({}, $.fn.collapse.defaults, options)
>  
>  if (this.options["parent"]) {
> -  this.$parent = $(this.options["parent"])
> +  this.$parent = $(document.querySelector(this.options["parent"]))
>  }
>  
>  this.options.toggle && this.toggle()
>
>
> I think an alternative option here would be to replace $(xyz) with
> $(document).find(xyz) - as used in the upstream patch for
> CVE-2018-14042.

I am a bit puzzled as to how this attack works, but I'm ready to accept
that as yet another jQuery excentricity. :)

> CVE-2018-14041 / CVE-2018-14042 both refer to code that I cannot find in
> Jessie, hence I do not think they apply.

However, when trying to reproduce this online, I am failing to do so
with the version numbers matching those in Debian. Here are "pastebins"
which actually run the XSS with various versions, as provided in one of
the upstream bug reports (CVE-2018-14042):

https://github.com/twbs/bootstrap/issues/26628

The original, with 4.1.1:

https://jsbin.com/bimipayoda/edit?html,output

The same, with 3.3.7 (stretch, sid):

https://jsbin.com/nakisuhuso/edit?html,output

3.2.0 (jessie):

https://jsbin.com/tafejagene/edit?html,output

2.0.2 (jessie, stretch, sid):

https://jsbin.com/zapefecije/edit?html,output

Only the 4.1.1 codebase triggers the mouse-over XSS when running in
Firefox 60 or Chromium 68. So I can confirm that both CVE-2018-14041 and
CVE-2018-14042 a n/a in jessie and have marked them as such in the
tracker.

In my tests, only CVE-2018-14040 actually triggers a XSS, and only with
3.2.0. So I've marked 2.x N/A there as well..

> Looking at the code I do see a number of other references to $(xyz)
> where xyz is potentially untrusted, so simply applying the above patch
> may not be sufficient to fixing the problem. e.g. in
> js/bootstrap-scrollspy.js I see:
>
> var href = $(this).attr('href')   
>
> return /^#\w/.test(href) && $(href).length ? href : null  
>
>
> While this one might be obvious, there any many others that are not so
> clear. So I am not sure if I should fix only the instances fixed by
> these CVEs or search for everything I can find.

I would focus on those issues for now. CVEs have been pretty
systematically assigned and auditing the entire bootstrap codebase does
not seem realistic to me. And if we do, it would mean going into another
round of CVE assigment and upstream communication.

It might be worth, however, pinpointing that fact upstream, which I have
done here:

https://github.com/twbs/bootstrap/issues/26628#issuecomment-416282154

I've also posted in the other issues to validate the above claims.

In the meantime, I'll see if I can issue a patch for CVE-2018-14040
directly.

Sounds good?

A.

-- 
Pour marcher au pas d'une musique militaire, il n'y a pas besoin de
cerveau, une moelle épinière suffit.
- Albert Einstein

Re: tiff / CVE-2018-15209

[Antoine Beaupré]

On 2018-08-14 17:27:29, Brian May wrote:
> I have been trying to reproduce this bug (buffer overflow), but instead
> I get increasing memory usage until my computer crashes. With versions
> from Jessie, Stretch, and Sid. So maybe another security issue?
>
> I note that CVE-2017-11613 and CVE-2018-5784 can use unbounded
> memory. However these are marked as fixed everywhere but Stretch.
>
> As far as I can tell, the relevant code is:
>
> uint64* newcounts;
>
> ...
>
> newcounts = (uint64*) _TIFFCheckMalloc(tif, nstrips, sizeof (uint64),
> "for chopped \"StripByteCounts\" array");
>
> ...
>
> for (strip = 0; strip < nstrips; strip++) {
> ...
> newcounts[strip] = stripbytes;
> ...
> }
>
> However, I cannot see how this could cause a buffer overflow
> condition. We appear to allocate nstrips uint64, and then use nstrips
> uint64.

I can't reproduce this either in a jessie VM:

[...]
ii  libtiff-tools4.0.3-12.3+deb8u6   amd64  
 TIFF manipulation and conversion tools
ii  libtiff5:amd64   4.0.3-12.3+deb8u6   amd64  
 Tag Image File Format (TIFF) library
vagrant@jessie:~$ valgrind tiff2pdf poc1
==17408== Memcheck, a memory error detector
==17408== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17408== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==17408== Command: tiff2pdf poc1
==17408== 
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not 
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 65046 (0xfe16) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "Software"; tag ignored.
TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and 
ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as 
ExtraSamples..
TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and 
calculating from imagelength.
II*TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not 
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 65046 (0xfe16) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "Software"; tag ignored.
TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and 
ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as 
ExtraSamples..
TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and 
calculating from imagelength.
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not 
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 65046 (0xfe16) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "Software"; tag ignored.
TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and 
ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as 
ExtraSamples..
TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and 
calculating from imagelength.
%PDF-1.1 
%âãÏÓ
1 0 obj
<< 
/Type /Catalog 
/Pages 3 0 R 
>>
endobj
2 0 obj
<< 
/CreationDate (D:20180827145928)
/ModDate (D:20180827145928)
/Producer (libtiff / tiff2pdf - 20120922)
/Title (miniswhite-1c-1b.tiff)
>> 
endobj
3 0 obj
<< 
/Type /Pages 
/Kids [ 4 0 R ] 
/Count 1 
>> 
endobj
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not 
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 65046 (0xfe16) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "Software"; tag ignored.
TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and 
ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as 
ExtraSamples..
TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and 
calculating from imagelength.
tiff2pdf: No support for poc1 with 254 samples per pixel.
tiff2pdf: An error occurred creating output PDF file.
==17408== 
==17408== HEAP SUMMARY:
==17408== in use at exit: 0 bytes in 0 blocks
==17408==   total heap usage: 106 allocs, 106 frees, 35,811 bytes allocated
==17408== 
==17408== All heap blocks were freed -- no leaks are possible
==17408== 
==17408== For counts of detected and suppressed errors, rerun with: -v
==17408== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Now, this could be because it's valgrind and not ASAN. But still - if
compiling with ASAN triggers the bug, I fail to see how this affects us:
our package is *not* compiled with it, and, as such, doesn't
misbehave. But just for the fun of it, I *did* try to recompile the
package with ASAN, as per:

https://wiki.debian.org/LTS/Development/Asan

And I still can't trigger the bug.

For what it's worth, the original bug report mentions Ubuntu 16.04 and
v4.0.9, compiled with clang:

Missing dependency on latest jessie-security release of linux-image-4.9-amd64

[Shaun Bugler - Hetzner (Pty) Ltd]

Hello, we have shifted a number of servers using linux-image-4.9-amd64 
from backports to the jessie-security release, with great success. Today 
however, we see the package was bumped to 4.9+80+deb9u6~deb8u1, which 
has a dependency on:


dedi # aptitude show linux-image-4.9-amd64
Package: linux-image-4.9-amd64
New: yes
State: not installed
Version: 4.9+80+deb9u6~deb8u1
Priority: optional
Section: kernel
Maintainer: Debian Kernel Team 
Architecture: amd64
Uncompressed Size: 39.9 k
Depends: linux-image-4.9.0-0.bpo.8-amd64
Provides: linux-latest-modules-4.9.0-0.bpo.8-amd64

dedi # apt-cache policy linux-image-4.9.0-0.bpo.8-amd64
linux-image-4.9.0-0.bpo.8-amd64:
  Installed: (none)
  Candidate: (none)
  Version table:
dedi # apt-cache policy linux-image-4.9.0-0.bpo.7-amd64
linux-image-4.9.0-0.bpo.7-amd64:
  Installed: 4.9.110-3+deb9u2~deb8u1
  Candidate: 4.9.110-3+deb9u2~deb8u1
  Version table:
 *** 4.9.110-3+deb9u2~deb8u1 0
    990 http://security.debian.org/ jessie/updates/main amd64 Packages

This doesn't seem to be available on the jessie security mirrors yet 
(linux-image-4.9.0-0.bpo.7-amd64 is still available), was this an 
oversight and being fixed or have we made a mistake in out apt 
configuration?


TIA
--
Kind Regards,

Shaun Bugler
System Administrator
Hetzner (Pty) Ltd

SA Contact Centre: 0861 0861 08
International: +27 21 970 2000



Website: hetzner.co.za 
Disclaimer: hetzner.co.za/email-disclaimer 

[SECURITY] [DLA 1476-1] dropbear security update

[Holger Levsen]

Package: dropbear
Version: 2014.65-1+deb8u3
CVE ID : CVE-2018-15599
Debian Bug : 906890

A vulnerability in dropbear, a lightweight SSH2 server and client, making it
possible to guess valid usernames has been found:

CVE-2018-15599:

The recv_msg_userauth_request function in svr-auth.c in is prone
to a user enumeration vulnerability, similar to CVE-2018-15473 in OpenSSH.

For Debian 8 "Jessie", this problem has been fixed in version
2014.65-1+deb8u3.

We recommend that you upgrade your dropbear packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS


signature.asc
Description: PGP signature