Debian Bug report logs - #286681
[CAN-2004-1000] [lib/Lab] Insecurely removes files after lab failed to be created

version graph

Package: lintian; Maintainer for lintian is Debian Lintian Maintainers <lintian-maint@debian.org>; Source for lintian is src:lintian.

Reported by: Javier Fernández-Sanguino Peña <jfs@computer.org>

Date: Sun, 19 Dec 2004 23:03:04 UTC

Severity: grave

Tags: confirmed, sarge, security

Found in version 1.18.1.1-3

Fixed in version lintian/1.23.6

Done: Steve Langasek <vorlon@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Javier Fernández-Sanguino Peña <jfs@computer.org>:
New Bug report received and forwarded. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

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

From: Javier Fernández-Sanguino Peña <jfs@computer.org>
To: submit@bugs.debian.org
Subject: lintian: Insecure temporary directory usage
Date: Sun, 19 Dec 2004 23:58:32 +0100
[Message part 1 (text/plain, inline)]
Package: lintian
Version: 1.18.1.1-3
Priority: important
Tags: security

The lintian script does not protect itself from temporary directory
attacks since it creates the labs in an insecure manner (the process PID
is not suffient to avoid and attack) and does not check
if the temporary dir it uses exists before using them. Actually, the
LIB interface happily uses any directory if it's already available so
a symlink attack can be devised through the standard contents of
a lab if the user has not defined LINTIAN_LAB to go to a proper 
(safe) location instead of to /tmp/ (i.e. TMPDIR has not been defined)

The attached patch is an attempt to fix this behaviour using the File::Temp
library. It does have a caveat empor, with the patch below lintian 
will produce the following warnings (due to -w), but I'm unable to
remove them myself:

---------------------------------------------------
Subroutine Pipeline::O_CREAT redefined at /usr/share/perl/5.8/Exporter.pm line 65.  at /usr/lib/perl/5.8/POSIX.pm line 19
Subroutine Pipeline::O_EXCL redefined at /usr/share/perl/5.8/Exporter.pm line 65.  at /usr/lib/perl/5.8/POSIX.pm line 19
Subroutine Pipeline::O_RDWR redefined at /usr/share/perl/5.8/Exporter.pm line 65.  at /usr/lib/perl/5.8/POSIX.pm line 19
---------------------------------------------------

Regards

Javier

PS: I initially reported this to the security team back in June,
but have not found time to follow up on this issue until today.
Security team, please check
Resent-Message-ID: <20040624124521.GA10101@dat.etsit.upm.es>

