NetBSD Problem Report #56673
From jschauma@netmeister.org Wed Jan 26 15:50:48 2022
Return-Path: <jschauma@netmeister.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 4FADC1A9239
for <gnats-bugs@gnats.NetBSD.org>; Wed, 26 Jan 2022 15:50:48 +0000 (UTC)
Message-Id: <20220126155045.32A3C8586F@panix.netmeister.org>
Date: Wed, 26 Jan 2022 10:50:45 -0500 (EST)
From: jschauma@netmeister.org
Reply-To: jschauma@netmeister.org
To: gnats-bugs@NetBSD.org
Subject: don't allow execve with NULL argv
X-Send-Pr-Version: 3.95
>Number: 56673
>Category: kern
>Synopsis: don't allow execve with NULL argv
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Jan 26 15:55:01 +0000 2022
>Last-Modified: Sat Feb 05 23:15:01 +0000 2022
>Originator: Jan Schaumann
>Release:
>Organization:
>Description:
As illustrated on Linux by e.g., https://seclists.org/oss-sec/2022/q1/80,
calling execve(2) with a NULL argv can have unexpected consequences.
OpenBSD, for example, does not permit exexcve with a NULL argv, but NetBSD
does.
I'd suggest to fail if the argv is NULL.
>How-To-Repeat:
$ cat <<EOF >a.c
#include <stdlib.h>
#include <unistd.h>
int main() {
char *argv[]={ NULL };
char *envp[]={ NULL };
execve("/bin/sh", argv, envp);
exit(42);
}
EOF
$ cc a.c
$ ./a.out
>Fix:
>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Wed, 26 Jan 2022 17:08:53 +0100
On Wed, Jan 26, 2022 at 03:55:01PM +0000, jschauma@netmeister.org wrote:
> I'd suggest to fail if the argv is NULL.
I'm ambivalent here. Posix does allow it and the behaviour is well defined
(if I didn't miss something).
And setuid programs with stupid casts to unsigned (probably just added
there to silence the compiler warning) are dangerous - and this is not
a kernel issue.
On the other hand there is probably no reasonable code out there that would
use this, so rejecting it might be ok.
Martin
From: Jan Schaumann <jschauma@netmeister.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Wed, 26 Jan 2022 11:31:04 -0500
Martin Husemann <martin@duskware.de> wrote:
> On Wed, Jan 26, 2022 at 03:55:01PM +0000, jschauma@netmeister.org wrote:
> > I'd suggest to fail if the argv is NULL.
>
> I'm ambivalent here. Posix does allow it and the behaviour is well defined
> (if I didn't miss something).
>
> And setuid programs with stupid casts to unsigned (probably just added
> there to silence the compiler warning) are dangerous - and this is not
> a kernel issue.
>
> On the other hand there is probably no reasonable code out there that would
> use this, so rejecting it might be ok.
If POSIX doesn't _require_ us to accept a NULL argv,
then I think it's reasonable to reject it:
,----[ https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html ]
| Early proposals required that the value of argc passed
| to main() be "one or greater". This was driven by the
| same requirement in drafts of the ISO C standard. In
| fact, historical implementations have passed a value
| of zero when no arguments are supplied to the caller
| of the exec functions. This requirement was removed
| from the ISO C standard and subsequently removed from
| this volume of POSIX.1-2017 as well. The wording, in
| particular the use of the word should, requires a
| Strictly Conforming POSIX Application to pass at least
| one argument to the exec function, thus guaranteeing
| that argc be one or greater when invoked by such an
| application. In fact, this is good practice, since
| many existing applications reference argv[0] without
| first checking the value of argc.
`----
Just seems like the safer thing to do in the absence
of a valid use case of a NULL argv.
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org, martin@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: re: kern/56673: don't allow execve with NULL argv
Date: Sun, 30 Jan 2022 16:57:24 +1100
this seems to work for me. martin, ok to commit?
.mrg.
don't allow exec or spawn with an argument vector of just NULL.
we already rejected argv == NULL itself, but this was allowed:
char *argv[1] = { 0 };
Index: kern_exec.c
===================================================================
RCS file: /cvsroot/src/sys/kern/kern_exec.c,v
retrieving revision 1.514
diff -p -u -r1.514 kern_exec.c
--- kern_exec.c 26 Nov 2021 08:06:12 -0000 1.514
+++ kern_exec.c 30 Jan 2022 03:24:42 -0000
@@ -1666,6 +1666,10 @@ copyinargs(struct execve_data * restrict
return error;
}
data->ed_argc += i;
+ if (data->ed_argc == 0) {
+ DPRINTF(("%s: zero args\n", __func__));
+ return EINVAL;
+ }
/*
* Read and count environment strings from user.
From: Robert Elz <kre@munnari.OZ.AU>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@netbsd.org, martin@netbsd.org, kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Sun, 30 Jan 2022 16:40:00 +0700
I see no reason, much less need or requirement, for this.
kre
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
jschauma@netmeister.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Sun, 30 Jan 2022 08:02:36 -0500
--Apple-Mail=_FF779BD6-7CAB-40E6-8E64-3FDEEDB167EB
Content-Type: multipart/alternative;
boundary="Apple-Mail=_CA0CF659-CB1C-4593-A26E-94356F0ED123"
--Apple-Mail=_CA0CF659-CB1C-4593-A26E-94356F0ED123
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
We have 10 pages of "argv[0]" according to nxr.netbsd.org =
<http://nxr.netbsd.org/>...
Enough programs assume it is there and dereference it without checking.
christos
--Apple-Mail=_CA0CF659-CB1C-4593-A26E-94356F0ED123
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=us-ascii
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">We have 10 pages of "argv[0]" according to <a href="http://nxr.netbsd.org" class="">nxr.netbsd.org</a>...<div class="">Enough programs assume it is there and dereference it without checking.</div><div class=""><br class=""></div><div class="">christos</div></body></html>
--Apple-Mail=_CA0CF659-CB1C-4593-A26E-94356F0ED123--
--Apple-Mail=_FF779BD6-7CAB-40E6-8E64-3FDEEDB167EB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYfaMbAAKCRBxESqxbLM7
OvWgAKCzpxAteMm86k+9sc0o5I1e1esr2ACg2tRmhyrvfsrjMNX1xQMrHA6iYxI=
=Ri2L
-----END PGP SIGNATURE-----
--Apple-Mail=_FF779BD6-7CAB-40E6-8E64-3FDEEDB167EB--
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Sun, 30 Jan 2022 20:37:47 +0700
Date: Sun, 30 Jan 2022 13:05:01 +0000 (UTC)
From: Christos Zoulas <christos@zoulas.com>
Message-ID: <20220130130501.C1D9D1A923D@mollari.NetBSD.org>
| Enough programs assume it is there and dereference it without checking.
It was this kind of reasoning that led to making *NULL == '\0'
Long term it is better to just fix progs making faulty assumptions
than to try to cater to all of those.
kre
From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, jschauma@netmeister.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Sun, 30 Jan 2022 16:53:17 +0100
Am Sun, Jan 30, 2022 at 01:40:01PM +0000 schrieb Robert Elz:
> The following reply was made to PR kern/56673; it has been noted by GNATS.
>
> From: Robert Elz <kre@munnari.OZ.AU>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/56673: don't allow execve with NULL argv
> Date: Sun, 30 Jan 2022 20:37:47 +0700
>
> Date: Sun, 30 Jan 2022 13:05:01 +0000 (UTC)
> From: Christos Zoulas <christos@zoulas.com>
> Message-ID: <20220130130501.C1D9D1A923D@mollari.NetBSD.org>
>
> | Enough programs assume it is there and dereference it without checking.
>
> It was this kind of reasoning that led to making *NULL == '\0'
>
> Long term it is better to just fix progs making faulty assumptions
> than to try to cater to all of those.
IMO POSIX at least implies that argc > 0:
The argument arg0 should point to a filename string that is associated
with the process being started by one of the exec functions.
I really don't see a point in allow argc==0 to be valid.
Joerg
From: Robert Elz <kre@munnari.OZ.AU>
To: Joerg Sonnenberger <joerg@bec.de>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, jschauma@netmeister.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Sun, 30 Jan 2022 23:54:47 +0700
Date: Sun, 30 Jan 2022 16:53:17 +0100
From: Joerg Sonnenberger <joerg@bec.de>
Message-ID: <Yfa0bYr9dWHjMajW@bec.de>
| IMO POSIX at least implies that argc > 0:
|
| The argument arg0 should point to a filename string that is associated
| with the process being started by one of the exec functions.
No, that cannot be read that way. That it says "should" and not "shall"
in any case makes it clear it is a recommendation, not a requirement, but
that one is also clearly aimed at application writers, indicating to them
the convention for the use of argv.
If that sentence meant what you're suggesting it might, then as well as
making
argv[] = { NULL };
invalid, we'd also need to make
argv[] = { "", NULL };
invalid, as "" isn't a proper filename string for anything, let alone
being associated with the process being started.
Further, it might also prohibit the (ancient) tradition of indicating
a login shell by making the first char of arg0 be '-', as "-sh" isn't
a filename string associated with the process either (nor are -ksh -csh
-tsch -bash ...)
If POSIX really intended to prohibit having no args at all (as distinct
from no arg vector at all) then it would be much more explicit than that,
and the requirement would be on the implementation to enforce it, not on
the application. For that there'd be an errno value defined to indicate
this "error", and there isn't. mrg's proposed patch uses EINVAL (which
is the one most likely to apply), but in the POSIX exec functions:
[EINVAL] The new process image file has appropriate privileges and has
a recognized executable binary format, but the system does not
support execution of a file with this format.
That's it for EINVAL for exec*() - nothing relating to the arg lists at
all. [Aside: I know that implementations are permitted to use new errno
values, or ones assigned for a purpose beyond that for which they are
defined, provided that doing do doesn't usurp some other errno value that
should have been returned instead ... that is, I am not claiming that
the proposed patch is a POSIX violation.]
| I really don't see a point in allow argc==0 to be valid.
I don't see a use for it either. But the number of things I don't
see a use for, which turn out to be quite useful, is almost beyond
comprehension.
What I don't see is any good reason (beyond laziness in fixing broken
applications) for making this change.
kre
From: Jan Schaumann <jschauma@netmeister.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Sun, 30 Jan 2022 16:54:10 -0500
If we already reject argv == NULL itself, as noted by
mrg@, then I really don't see a good argument to allow
char *argv[1] = { 0 };
POSIX does not appear to prohibit enforcing argv[0] to
be non-NULL, and while it may at the same time _allow_
argv[0] == NULL, it strikes me as entirely reasonable
to prevent what almost inevitably is problematic.
While we can fix all code in the NetBSD source tree to
not assume argv[0] != NULL, we cannot do the same for
all add-on software. Preventing errant use of
(albeit permissible) coding errors makes for a more
robust OS.
From: matthew green <mrg@eterna.com.au>
To: Jan Schaumann <jschauma@netmeister.org>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Subject: re: kern/56673: don't allow execve with NULL argv
Date: Mon, 31 Jan 2022 10:53:46 +1100
Jan Schaumann writes:
> If we already reject argv == NULL itself, as noted by
> mrg@, then I really don't see a good argument to allow
>
> char *argv[1] = { 0 };
>
> POSIX does not appear to prohibit enforcing argv[0] to
> be non-NULL, and while it may at the same time _allow_
> argv[0] == NULL, it strikes me as entirely reasonable
> to prevent what almost inevitably is problematic.
>
> While we can fix all code in the NetBSD source tree to
> not assume argv[0] != NULL, we cannot do the same for
> all add-on software. Preventing errant use of
> (albeit permissible) coding errors makes for a more
> robust OS.
while kre is technically correct that the "should" and
"shall" usage in the standard enables the current method,
the RATIONALE is pretty clear on what they prefer and
explicitly call out the accessing argv[0] issue.
The wording, in particular the use of the word should,
requires a Strictly Conforming POSIX Application to
pass at least one argument to the exec function, thus
guaranteeing that argc be one or greater when invoked
by such an application. In fact, this is good practice,
since many existing applications reference argv[0]
without first checking the value of argc.
i'm failing to see any real benefit for this *except* if
you have an existing binary that relies upon this, though
i'd really like to understand this if it were true (and
why, if only to understand what went wrong...)
i think it's folly to try to fix every argv[0] usage in
the world. there's probably new code written every day
that assumes argv[0] is valid.
i'm open to a sysctl to enable the existing usage for
anyone that absolutely needs it.
.mrg.
From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, jschauma@netmeister.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Mon, 31 Jan 2022 01:43:17 +0100
Am Sun, Jan 30, 2022 at 11:55:02PM +0000 schrieb matthew green:
> i'm open to a sysctl to enable the existing usage for
> anyone that absolutely needs it.
That would defeat the purpose, wouldn't it? One option would be to fix
it up on the kernel side if we really want to support such broken
binaries...
Joerg
From: Robert Elz <kre@munnari.OZ.AU>
To: Joerg Sonnenberger <joerg@bec.de>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, jschauma@netmeister.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Mon, 31 Jan 2022 17:09:33 +0700
Date: Mon, 31 Jan 2022 01:43:17 +0100
From: Joerg Sonnenberger <joerg@bec.de>
Message-ID: <YfcwpZ/g7ltS0Y6t@bec.de>
| Am Sun, Jan 30, 2022 at 11:55:02PM +0000 schrieb matthew green:
| > i'm open to a sysctl to enable the existing usage for
| > anyone that absolutely needs it.
|
| That would defeat the purpose, wouldn't it?
I agree. Whatever finally happens, if anything, making it tunable
helps no-one.
The question is whether we're going to start pandering to broken
apps which assume argc > 0, and if that, what else?
My guess would be that such apps also assume that **argv != '\0',
so should that be an error as well?
Or should we just fix anything we find that is broken? That is
what we did (do) with apps that reference *NULL - or should we
also go back to making that work?
I doubt fixing breakage here would be very hard, finding refs
to refs of argv[0] isn't all that difficult. This also is not
urgent, I'm not aware af anything that calls any of the exec()
functions without giving a value for argv[0] - is anyone?
kre
ps: if you really want to have the kernel prevent any bugs
from occurring in any application code - that's trivial to
accomplish. Simply have the exec() sys call simply return
EINVAL in all cases. No more bugs in user code. Just don't
do that in the kernel I run, I like my application bugs...
From: Jan Schaumann <jschauma@netmeister.org>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: Joerg Sonnenberger <joerg@bec.de>, gnats-bugs@netbsd.org,
kern-bug-people@netbsd.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Mon, 31 Jan 2022 09:11:50 -0500
Robert Elz <kre@munnari.OZ.AU> wrote:
> I doubt fixing breakage here would be very hard, finding refs
> to refs of argv[0] isn't all that difficult. This also is not
> urgent, I'm not aware af anything that calls any of the exec()
> functions without giving a value for argv[0] - is anyone?
Are you asking for calls in base or for _any_ example?
The polkit vulnerabiity (CVE-2021-4034)) that prompted
me to open this PR is an example. polkit is available
via pkgsrc, so conceivably vulnerable on NetBSD
(although I haven't verified it).
-Jan
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
jschauma@netmeister.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Mon, 31 Jan 2022 09:41:14 -0500
--Apple-Mail=_EA25A4D9-A4C8-4715-81DC-0AC4C1D91517
Content-Type: multipart/alternative;
boundary="Apple-Mail=_883632D1-401E-48E7-B63B-A9B26E10D83F"
--Apple-Mail=_883632D1-401E-48E7-B63B-A9B26E10D83F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
I see this as an instance of a non-conforming environment as described =
in:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html =
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html>
It was the case in the past that we did not deal with 0, 1, 2 being =
closed,
but now we do, at least for set*id executables. The fact that the =
documentation
explicitly does not call having argc !=3D 0 and argv[0] pointing to =
valid memory
out *yet* as a requirement does not mean that we should not make the
world a safer place and enforce it. I see it simply as putting a check =
in one
place instead of forcing everyone to be check for it. It is good =
hygiene.
Best,
christos
--Apple-Mail=_883632D1-401E-48E7-B63B-A9B26E10D83F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">I =
see this as an instance of a non-conforming environment as described =
in:<div class=3D""><a =
href=3D"https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.ht=
ml" =
class=3D"">https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec=
.html</a></div><div class=3D""><br class=3D""></div><div class=3D"">It =
was the case in the past that we did not deal with 0, 1, 2 being =
closed,</div><div class=3D"">but now we do, at least for set*id =
executables. The fact that the documentation</div><div =
class=3D"">explicitly does not call having argc !=3D 0 and argv[0] =
pointing to valid memory</div><div class=3D"">out *yet* as a requirement =
does not mean that we should not make the</div><div class=3D"">world a =
safer place and enforce it. I see it simply as putting a check in =
one</div><div class=3D"">place instead of forcing everyone to be check =
for it. It is good hygiene.</div><div class=3D""><br class=3D""></div><div=
class=3D"">Best,</div><div class=3D""><br class=3D""></div><div =
class=3D"">christos<br class=3D""><div><br class=3D""></div><br =
class=3D""></div></body></html>=
--Apple-Mail=_883632D1-401E-48E7-B63B-A9B26E10D83F--
--Apple-Mail=_EA25A4D9-A4C8-4715-81DC-0AC4C1D91517
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYff1CgAKCRBxESqxbLM7
Or4MAKCYaid/OZ7Rdy/oZXqTTgrW6rSzLgCgwwzlcAd/zxQunBnAIvmgdn0l7UE=
=6deB
-----END PGP SIGNATURE-----
--Apple-Mail=_EA25A4D9-A4C8-4715-81DC-0AC4C1D91517--
From: Robert Elz <kre@munnari.OZ.AU>
To: Jan Schaumann <jschauma@netmeister.org>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Mon, 31 Jan 2022 22:24:01 +0700
Date: Mon, 31 Jan 2022 09:11:50 -0500
From: Jan Schaumann <jschauma@netmeister.org>
Message-ID: <20220131141150.GK8927@netmeister.org>
| Are you asking for calls in base or for _any_ example?
Any but...
| The polkit vulnerabiity (CVE-2021-4034)) that prompted
| me to open this PR is an example. polkit is available
| via pkgsrc, so conceivably vulnerable on NetBSD
| (although I haven't verified it).
That's an example of something which is affected by this issue, not
something which causes it. I was seeking any (normal, rather than
purpose created) applications which actually exec utilities with
no args at all (ie: ones where the proposed change would generate an
error).
I don't doubt there are applications which don't check for argc==0
correctly (that one being one) - and which should be fixed, regardless
of whether or not the kernel change is made on NetBSD, as any application
could easily be moved to some other system (including older NetBSD) where
there is no such check.
Obviously any setuid/setgid applications should be checked quickly,
as those might be able to be coerced to do something strange - but
for the rest, assuming that there are no ordinary invocations (and in
NetBSD base I assume not, as no-one is reporting any bugs with other
apps randomly crashing because of this) there is no big hurry to fix
any that are broken, as (assuming ls was to be one such program, just as
an example ... I have no reason to suspect that it is however, just for
the purposes of exposition in this message) that someone can write a
program to exec ls (or whatever) with no args, and have it do something
strange (including perhaps dump core) isn't really a problem for anyone
but them (whatever ls did in such a case they could simply write code
to do, and run it).
kre
ps: I remain opposed to installing changes that promote/allow sloppy
programming, no matter how widespread it seems it may be.
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
jschauma@netmeister.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Mon, 31 Jan 2022 10:28:50 -0500
--Apple-Mail=_B6F9B7A1-CE5F-4E65-A8FB-54A7826750C3
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
> Obviously any setuid/setgid applications should be checked quickly,
> as those might be able to be coerced to do something strange - but
> for the rest, assuming that there are no ordinary invocations (and in
> NetBSD base I assume not, as no-one is reporting any bugs with other
> apps randomly crashing because of this) there is no big hurry to fix
> any that are broken, as (assuming ls was to be one such program, just as
> an example ... I have no reason to suspect that it is however, just for
> the purposes of exposition in this message) that someone can write a
> program to exec ls (or whatever) with no args, and have it do something
> strange (including perhaps dump core) isn't really a problem for anyone
> but them (whatever ls did in such a case they could simply write code
> to do, and run it).
In that case we should at least put the check for set*id programs, like we've
done with file descriptors :-)
christos
--Apple-Mail=_B6F9B7A1-CE5F-4E65-A8FB-54A7826750C3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYfgAMgAKCRBxESqxbLM7
Oo3eAJ9WNy7hW+/RxwFDJ6HQoWJv2EX/NgCgvVbKJLOHbmZHfmAAgW8AjhVfcJ8=
=Ggsn
-----END PGP SIGNATURE-----
--Apple-Mail=_B6F9B7A1-CE5F-4E65-A8FB-54A7826750C3--
From: Robert Elz <kre@munnari.OZ.AU>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Mon, 31 Jan 2022 22:43:18 +0700
Date: Mon, 31 Jan 2022 09:41:14 -0500
From: Christos Zoulas <christos@zoulas.com>
Message-ID: <12E23D1B-F51B-44F2-B4C0-D950415B4863@zoulas.com>
| I see this as an instance of a non-conforming environment
It isn't.
| The fact that the documentation explicitly does not call having argc != 0
| and argv[0] pointing to valid memory out *yet*
The latter (pointing to invalid memory) isn't an issue, if the caller
of an exec function supplies a nonsense argv[0] they'll either get a
SIGSETV or an EFAULT, just like any other syscall where a pointer to
invalid memory is provided. If the kernel is supplying an invalid
pointer to an exec'd application, then it (the kernel) is simply broken,
which no test we can reasonably insert can prevent (but which, for this
issue anyway, doesn't happen).
As for *yet* for the former (argc > 0) I see no signs of that ever
changing - it is clear from what is already there, that the issue of
sending no args at all was very well understood by some earlier set
of standards writers (I don't have copies of anything old enough to
determine when that was first added) and yet there was no attempt to
force the world to change at that time (and this would have been an
easy change to make, as in practice, no-one normally ever exec's
something with no args at all, so they would have not been breaking
anything, unlike some of the other changes that have been made).
It is a bit hard to imagine that anyone is about to change that now.
| I see it simply as putting a check in one place instead of forcing
| everyone to be check for it. It is good hygiene.
Exactly the same can be said about making *NULL "work" properly.
We can (and once it was done) fix the kernel to that *NULL == '\0'
(and if needed is zero for any reasonable width of data access - ie:
provide a page of all 0's at 0), which would save all of those
if (p != NULL) tests that we currently need to make. Not sure doing
that counts as good hygiene though, in either case.
kre
From: Robert Elz <kre@munnari.OZ.AU>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, jschauma@netmeister.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Mon, 31 Jan 2022 23:34:20 +0700
Date: Mon, 31 Jan 2022 10:28:50 -0500
From: Christos Zoulas <christos@zoulas.com>
Message-ID: <5DEB3406-EC66-44B8-905B-9C87A650506F@zoulas.com>
| In that case we should at least put the check for set*id programs
That much I wouldn't object to.
kre
From: Jan Schaumann <jschauma@netmeister.org>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org
Cc:
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Fri, 4 Feb 2022 18:21:51 -0500
FWIW, here's a summary of the same discussion on
the linux-kernel mailing list:
https://lwn.net/SubscriberLink/882799/cb8f313c57c6d8a6/
https://lwn.net/ml/linux-kernel/20220126043947.10058-1-ariadne@dereferenced.org/
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
jschauma@netmeister.org
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Sat, 5 Feb 2022 18:11:33 -0500
--Apple-Mail=_CED7FD20-ADC0-4260-B62E-0E8103F96734
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
I've committed a change that prevents executing set*id binaries with no =
args as discussed.
The link below is factually incorrect because it says that BSD's already =
disallow this.
christos
> On Feb 4, 2022, at 6:25 PM, Jan Schaumann <jschauma@netmeister.org> =
wrote:
>=20
> The following reply was made to PR kern/56673; it has been noted by =
GNATS.
>=20
> From: Jan Schaumann <jschauma@netmeister.org>
> To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org
> Cc:
> Subject: Re: kern/56673: don't allow execve with NULL argv
> Date: Fri, 4 Feb 2022 18:21:51 -0500
>=20
> FWIW, here's a summary of the same discussion on
> the linux-kernel mailing list:
>=20
> https://lwn.net/SubscriberLink/882799/cb8f313c57c6d8a6/
>=20
> =
https://lwn.net/ml/linux-kernel/20220126043947.10058-1-ariadne@dereference=
d.org/
>=20
--Apple-Mail=_CED7FD20-ADC0-4260-B62E-0E8103F96734
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYf8EJQAKCRBxESqxbLM7
OuyuAKCIRfOEQuE0k6H1U1zX7l2QXPudDQCfUf7eFyNsfBeTUMniCjnooZ3S2+s=
=dSzM
-----END PGP SIGNATURE-----
--Apple-Mail=_CED7FD20-ADC0-4260-B62E-0E8103F96734--
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home