----- Original Message -----
From: "Keith Medcalf" <kmedcalf@dessus.com>
From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Valdis.Kletnieks@vt.edu
On Sat, 27 Sep 2014 21:10:28 -0400, Jay Ashworth said:
I haven't an example case, but it is theoretically possible.
The sendmail setuid bug, where it failed to check the return code because it was *never* possible for setuid from root to non-root to fail... ... until the Linux kernel grew new features.
This is another case where a change was made.
If the change had not been made (implement the new kernel) then the vulnerability would not have been introduced.
The more examples people think they find, the more it proves my proposition. Vulnerabilities can only be introduced or removed through change. If there is no change, then the vulnerability profile is fixed.
[ quoting fixed because you were too lazy ] We have established, Keith, that you place the boundary of the object for which an end-deployer has administrative control in a different place for the purpose of assigning blame than most other people seem to, yes. The sendmail maintainers are *NOT RESPONSIBLE* for avoiding exploits that cannot happen in any available or planned deployment environment, nor for decisions made by the creators of those environments which *cause their code to become exploitable ex-post-facto*. That's the point which I see being made here. If that's orthogonal to your argument, so be it. Could we drop this now? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274