tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Debian Bug report logs - #893806
tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Date: Thu, 22 Mar 2018 17:06:47 +0100

Source: tiff
Version: 4.0.9-1
Severity: important
Tags: security upstream
Forwarded: http://bugzilla.maptools.org/show_bug.cgi?id=2780

Hi,

the following vulnerability was published for tiff.

CVE-2018-8905[0]:
| In LibTIFF 4.0.9, a heap-based buffer overflow occurs in the function
| LZWDecodeCompat in tif_lzw.c via a crafted TIFF file, as demonstrated
| by tiff2ps.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-8905
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8905
[1] http://bugzilla.maptools.org/show_bug.cgi?id=2780

Please adjust the affected versions in the BTS as needed.  There is a
poc file attached to the upstream bug [1] which can be used to verify
a fix; the poc might not trigger but still the issue might be present
in other versions than 4.0.9. There is not upstream commit yet which
might help pinpointing then the issue.

Regards,
Salvatore

Message #10 received at 893806@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 893806@bugs.debian.org

Cc: debian-lts@lists.debian.org

Subject: Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Date: Sun, 15 Apr 2018 15:57:50 -0400

[Message part 1 (text/plain, inline)]

Hi,

I have successfully reproduced this issue in latest upstream master
branch and Buster but couldn't reproduce it neither in Wheezy nor in
Jessie or Stretch.

I am going to take a closer look, try to prepare a patch and declare
Wheezy, Jessie and Stretch unaffected if appropriate.

Regards,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 893806@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Hugo Lefeuvre <hle@debian.org>

Cc: 893806@bugs.debian.org

Subject: Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Date: Mon, 16 Apr 2018 10:06:47 +0200

Hi Hugo,

On Sun, Apr 15, 2018 at 03:57:50PM -0400, Hugo Lefeuvre wrote:
> Hi,
> 
> I have successfully reproduced this issue in latest upstream master
> branch and Buster but couldn't reproduce it neither in Wheezy nor in
> Jessie or Stretch.
> 
> I am going to take a closer look, try to prepare a patch and declare
> Wheezy, Jessie and Stretch unaffected if appropriate.

Please do it only mark as not-affected if you can confirm the
vulneable source/issue is not there/why the issue is introduced later,
but not only based on reproducibility. Just wanted to state that,
although I think given you want to have a closer look, that implies
already.

Thanks for your work,

Salvatore

Message #20 received at 893806@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: Salvatore Bonaccorso <carnil@debian.org>

Cc: 893806@bugs.debian.org

Subject: Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Date: Mon, 16 Apr 2018 20:01:06 -0400

[Message part 1 (text/plain, inline)]

Hi Salvatore,

> > I have successfully reproduced this issue in latest upstream master
> > branch and Buster but couldn't reproduce it neither in Wheezy nor in
> > Jessie or Stretch.
> > 
> > I am going to take a closer look, try to prepare a patch and declare
> > Wheezy, Jessie and Stretch unaffected if appropriate.
> 
> Please do it only mark as not-affected if you can confirm the
> vulneable source/issue is not there/why the issue is introduced later,
> but not only based on reproducibility. Just wanted to state that,
> although I think given you want to have a closer look, that implies
> already.

Sorry for my imprecision, with "take a closer look" I was meaning "I am
going to investigate the issue and, if applicable, prove that these
tiff versions are not affected by the issue". ;)

Cheers,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 893806@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 893806@bugs.debian.org

Cc: debian-lts@lists.debian.org

Subject: Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Date: Thu, 19 Apr 2018 22:46:06 -0400

[Message part 1 (text/plain, inline)]

Hi,

My current understanding of the problem (based on investigations on
latest master, but also valid for older versions):

The code_t string type is defined as a kind of chained list. Each entry
contains:

. a pointer to the next string entry
. a length field indicating the remaining length of the string

This length field includes the current entry.

. a value field containing the current string character
. the first character of the string

In the affected source code

> do {
>     *--tp = codep->value;
> } while ( (codep = codep->next) != NULL );

