netdev - RE: [PATCH for 3.8] iproute2: Add "ip netns pids" and "ip netns identify"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B711A@saturn3.aculab.com>
Date:	Mon, 21 Jan 2013 09:52:28 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Ben Hutchings" <bhutchings@...arflare.com>
Cc:	"Stephen Hemminger" <shemminger@...tta.com>,
	<netdev@...r.kernel.org>, "Serge E. Hallyn" <serge@...lyn.com>
Subject: RE: [PATCH for 3.8] iproute2: Add "ip netns pids" and "ip netns identify"

> >> >> >> +		if (!isdigit(ch))
> >> >> >
> >> >> > ch must be cast to unsigned char before passing to isdigit().
> >> >>
> >> >> isdigit is defined to take an int.  A legacy of the implicit casts in
> >> >> the K&R C days.  Casting to unsigned char would be pointless and silly.
> >> > [...]
> >> >
> >> > It's not pointless.  This is explained in the very first line of the
> >> > description in the manual page...
> >>
> >> If it's not pointless it is an implementation bug.
> >
> > You can either get in your time machine and go back to 1978 and fix it,
> > or add the cast like every C programmer who knows what the C standards
> > say about these functions.
> 
> So I took a moment to look. The C standard is indeed does not say
> anything about this and supporting signed char becomes a quality of
> implementation issue.  glibc supports being passed signed character
> values.

You must have looked in the wrong place.
The standards documentation on all the ctype functions is very clear
about the valid input domain.

> > Testing on one implementation doesn't prove anything.  'char' can be
> > signed or unsigned depending on the architecture, and some C libraries
> > work around buggy applications that .  That's no reason to write another
> > buggy application.
> 
> This code by it's very nature is not portable.  The code is not suid
> so insane level of paranoia don't need to be maintained.

What!!!! You still don't want core dumps due to invalid input.
Especially if the input might be from a file.
I did the full trawl of NetBSD's 'src' tree because of issues with
one of the shells faulting.

> The definition
> in the C standard is a least common denominator requirement.  Posix
> copies that least common denominator requirement.  Glibc does not
> implment the least common denominator.

Unless you writes 'standards compliant' programs, you will eventually
fall foul of these sort of problems.

Are you sure that glibc will always be used? What about newlib?

There may be strict requirements on isdigit() (I think you are
allowed to subtract '0' to get a number). The same is not true
of isprint(), isprint(EOF) is FALSE, isprint(255) may be TRUE
(ij ligature).

	David



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html