Re: kern/56673: don't allow execve with NULL argv

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/56673; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Jan Schaumann <jschauma%netmeister.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost
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@localhost>
     Message-ID:  <20220131141150.GK8927%netmeister.org@localhost>
 
   | 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.