we read such a string and put the values into a buffer (in reverse order, but,
well, it doesn't matter).

Here we assume that the string always has the size it claims to have in its
length field.

But it's not the case with the reproducer. There is a list that claims to have
only one character but defines two, so we continue to read and write to the
buffer even if we are already OOB.

So now the question is: why is that happening ? Is it directly user input or is
coming from an earlier bug in the source code ?

Even if I can't reproduce the issue with the original reproducer, the
versions in Wheezy, Jessie and Stretch are likely to be affected because
the affected code is present.

I'm going to continue my investigations, try to prepare a poc for older
versions, prepare a patch for latest master and backport it to Wheezy
(+ Jessie & Stretch if needed).

Regards,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 893806@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 893806@bugs.debian.org

Cc: debian-lts@lists.debian.org

Subject: Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Date: Sun, 22 Apr 2018 17:50:48 -0400

[Message part 1 (text/plain, inline)]

It looks like this buffer overflow is the consequence of an earlier buffer
overflow in the GetNextCodeCompat macro:

> #define GetNextCodeCompat(sp, bp, code) {                       \
>          nextdata |= (unsigned long) *(bp)++ << nextbits;        \
>          nextbits += 8;                                          \
>          if (nextbits < nbits) {                                 \
>                  nextdata |= (unsigned long) *(bp)++ << nextbits;\
>                  nextbits += 8;                                  \
>          }                                                       \
>          code = (hcode_t)(nextdata & nbitsmask);                 \
>          nextdata >>= nbits;                                     \
>          nextbits -= nbits;                                      \
> }

The raw data buffer is read using the bp pointer without proper bound checking.
At some point, we start to read garbage, store it into the code variable which
is later used to create the codep. This invalid codep later triggers the second
overflow.

So now the question is: Why is this first buffer overflow happening ?

My guess is that the sample is declaring more strips than actually available, or
declares strips with incorrect size. I still have to check that however.

Regards,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 893806@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 893806@bugs.debian.org

Cc: debian-lts@lists.debian.org

Subject: Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Date: Mon, 30 Apr 2018 23:07:24 -0400

[Message part 1 (text/plain, inline)]

Hi,

> It looks like this buffer overflow is the consequence of an earlier buffer
> overflow in the GetNextCodeCompat macro:

Hum, that was not completely true. But I think I got it now.

The buggy sequence is:

1) Initialy oldcodep points to 0x632000001890.
   We get code 0x010c = 268, add it to the code table, print some stuff
   and read the next code.

2) The next code is 0x100, which is CLEAR_CODE, so we set free_entp to
   0x632000001820 (= sp->dec_codetab + CODE_FIRST).

   Then, we memset free_entp with a size of
     CSIZE - CODE_FIRST
   = (MAXCODE(BITS_MAX)+1024L)-258
   = (MAXCODE(9)+1024L)-258
   = ((1L<<(9))-1)+1024L-258 = 1277

   This means that everything between 0x632000001820 and 0x632000001D1D
   will be set to 0. Then we read the next code.

3) Next code is CLEAR_CODE, same as before, nothing changes.

4) Next code is 0x01d6. This is bad because it is too big for a first
   code. At this point we exit 0 without updating the decoder state.

5) Because we exit 0, TIFFReadScanline(in, buf, row, s) < 0 in
   tools/tiffcp.c is false and the whole process is repeated !

6) So, again, oldcodep initially points to 0x632000001890. BUT,
   remember, this area was set to 0 by 2) !

   So, well, we read the next code which is 0x010c and add it to the code
   table. This means that for our 0x010c code @codep, codep->next will
   point to the memset-ed area ! This means that codep->next->next == NULL.

7) Overflow, NULL pointer dereference, etc.

So, what is the solution ?

First, change

TIFFReadScanline(in, buf, row, s) < 0

in tools/tiffcp.c to

TIFFReadScanline(in, buf, row, s) <= 0

It is important to understand that 0 is also an error code here. Otherwise,
change error handling in tif_lzw to return negative numbers.

Then, there's maybe something to fix in tif_lzw, but I'm not quite sure
at the moment and I still have to check that.

Now that the issue is clear to me, I'll check the Wheezy code and try to
see why the issue isn't reproducible there.

Cheers,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 893806@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 893806@bugs.debian.org