[lintian.diff (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

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

From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: Javier Fern?ndez-Sanguino Pe?a <jfs@computer.org>, 286379@bugs.debian.org
Subject: Re: Bug#286379: lintian: Insecure temporary directory usage
Date: Mon, 20 Dec 2004 00:29:09 +0100
On Sun, Dec 19, 2004 at 11:58:32PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> Package: lintian
> Version: 1.18.1.1-3
^^^^
There has never been a lintian version even remotely like this one...

> The lintian script does not protect itself from temporary directory
> attacks since it creates the labs in an insecure manner (the process PID
> is not suffient to avoid and attack) and does not check
> if the temporary dir it uses exists before using them. Actually, the
> LIB interface happily uses any directory if it's already available so
> a symlink attack can be devised through the standard contents of
> a lab if the user has not defined LINTIAN_LAB to go to a proper 
> (safe) location instead of to /tmp/ (i.e. TMPDIR has not been defined)

I noticed this before, but at that time didn't think it was a security
issue. Directory creation would simply fail if that name is already
taken, and the cleanup afterwards is harmless. If the name is not yet
taken, no issue.

However, when re-reading, I see that this assassment was a misreading of
the sources. svn blame yields back to revision 1 (hm, I still didn't
import the old cvs stuff...), so I don't know how it's possible I
overlooked this.

FWIW, maintainers of lintian can always be mailed privately about
security issues, so that this could have been fixed in a timely matter.
I never got any mail about this issue.

--Jeroen

-- 
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Florian Weimer <fw@deneb.enyo.de>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

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

From: Florian Weimer <fw@deneb.enyo.de>
To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
Cc: 286379@bugs.debian.org, Javier Fern?ndez-Sanguino Pe?a <jfs@computer.org>
Subject: Re: Bug#286379: lintian: Insecure temporary directory usage
Date: Mon, 20 Dec 2004 00:47:52 +0100
* Jeroen van Wolffelaar:

> FWIW, maintainers of lintian can always be mailed privately about
> security issues, so that this could have been fixed in a timely matter.
> I never got any mail about this issue.

Debian guidelines discourage contacting the maintainers with security
holes:

<http://www.debian.org/security/faq#care>

(These instructions are somehwat inconsistent.  For sid, you are
supposed to work directly with upstream and/or packages maintainers
AFAIK because the security team does not really have the resources to
deal with sid, too.)

OTOH, the Social Contract does not really propagate the secret filing
of security bugs.  (Yeah, I know, we have some disagreement, no need
to rehash the old discussion.)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

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

From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>, 286379@bugs.debian.org
Cc: Javier Fern?ndez-Sanguino Pe?a <jfs@computer.org>
Subject: Re: Bug#286379: lintian: Insecure temporary directory usage
Date: Mon, 20 Dec 2004 01:24:03 +0100
On Mon, Dec 20, 2004 at 12:29:09AM +0100, Jeroen van Wolffelaar wrote:
> On Sun, Dec 19, 2004 at 11:58:32PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> > The lintian script does not protect itself from temporary directory
> > attacks since it creates the labs in an insecure manner (the process PID
> > is not suffient to avoid and attack) and does not check
> > if the temporary dir it uses exists before using them. Actually, the
> > LIB interface happily uses any directory if it's already available so
> > a symlink attack can be devised through the standard contents of
> > a lab if the user has not defined LINTIAN_LAB to go to a proper 
> > (safe) location instead of to /tmp/ (i.e. TMPDIR has not been defined)
> 
> I noticed this before, but at that time didn't think it was a security
> issue.

Argh, after looking again, I still stand by my initial assassment, I was
misleaded by the theory that the logic was bogus. The key point is:

| if (not -d "$LINTIAN_LAB" or ($lab_mode eq 'temporary'))
|     mkdir($LINTIAN_LAB,0777) or fail("cannot create lab directory $LINTIAN_LAB")

And, this is correct. If $lab_mode is not temporarily, a lab location
was specifically given to lintian, and we should assume that the invoker
of lintian in that case knows what he does. In all other cases, i.e.,
lab_mode equals temporary, the condition in the if is true (note the
'or'), and the lab dir is unconditionally tried to be made, which fails
if it already exists.

In woody's END, the lab is removed even though it might not have been
created, however. Since it only removed
$LINTIAN_LAB/{binary,source,info}, the impact is limited (one can only
have directories/files removed that are named either of those 3 names),
and it's nontrivial to exploit (the time between the mkdir failing and
remove_lab executing is extremely small), and you need to have your
symlink in place between those two moments), but it is indeed a bug.
It's completely different issue than in the bugreport though.

--Jeroen

-- 
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

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

From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: team@security.debian.org
Cc: 286379@bugs.debian.org
Subject: Lintian insecure removal bug (#286379)
Date: Mon, 20 Dec 2004 20:31:26 +0100
Should we prepare a security upload for woody for this issue? Do you
agree or not that this is a security bug in woody that should be fixed?

It involves a symlink attack where lintian is fooled into cleaning up
its not-self-created temporary lab in /tmp. Files/directories/whatever
called either of "binary", "source" or "info" run the risk of being
removed by the user invoking lintian. The code boils down to:

if not mkdir /tmp/lintian-lab.$$ {
	# a few light commands
	if -d /tmp/lintian-lab.$$ and -d /tmp/lintian-lab.$$/binary {
		rm -rf /tmp/lintian-lab.$$/{binary,source,info}
		# and udeb, in the case of sarge/sid
	}
}

So an attack would be:
- create a real directory with a conflicting name
- just before the rm -rf is invoked, but after the -d test on the lab
  dir, replace the dir with a symlink to the directory that contains
  'binary', 'source' or 'info' and you want to have removed. I'm
  assuming rm -rf is safe against symlink attacks during its execution.

--Jeroen

----- Forwarded message from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> -----

Subject: Bug#286379: lintian: Insecure temporary directory usage
Reply-To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>,
	286379@bugs.debian.org
Resent-From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
Date: Mon, 20 Dec 2004 01:24:03 +0100
To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>,
	286379@bugs.debian.org
Cc: Javier Fern?ndez-Sanguino Pe?a <jfs@computer.org>
From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>

In woody's END, the lab is removed even though it might not have been
created, however. Since it only removes
$LINTIAN_LAB/{binary,source,info}, the impact is limited (one can only
have directories/files removed that are named either of those 3 names),
and it's nontrivial to exploit (the time between the mkdir failing and
remove_lab executing is extremely small), and you need to have your
symlink in place between those two moments), but it is indeed a bug.
It's completely different issue than in the bugreport though.

