----- Original Message ----- > From: "Keith Medcalf" <kmedc...@dessus.com>
> >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of > >valdis.kletni...@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 j...@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