Cc: debian-lts@lists.debian.org

Subject: Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Date: Wed, 2 May 2018 22:30:38 -0400

[Message part 1 (text/plain, inline)]

> So, what is the solution ?
> 
> First, change
> 
> TIFFReadScanline(in, buf, row, s) < 0
> 
> in tools/tiffcp.c to
> 
> TIFFReadScanline(in, buf, row, s) <= 0
> 
> It is important to understand that 0 is also an error code here. Otherwise,
> change error handling in tif_lzw to return negative numbers.

After taking a fresh look at it, this turns out to be a non solution
because TIFFReadScanline (the function between LZWDecodeCompat and
DECLAREcpFunc) converts 0 return codes to -1s.
 
> Then, there's maybe something to fix in tif_lzw, but I'm not quite sure
> at the moment and I still have to check that.

So, obviously the solution is in tif_lzw. Because of the ignore option,
we must understand the process of exiting not only as returning, but
most importantly as preparing the decoder for being called again with
the same corrupted memory state and the same buggy codes.

If we don't do that the next decoder call will stumble across the
corrupted memory and crash.

There are two things we have to handle: First, make sure the next
decoder call detects that it was previously interrupted and that the
oldcodep is invalid, so we avoid the crash.

Then, we have to be able to skip the buggy error code, because otherwise
we are going to run into an endless loop and we do not want that either.

I suggest to fix both issues via an additional flag in the decoder base
state. This flag would indicate the position where an invalid code can
be found.

Whenever this flag is set, we would fast forward to the next CODE_CLEAR
after the invalid code (according to my understanding of LZW, the whole
set of information between the corrupted code and the next CODE_CLEAR
may be corrupted or risky / hard to recover).

Concerning the Wheezy version, I have inspected the diffs and it is
still pretty unclear to me why the issue isn't reproducible because the
affected code it present. I'm still working on it.

Cheers,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #47 received at 893806@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 893806@bugs.debian.org

Subject: Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

Date: Sat, 12 May 2018 10:31:20 -0400

[Message part 1 (text/plain, inline)]

Well, upstream just published a fix for this issue.

This is not really what I wanted to do, but, my bad, I took too much
time to submit my fix. I'm probably going to prepare an LTS upload
for this patch, if needed I can also backport the fix to Jessie and
other versions.

Cheers,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #54 received at 893806-close@bugs.debian.org (full text, mbox, reply):

From: Laszlo Boszormenyi (GCS) <gcs@debian.org>

To: 893806-close@bugs.debian.org

Subject: Bug#893806: fixed in tiff 4.0.9-6

Date: Sun, 01 Jul 2018 21:21:01 +0000

Source: tiff
Source-Version: 4.0.9-6

