headers
Zafer Aydogan | 3 Jul 2007 22:06
Picon

passwd authentication bug

Hello list,

I've come across that trying to set a password for a non existing user
displays this error:

# passwd foobar
Changing password for foobar.
Unable to change auth token: failed to recover old authentication token

instead of displaying that the user doesn't exists.

I'm running current as of July 3rd (4.99.22), but I noticed this bug a
while ago.

Zafer.
Permalink | Reply | 1 comment |
headers
Allen Briggs | 3 Jul 2007 22:08
Picon

Re: passwd authentication bug

On Tue, Jul 03, 2007 at 10:06:01PM +0200, Zafer Aydogan wrote:
> # passwd foobar
> Changing password for foobar.
> Unable to change auth token: failed to recover old authentication token
> 
> instead of displaying that the user doesn't exists.

Isn't this intentional?
To not provide information about which users exist or not.  Granted, for
root, it's not a big deal, but do we really need a separate code path
for that?

-allen

--

-- 
Allen Briggs  |  http://www.ninthwonder.com/~briggs/  |  briggs <at> ninthwonder.com
Permalink | Reply | 0 comments |
headers
John Nemeth | 3 Jul 2007 22:21
Picon
Favicon

Re: passwd authentication bug

On Nov 23,  4:41pm, "Zafer Aydogan" wrote:
} 
} I've come across that trying to set a password for a non existing user
} displays this error:
} 
} # passwd foobar
} Changing password for foobar.
} Unable to change auth token: failed to recover old authentication token
} 
} instead of displaying that the user doesn't exists.
} 
} I'm running current as of July 3rd (4.99.22), but I noticed this bug a
} while ago.

     This is not a bug.  It is not possible for passwd to determine
apriori if "user" exists.  Consider the idea of having passwords for
services which don't correspond to users that can login.  Under the new
world order of things like PAM and NSS, authentication has been
decoupled from user info and can come from completely seperate
sources.

}-- End of excerpt from "Zafer Aydogan"
Permalink | Reply | 1 comment |
headers
Zafer Aydogan | 3 Jul 2007 22:29
Picon

Re: passwd authentication bug

2007/7/3, John Nemeth <jnemeth <at> victoria.tc.ca>:
> On Nov 23,  4:41pm, "Zafer Aydogan" wrote:
> }
> } I've come across that trying to set a password for a non existing user
> } displays this error:
> }
> } # passwd foobar
> } Changing password for foobar.
> } Unable to change auth token: failed to recover old authentication token
> }
> } instead of displaying that the user doesn't exists.
> }
> } I'm running current as of July 3rd (4.99.22), but I noticed this bug a
> } while ago.
>
>      This is not a bug.  It is not possible for passwd to determine
> apriori if "user" exists.  Consider the idea of having passwords for
> services which don't correspond to users that can login.  Under the new
> world order of things like PAM and NSS, authentication has been
> decoupled from user info and can come from completely seperate
> sources.
>
> }-- End of excerpt from "Zafer Aydogan"
>

I would prefer a human readable error. In this case I don't really
know, if it is a system error or not. Something like: no such user,
would be great.

Zafer.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hubert Feyrer | 13 Jul 2007 14:13
Picon
Favicon

Secretly monopolizing the CPU w/o superuser privileges?


I've stumbled across [1] which describes a way to use cpu ressources in a 
way that does sub-tick task-switching, so that other processes get 
accounted while the mallicious process still takes an arbitrary CPU whare. 
Apparently FreeBSD's 4BSD and ULE schedulers are vulnerable.

I wonder how NetBSD goes in that regard - can you tell?

   - Hubert

[1] http://www.cs.huji.ac.il/~dants/papers/Cheat07Security.pdf
Permalink | Reply | 1 comment |
headers
matthew green | 13 Jul 2007 20:14
Picon
Favicon

re: Secretly monopolizing the CPU w/o superuser privileges?


   I've stumbled across [1] which describes a way to use cpu ressources in a 
   way that does sub-tick task-switching, so that other processes get 
   accounted while the mallicious process still takes an arbitrary CPU whare. 
   Apparently FreeBSD's 4BSD and ULE schedulers are vulnerable.

   I wonder how NetBSD goes in that regard - can you tell?

i've read most of this paper earlier this week.  as far as i can
tell and know, we are affected by it.  i've noticed the problem
(mainly between X and mplayer, like they did), but i didn't take
the next step and think about abuse (like they have.)

.mrg.
Permalink | Reply | 0 comments |
headers
Anne Bennett | 28 Jul 2007 19:41
Picon
Favicon

Re: NetBSD Security Advisory 2007-004: Insufficient length checking in iso(4)


On Thu, 29 Mar 2007, NetBSD Security-Officer wrote:

> 		 NetBSD Security Advisory 2007-004
[...]
> 		NetBSD 3.1:		affected
[...]
> Fixed:	[...]
> 		NetBSD-3-1 branch:	March 29, 2007
[...]
> To update from CVS, re-build, and re-install the kernel:
>
> 	# cd src
> 	# cvs update sys/netiso/clnp_subr.c
[and rebuild kernel]