----- End forwarded message -----

-- 
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Martin Schulze <joey@infodrom.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

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

From: Martin Schulze <joey@infodrom.org>
To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
Cc: team@security.debian.org, 286379@bugs.debian.org
Subject: Re: Lintian insecure removal bug (#286379)
Date: Mon, 20 Dec 2004 20:43:53 +0100
Jeroen van Wolffelaar wrote:
> Should we prepare a security upload for woody for this issue? Do you
> agree or not that this is a security bug in woody that should be fixed?

I wonder if this isn't that low that it wouldn't require an update.
Who would remove lintian?  It needs to be installed manually and
will only be done manually by the admin after there is some need.

Regards,

	Joey

-- 
Let's call it an accidental feature.  -- Larry Wall

Please always Cc to me when replying to me on the lists.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

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

From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: Martin Schulze <joey@infodrom.org>
Cc: team@security.debian.org, 286379@bugs.debian.org
Subject: Re: Lintian insecure removal bug (#286379)
Date: Mon, 20 Dec 2004 20:57:01 +0100
On Mon, Dec 20, 2004 at 08:43:53PM +0100, Martin Schulze wrote:
> Jeroen van Wolffelaar wrote:
> > Should we prepare a security upload for woody for this issue? Do you
> > agree or not that this is a security bug in woody that should be fixed?
> 
> I wonder if this isn't that low that it wouldn't require an update.
> Who would remove lintian?  It needs to be installed manually and
> will only be done manually by the admin after there is some need.

I'm sorry, but I think you've misunderstood. The bug happens on
each execution of lintian (as a regular user normally), by default. The
lintian lab is setup and removed (<- bug) every invocation unless the
admin or user has set up a permanent lab, which is rare.

--Jeroen

-- 
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Javier Fernández-Sanguino Peña <jfs@computer.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

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

From: Javier Fernández-Sanguino Peña <jfs@computer.org>
To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
Cc: 286379@bugs.debian.org
Subject: Re: Bug#286379: lintian: Insecure temporary directory usage
Date: Tue, 21 Dec 2004 01:18:27 +0100
[Message part 1 (text/plain, inline)]
On Mon, Dec 20, 2004 at 01:24:03AM +0100, Jeroen van Wolffelaar wrote:
> 
> Argh, after looking again, I still stand by my initial assassment, I was
> misleaded by the theory that the logic was bogus. The key point is:
> 
> | if (not -d "$LINTIAN_LAB" or ($lab_mode eq 'temporary'))
> |     mkdir($LINTIAN_LAB,0777) or fail("cannot create lab directory $LINTIAN_LAB")
> 

> And, this is correct. If $lab_mode is not temporarily, a lab location
> was specifically given to lintian, and we should assume that the invoker
> of lintian in that case knows what he does. In all other cases, i.e.,
> lab_mode equals temporary, the condition in the if is true (note the
> 'or'), and the lab dir is unconditionally tried to be made, which fails
> if it already exists.

_However_ if it does not exist the lab is created, if the user has a 
"insecure" umask (002) you will end up being prey to symlink attacks due 
to a race condition check this (when setting up the lab):

        _touch("$LINTIAN_LAB/info/binary-packages")
                or fail("cannot create binary package list");
        _touch("$LINTIAN_LAB/info/source-packages")
                or fail("cannot create source package list");
        _touch("$LINTIAN_LAB/info/udeb-packages")
                or fail("cannot create udeb package list");

And 

sub _touch {
    open(T,">$_[0]") or return 0;
    close(T) or return 0;

    return 1;
}


Image the following race condition:

1.- User A in group B with umask 002 runs 'lintian package.deb'
2.- The following structure is created:
[first steps of Lab::setup]
/tmp/lintian-lab.8624/
|-- binary
|-- info
|-- source
`-- udeb

3.- User R in group B symlinks the following files to files that belong to 
user A:
|-- info
|   |-- binary-packages
|   |-- source-packages
|   `-- udeb-packages

4.- [final steps of Lab::setup]
	_touch is executed and the files that A's files where B
symlinked the previous files to are emptied because of the race condition.

So what you have here is a race condition because of temporary 
files. Granted, this only happens when you have a lax umask, but it could 
be prevented either by using a proper function to create temporary 
directories (tempdir() will set them up mode 700) or by restricting the 
umask to 0700 when creating the temporary directories in Lab::setup().

I did not properly assess the issue in the initial report, but I still 
believe that Lintian has a security bug which introduces a hole under some 
conditions and that could be easily fixed.

Regards

Javier

PS: Yes, version was 1.23.3, blame it on opening up multiple bug reports at 
1 am

PPS: I already informed the security team and was told to follow this bugs 
up on the BTS
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

Message #45 received at 286379@bugs.debian.org (full text, mbox):

From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: Javier Fern?ndez-Sanguino Pe?a <jfs@computer.org>
Cc: 286379@bugs.debian.org
Subject: Re: Bug#286379: lintian: Insecure temporary directory usage
Date: Tue, 21 Dec 2004 03:43:19 +0100
On Tue, Dec 21, 2004 at 01:18:27AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> _However_ if it does not exist the lab is created, if the user has a 
> "insecure" umask (002) you will end up being prey to symlink attacks due 
> to a race condition check this (when setting up the lab):

If you have a umask of 002 you can expect people of the same group to
do nasty things with you... Isn't that the whole point of umask? If I
set umask of 0, I'll be vulnerable too, to a whole lot of issues.
 
> So what you have here is a race condition because of temporary 
> files. Granted, this only happens when you have a lax umask, but it could 
> be prevented either by using a proper function to create temporary 
> directories (tempdir() will set them up mode 700) or by restricting the 
> umask to 0700 when creating the temporary directories in Lab::setup().

No need to extra-restrict IMHO, I don't think one should restrict
permissions above what's needed according to the user. On systems where
I have a 02 umask, I *intent* for users of the same group to be able
to write to all the stuf I do. If that's not intended, well, don't have
a 02 umask.
 
> I did not properly assess the issue in the initial report, but I still
> believe that Lintian has a security bug which introduces a hole under
> some conditions and that could be easily fixed.

I, and with me one other lintian maintainer I consulted, still don't
think this is a security bug (the different issue w.r.t. removing files
however still stands).
 
> PS: Yes, version was 1.23.3, blame it on opening up multiple bug reports at 
> 1 am

Thought something like that :), n/p.

--Jeroen

-- 
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Martin Schulze <joey@infodrom.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

Message #50 received at 286379@bugs.debian.org (full text, mbox):

From: Martin Schulze <joey@infodrom.org>
To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
Cc: team@security.debian.org, 286379@bugs.debian.org
Subject: Re: Lintian insecure removal bug (#286379)
Date: Tue, 21 Dec 2004 05:39:29 +0100
Jeroen van Wolffelaar wrote:
> On Mon, Dec 20, 2004 at 08:43:53PM +0100, Martin Schulze wrote:
> > Jeroen van Wolffelaar wrote:
> > > Should we prepare a security upload for woody for this issue? Do you
> > > agree or not that this is a security bug in woody that should be fixed?
> > 
> > I wonder if this isn't that low that it wouldn't require an update.
> > Who would remove lintian?  It needs to be installed manually and
> > will only be done manually by the admin after there is some need.
> 
> I'm sorry, but I think you've misunderstood. The bug happens on
> each execution of lintian (as a regular user normally), by default. The
> lintian lab is setup and removed (<- bug) every invocation unless the
> admin or user has set up a permanent lab, which is rare.

Ah.  Then I did not understand you inded.  I'd be glad for a fixed
package sent to the security team.

Regards,

	Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Martin Schulze <joey@infodrom.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

Message #55 received at 286379@bugs.debian.org (full text, mbox):

From: Martin Schulze <joey@infodrom.org>
To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
Cc: Debian Security Team <team@security.debian.org>, 286379@bugs.debian.org
Subject: Re: Lintian insecure removal bug (#286379)
Date: Tue, 21 Dec 2004 05:40:29 +0100
Jeroen van Wolffelaar wrote:
> On Mon, Dec 20, 2004 at 08:43:53PM +0100, Martin Schulze wrote:
> > Jeroen van Wolffelaar wrote:
> > > Should we prepare a security upload for woody for this issue? Do you
> > > agree or not that this is a security bug in woody that should be fixed?
> > 
> > I wonder if this isn't that low that it wouldn't require an update.
> > Who would remove lintian?  It needs to be installed manually and
> > will only be done manually by the admin after there is some need.
> 
> I'm sorry, but I think you've misunderstood. The bug happens on
> each execution of lintian (as a regular user normally), by default. The
> lintian lab is setup and removed (<- bug) every invocation unless the
> admin or user has set up a permanent lab, which is rare.

Please use CAN-2004-1000 for this problem.

Regards,

	Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Javier Fernández-Sanguino Peña <jfs@computer.org>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

Message #60 received at 286379@bugs.debian.org (full text, mbox):

From: Javier Fernández-Sanguino Peña <jfs@computer.org>
To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
Cc: 286379@bugs.debian.org
Subject: Re: Bug#286379: lintian: Insecure temporary directory usage
Date: Tue, 21 Dec 2004 09:03:34 +0100
[Message part 1 (text/plain, inline)]
On Tue, Dec 21, 2004 at 03:43:19AM +0100, Jeroen van Wolffelaar wrote:
> On Tue, Dec 21, 2004 at 01:18:27AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> > _However_ if it does not exist the lab is created, if the user has a 
> > "insecure" umask (002) you will end up being prey to symlink attacks due 
> > to a race condition check this (when setting up the lab):
> 
> If you have a umask of 002 you can expect people of the same group to
> do nasty things with you... Isn't that the whole point of umask? If I
> set umask of 0, I'll be vulnerable too, to a whole lot of issues.

The main point here is predictability. Even if I have a 002 umask, rogue 
users from my same group cannot target symlink attacks against me (against 
files that might be mode 700 for example) if they cannot foresee what files 
I will create in the future. Temporary stuff which is predictable can, 
however, be used for this kind of attacks. Notice that a user might have an 
insecure umask at some point but not usually, the Lab::setup code 
compromises all the files he owns, not just those that are 770.

> > So what you have here is a race condition because of temporary 
> > files. Granted, this only happens when you have a lax umask, but it could 
> > be prevented either by using a proper function to create temporary 
> > directories (tempdir() will set them up mode 700) or by restricting the 
> > umask to 0700 when creating the temporary directories in Lab::setup().
> 
> No need to extra-restrict IMHO, I don't think one should restrict
> permissions above what's needed according to the user. On systems where
> I have a 02 umask, I *intent* for users of the same group to be able
> to write to all the stuf I do. If that's not intended, well, don't have
> a 02 umask.

Please, code that setups temporary stuff in all-writable location should be 
extra-restricted. Notice how tempfile() implementations and mktemp() 
implementations make temporary stuff _always_ mode 0700 for this same 
reason.
 
> > I did not properly assess the issue in the initial report, but I still
> > believe that Lintian has a security bug which introduces a hole under
> > some conditions and that could be easily fixed.
> 
> I, and with me one other lintian maintainer I consulted, still don't
> think this is a security bug (the different issue w.r.t. removing files
> however still stands).

I still think it _is_ a security issue, similar bugs (not defining a 
stricter umask when setting up temporary stuff) have been addressed in 
other programs without any issues. I would like to hear why is so important 
to you to preserve the user's umasks in the LINTIAN_LAB temporary directory 
when it's:

a- a temporary directory
b- a target for symlink attacks since its contents are predictable

Why not enforce a 077 umask there? 

Regards

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286379; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

Message #65 received at 286379@bugs.debian.org (full text, mbox):

From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: Martin Schulze <joey@infodrom.org>, 286379@bugs.debian.org
Cc: team@security.debian.org
Subject: Re: Bug#286379: Lintian insecure removal bug (#286379)
Date: Tue, 21 Dec 2004 13:16:03 +0100
clone 286379 -1
# why isn't there a BTS tag for 'disputed' or something??
retitle 286379 [lib/Lab] Lintian lab created unsafely, disputed
retitle -1 [CAN-2004-1000] [lib/Lab] Insecurely removes files after lab failed to be created
tags -1 confirmed woody sarge sid
severity -1 grave
thanks

On Tue, Dec 21, 2004 at 05:39:29AM +0100, Martin Schulze wrote:
> Ah.  Then I did not understand you inded.  I'd be glad for a fixed
> package sent to the security team.

Ok, since you confirm this is a security issue, cloned and severity set
to grave.

The originally reported issue is still under discussion, feel free to
give your opinion there if you wish.

Thanks,
--Jeroen

-- 
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl



Bug 286379 cloned as bug 286681. Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: confirmed, woody, sarge, sid Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `grave'. Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: pending Request was from "www.wolffelaar.nl" <www-data@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Message sent on to Javier Fernández-Sanguino Peña <jfs@computer.org>:
Bug#286681. Full text and rfc822 format available.

Message #78 received at 286681-submitter@bugs.debian.org (full text, mbox):

From: "www.wolffelaar.nl" <www-data@wolffelaar.nl>
To: control@bugs.debian.org, 286681-submitter@bugs.debian.org
Subject: Lintian bugs fixed in revision r395
Date: Mon, 27 Dec 2004 05:42:26 +0100
package lintian
# Fixed in r395 by djpig
tag 286681 + pending
thanks

These bugs are fixed in revision 395 by djpig
Log message:
SECURITY (CAN-2004-1000):
Overhaul lab directory handling. This also fixes the issue
of removing a lab that never was created (Closes: #286681)






Reply sent to Debian Lintian Maintainers <lintian-maint@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Javier Fernández-Sanguino Peña <jfs@computer.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #83 received at 286681-close@bugs.debian.org (full text, mbox):

From: Debian Lintian Maintainers <lintian-maint@debian.org>
To: 286681-close@bugs.debian.org
Subject: Bug#286681: fixed in lintian 1.23.6
Date: Sat, 01 Jan 2005 21:17:30 -0500
Source: lintian
Source-Version: 1.23.6

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

lintian_1.23.6.dsc
  to pool/main/l/lintian/lintian_1.23.6.dsc
lintian_1.23.6.tar.gz
  to pool/main/l/lintian/lintian_1.23.6.tar.gz
lintian_1.23.6_all.deb
  to pool/main/l/lintian/lintian_1.23.6_all.deb



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 286681@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Debian Lintian Maintainers <lintian-maint@debian.org> (supplier of updated lintian 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@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 27 Dec 2004 05:40:13 +0100
Source: lintian
Binary: lintian
Architecture: source all
Version: 1.23.6
Distribution: unstable
Urgency: low
Maintainer: Debian Lintian Maintainers <lintian-maint@debian.org>
Changed-By: Debian Lintian Maintainers <lintian-maint@debian.org>
Description: 
 lintian    - Debian package checker
Closes: 200171 244830 245883 258824 259227 284662 284728 285335 286681
Changes: 
 lintian (1.23.6) unstable; urgency=low
 .
   The "Let's see if I can upload myself now" release, made by Marc, Frank and
   Colin, uploaded by Jeroen.
 .
   * checks/description
     + [HE] Warn if the short description start with an article or a capital
       letter. Patch by Tobias Toedter <t.toedter@gmx.net>, thanks. (Closes:
       #258824)
   * checks/fields:
     + [HE] Warn if the debian revision has three parts, as this is the sign of
       a binary NMU. New check's name is binary-nmu-debian-revision-in-source.
       (Closes: #244830)
     + [HE] Warn if people use the Bugs field to refer to the Debian BTS, the
       new check is called redundant-bugs-field. (Closes: #245883)
   * checks/files:
     + [HE] Check that .desktop files are placed in /usr/share/applications.
       This seems to be the standard place for those files that are used
       to create menus. The check is called desktop-file-in-wrong-dir.
       (Closes: #200171)
   * checks/manpages:
     + [HE] Don't compare the manpage filename extension and the content of
       .TH case-sensitive. Report + patch by Jay Berkenbilt <ejb@ql.org>,
       thanks. (Closes: #285335)
     + [HE] Emit binary-without-english-manpage if a package only provides
       translated manpages for a binary. (Closes: #259227)
     + [HE] Skip all comment lines when checking for .so links in manpages.
       Thanks for the report and fix suggestion to Steinar H. Gunderson
       <sgunderson@bigfoot.com>. (Closes: #284662)
   * checks/md5sums:
     + [HE] Strip off ./ at the beginning of the filenames in md5sums
       files (this seems to happen on some systems, though we don't know
       how). (Closes: #284728)
   * checks/standards-version:
     + [CW] By definition, udebs aren't required to conform to policy, so
       don't issue no-standards-version-field for them. (If they happen to
       have a Standards-Version field anyway, we still check that it's
       valid.)
 .
   * lib/Lab.pm, frontend/lintian:
     SECURITY (CAN-2004-1000):
     + [FL] Overhaul lab directory handling. This also fixes the issue
       of removing a lab that never was created (Closes: #286681)
Files: 
 d7d7da4d3bf9e489da7174cf95dc8bbf 802 devel optional lintian_1.23.6.dsc
 039d5def803533ebcba3abe6656649e5 255150 devel optional lintian_1.23.6.tar.gz
 58c3979171d3751b04cafec7246038eb 221236 devel optional lintian_1.23.6_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Signed by Jeroen van Wolffelaar <jeroen@wolffelaar.nl>

iD8DBQFB11Qil2uISwgTVp8RAu/RAJ9M63wnOaxQWEt6WZny8tKTHEZVswCZAX9S
gASJ+tMQyWvj8o7jnWlbsUo=
=zLXv
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Lintian Maintainers <lintian-maint@debian.org>:
Bug#286681; Package lintian. Full text and rfc822 format available.

Acknowledgement sent to Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
Extra info received and forwarded to list. Copy sent to Debian Lintian Maintainers <lintian-maint@debian.org>. Full text and rfc822 format available.

Message #88 received at 286681@bugs.debian.org (full text, mbox):

From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: 286681@bugs.debian.org, 286681-submitter@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#286681: marked as done ([CAN-2004-1000] [lib/Lab] Insecurely removes files after lab failed to be created)
Date: Sun, 2 Jan 2005 03:45:08 +0100
reopen 286681
tags 286681 - sid
thanks

On Sat, Jan 01, 2005 at 06:33:16PM -0800, Debian Bug Tracking System wrote:
> Your message dated Sat, 01 Jan 2005 21:17:30 -0500
> with message-id <E1CkvJC-0004bI-00@newraff.debian.org>
> and subject line Bug#286681: fixed in lintian 1.23.6
> has caused the attached Bug report to be marked as done.

But is done in Sid only at the moment.

--Jeroen

-- 
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl



Bug reopened, originator not changed. Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Tags removed: sid Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Message sent on to Javier Fernández-Sanguino Peña <jfs@computer.org>:
Bug#286681. Full text and rfc822 format available.

Tags added: fixed Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Tags removed: fixed, woody Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to Steve Langasek <vorlon@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Javier Fernández-Sanguino Peña <jfs@computer.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #104 received at 286681-done@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 286681-done@bugs.debian.org
Subject: Re: [CAN-2004-1000] [lib/Lab] Insecurely removes files after lab failed to be created
Date: Tue, 11 Jan 2005 23:34:41 -0800
[Message part 1 (text/plain, inline)]
Version lintian 1.23.7 has reached testing, which is the last suite to be
fixed, so I believe this bug can now be closed.

Thanks,
-- 
Steve Langasek
postmodern programmer
[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 00:17:33 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.