We believe that the bug you reported is fixed in the latest version of
tiff, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 893806@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Laszlo Boszormenyi (GCS) <gcs@debian.org> (supplier of updated tiff package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sun, 01 Jul 2018 19:46:23 +0000
Source: tiff
Binary: libtiff5 libtiffxx5 libtiff5-dev libtiff-dev libtiff-tools libtiff-opengl libtiff-doc
Architecture: source amd64 all
Version: 4.0.9-6
Distribution: unstable
Urgency: high
Maintainer: Laszlo Boszormenyi (GCS) <gcs@debian.org>
Changed-By: Laszlo Boszormenyi (GCS) <gcs@debian.org>
Description:
 libtiff-dev - Tag Image File Format library (TIFF), development files, current
 libtiff-doc - TIFF manipulation and conversion documentation
 libtiff-opengl - TIFF manipulation and conversion tools
 libtiff-tools - TIFF manipulation and conversion tools
 libtiff5   - Tag Image File Format (TIFF) library
 libtiff5-dev - Tag Image File Format library (TIFF), development files
 libtiffxx5 - Tag Image File Format (TIFF) library -- C++ interface
Closes: 893806 898348
Changes:
 tiff (4.0.9-6) unstable; urgency=high
 .
   * Fix CVE-2018-8905: eap-based buffer overflow in LZWDecodeCompat()
     (closes: #893806).
   * Fix CVE-2018-10963: remote denial of service (closes: #898348).
Checksums-Sha1:
 81b18818f1320c27c3e09c9c55e4b24db957ee59 2184 tiff_4.0.9-6.dsc
 01cb0f32986d44622a7f5af6d596d5b4bece91f7 23684 tiff_4.0.9-6.debian.tar.xz
 3b1a55ba1ab15ce13879226bddfe6155ff32d4ea 96372 libtiff-dev_4.0.9-6_amd64.deb
 fc00cb195061521c5e8e69ba57117c5526276e39 403296 libtiff-doc_4.0.9-6_all.deb
 0ebcd77ce059ecd244e479a5d1d0c4094cf96363 13764 libtiff-opengl-dbgsym_4.0.9-6_amd64.deb
 38dbda0cebcc248b46b7a19a50658b3a8eae3309 104940 libtiff-opengl_4.0.9-6_amd64.deb
 a29d89e20e429184aa87ce5a68cd57f930239e3a 348212 libtiff-tools-dbgsym_4.0.9-6_amd64.deb
 740b294ae8a817836dd485f18b06e1330c0bbd3f 287080 libtiff-tools_4.0.9-6_amd64.deb
 ac2d0415b515dcc32b3e0e30a33238a7431d4de6 376832 libtiff5-dbgsym_4.0.9-6_amd64.deb
 e0cd10c04a2ef4108b528a3c4c98238cbdb2276e 367624 libtiff5-dev_4.0.9-6_amd64.deb
 290186af454e325c6fa91c35e8c9bffca4a8a4c9 245968 libtiff5_4.0.9-6_amd64.deb
 f0e5cf62a910e23c499346663e56af7e5184053e 21284 libtiffxx5-dbgsym_4.0.9-6_amd64.deb
 90beb0e54223387c87451c95e8ec7579d64a51ed 100092 libtiffxx5_4.0.9-6_amd64.deb
 fcca80bd5517cfbe179e8acc6b9a27c2345e1f06 12234 tiff_4.0.9-6_amd64.buildinfo
Checksums-Sha256:
 9200f8f74e28e99b46bc083ad7a253d38e4dd0838fe0355c473c409610b8b14e 2184 tiff_4.0.9-6.dsc
 4e145dcde596e0c406a9f482680f9ddd09bed61a0dc6d3ac7e4c77c8ae2dd383 23684 tiff_4.0.9-6.debian.tar.xz
 a0cbd2d798102712293abc410eb27835fe6e39bc11ab6cb088db3418e186cba1 96372 libtiff-dev_4.0.9-6_amd64.deb
 398c64aaac654cefa6abe7910fccbdd16cf5a09e8244d20f94eedc849a46c7a7 403296 libtiff-doc_4.0.9-6_all.deb
 6425e10ef610d46e79a0ee5c3db75e98858a3806bb0bc6f93f6849e3ec524af1 13764 libtiff-opengl-dbgsym_4.0.9-6_amd64.deb
 e1d4a44ff7c3cb9a9851345361f4f85894813255da2684ad06bc4cc4e9e6ffa3 104940 libtiff-opengl_4.0.9-6_amd64.deb
 0323bf86bdc35a28be2f62fd839b6b6ef4ec39934a2c11af2ecbe29ba8efad1a 348212 libtiff-tools-dbgsym_4.0.9-6_amd64.deb
 63999dec55c0e547c1b5478873be2427206e5d20d0484574f641988c4eab8268 287080 libtiff-tools_4.0.9-6_amd64.deb
 640c81bcd91cb0e45aaf3df7fa946e50856a1e8affb2d290b6429576e5506f7b 376832 libtiff5-dbgsym_4.0.9-6_amd64.deb
 05cfda1af6ce290b40495f39d1f82a22741ecd029126524319db8b819f24072d 367624 libtiff5-dev_4.0.9-6_amd64.deb
 75f55511749790c6c184b722485292e963a7d71922bfa7de496e0e96d347d668 245968 libtiff5_4.0.9-6_amd64.deb
 d6aa9a1731a51742d8c740149238f7a0301dfd1c3f678d49c02a8b6f7a1a8b00 21284 libtiffxx5-dbgsym_4.0.9-6_amd64.deb
 52694e9b853bf2bc19d73a42ed3aa55ccce7845ef3e48f2b619f998b06ef101c 100092 libtiffxx5_4.0.9-6_amd64.deb
 e312ca9b77c3bf478126b533d19be17b74d6c495ead0c8b3f99e888e581489d5 12234 tiff_4.0.9-6_amd64.buildinfo
Files:
 ef14e5221e1a221cc028aaf3a8a60f67 2184 libs optional tiff_4.0.9-6.dsc
 53e60381c0c7838fb766ce4f93887ce8 23684 libs optional tiff_4.0.9-6.debian.tar.xz
 db40836594b7bdbde7ebc50fb7ee50a6 96372 oldlibs optional libtiff-dev_4.0.9-6_amd64.deb
 2ac029d6f64727f199488584e3f6c7be 403296 doc optional libtiff-doc_4.0.9-6_all.deb
 46ebd544eece4850934d8f3a9de9c4e2 13764 debug optional libtiff-opengl-dbgsym_4.0.9-6_amd64.deb
 bddec8c2a2122930e8c48a18ed3cca05 104940 graphics optional libtiff-opengl_4.0.9-6_amd64.deb
 06713bde8891ffba63994ed96b7da604 348212 debug optional libtiff-tools-dbgsym_4.0.9-6_amd64.deb
 4709e343fd4570e271c5fb8e8c26006d 287080 graphics optional libtiff-tools_4.0.9-6_amd64.deb
 0acb1ca8eff66d81048a4b39be4466fc 376832 debug optional libtiff5-dbgsym_4.0.9-6_amd64.deb
 1f48f8dc202cc4b4821c38ad45bfa946 367624 libdevel optional libtiff5-dev_4.0.9-6_amd64.deb
 38a1e30f97d020caf7016993ba85b34a 245968 libs optional libtiff5_4.0.9-6_amd64.deb
 912111894b84ce5cfb6537c9734e476c 21284 debug optional libtiffxx5-dbgsym_4.0.9-6_amd64.deb
 ccdc2899e536eb94559ba69fab203e24 100092 libs optional libtiffxx5_4.0.9-6_amd64.deb
 78cf0a40a51962f811a671f1c252062f 12234 libs optional tiff_4.0.9-6_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEfYh9yLp7u6e4NeO63OMQ54ZMyL8FAls5P8cACgkQ3OMQ54ZM
yL9XWQ//ZFz8o1EqdVUBC+Tue5wpTN4d88phuk3mgVMAo1bFcA110SH2qF8tch/P
q+DcmKY36Wprqm3S6Ra6d85ovw2tDuqR1AvQwR7JKTuDwxkgoh/Sy945qazLGAuG
I0y3xh43litw2oYkarZNa6KXbq+BgSN3h78oUAOETW9edRfJqfqKYbjCw64gh8gG
gtfTMMHPiHXbmWHEWCIjP5YDsDVBPVQ/p7ffiD9ZdZIWsyFelvrL/qlOlFBl0/d/
YmmRcwo4+39D5AYnW14SFIfBB/WIyiYbYB8LYAUqgcFjcQmHAf0wlR8foyb/QCya
w0T451eHutuqkyZP2plFnwNogT78Ae+yjOtz53Lgw1SP9K1rlgPVguG3QQ3czhp1
q6gYiqESxyrBccsZWwPMkg3zJFeklL8Gxb/412U+yLnC7mt0AkT8ELbi+BbScIDa
4NP8Kw77/UO7+pXb6LUrnh4RxO8GfQDqyGniE3SUdfHsjVTz8SBy9Mo7ws8URXSU
ttSYf+6ngIAdKe8s3MSLCtU3uRnD3vCdW/lOvOW5hkih/TIGK3mv095N4R4YYkHY
5L2K8wPGE4GFqxsoLBjro6+rWNcdujHlc4r4sd27ieBibxlQF9tSduVZ8vWaH3Ep
N7K4xiNpLT0SLyrJY0IkS8ll92DlggLAipxdxsXhvmevVSUrQAs=
=KTsh
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.