I have tried this (cd /usr/src; cvs update sys/netiso/clnp_subr.c) and
as far as I can tell by the date stamps on clnp_subr.c (mod time
2005-02-26, ctime 2007-01-16 which is when I installed the system), I
am not getting updated code.  This is NetBSD 3.1 release (based on the
contents of /usr/src/CVS/Tag: Nnetbsd-3-1-RELEASE).  If I trace the
cvs call:

   : quill[root]:/usr/src ; cvs -t update sys/netiso/clnp_subr.c
    -> main loop with CVSROOT=anoncvs <at> anoncvs.netbsd.org:/cvsroot
    -> Starting server: ssh -l anoncvs anoncvs.netbsd.org cvs server
    -> Lock_Cleanup()
    -> Lock_Cleanup()

... apparently nothing to update.  Help?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Greg Troxel | 28 Jul 2007 21:16
Picon

Re: NetBSD Security Advisory 2007-004: Insufficient length checking in iso(4)

The release tag won't be moved.  You probably want to update to
netbsd-3-1 which is the tag for the stable branch along which 3.1 was
cut.  I just follow netbsd-3, which has more pullups, but I've never had
trouble from following a post-release stable branch.

'cvs log' on such a file is helpful.  excerpts

RCS file: /cvsroot/src/sys/netiso/clnp_subr.c,v
Working file: clnp_subr.c
head: 1.29
branch:
locks: strict
access list:
symbolic names:
	netbsd-3-1: 1.17.0.6
	netbsd-3-1-RELEASE: 1.17
	netbsd-3-1-1-RELEASE: 1.17.6.1
	netbsd-3-0-3-RELEASE: 1.17.4.1
	netbsd-3-0-1-RELEASE: 1.17
	netbsd-3-0: 1.17.0.4
	netbsd-3-0-RELEASE: 1.17
	netbsd-3-0-RC6: 1.17
	netbsd-3: 1.17.0.2
	netbsd-3-base: 1.17
	netbsd-4: 1.21.0.2
	netbsd-4-base: 1.21

As you can see it's mostly 1.17.

revision 1.17.6.1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Barrett | 28 Jul 2007 21:19
Gravatar

Re: NetBSD Security Advisory 2007-004: Insufficient length checking in iso(4)

On Sat, 28 Jul 2007, Anne Bennett wrote:
> I have tried this (cd /usr/src; cvs update sys/netiso/clnp_subr.c) and
> as far as I can tell by the date stamps on clnp_subr.c (mod time
> 2005-02-26, ctime 2007-01-16 which is when I installed the system), I
> am not getting updated code.  This is NetBSD 3.1 release (based on the
> contents of /usr/src/CVS/Tag: Nnetbsd-3-1-RELEASE).

That's a release tag, not a branch tag, so "cvs update" will do nothing.
If you had a branch tag, such as "netbsd-3-1" or "netbsd-3" instead of
"netbsd-3-1-RELEASE", then "cvs update" would attempt to update to a
later revision on the same branch.

"cvs update -r netbsd-3-1 ${filename}" should do the right thing.  I
suppose the instructions in the security advisory should be improved.

It would also be possible to change the process for creating the source
tarballs that are shipped with releases, such that they appear to
contain a branch tag instead of a release tag.  For example, a recursive
search and replace in all src/**/CVS/Tag files could be performed before
rolling the tarballs.

--apb (Alan Barrett)
Permalink | Reply | 2 comments |
headers
Anne Bennett | 28 Jul 2007 22:04
Picon
Favicon

updating vulnerable package in pkgsrc (gimp24)


Hi!

I wanted to install gimp24 from pkgsrc-2007Q2, but "make fetch"
stopped me with an error explaining that the version I had (2.3.18)
had a security vulnerability.  The documentation at
   ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/graphics/gimp24/README.html
suggests that the latest version is 2.3.18nb1, not 2.3.18.

I tried "cd /usr/pkgsrc; cvs -q update -dP", but it has not picked up
any updates since a run earlier this morning.  I was finally able to get
an updated version of gimp24 by downloading the pkgsrc-current tarball.

*Should* my "cvs" operation have picked up an updated version of gimp24,
or am I going about this all wrong?  The release announcement said that
"continuing engineering starts on the pkgsrc-2007Q2 release", and the
tarball does seem to get updated weekly or so, so I had the impression
that I should be able to pick up this update.  Perhaps I just tried at the
wrong moment, but gimp24 in pkgsrc-current seems to have been updated on
July 5, so I wonder if someone missed porting that update back to 2007Q2.

I don't have a deep understanding of what changes are or are not
included in released software trees, so I apologize if I seem to be
making unreasonable demands; such is not my intention.

Anne Bennett.
Permalink | Reply | 0 comments |

Gmane