Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: A Famous Security Bug Date: Fri, 22 Mar 2024 07:50:09 -0700 Organization: A noiseless patient Spider Lines: 62 Message-ID: <86a5mql3ry.fsf@linuxsc.com> References: <20240320114218.151@kylheku.com> <20240321211306.779b21d126e122556c34a346@gmail.moc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="43a124101bc8549bfa1c6f6d248b1944"; logging-data="3141256"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1820LYTj/yTSHX3OWUKPF+l4wR8VICgcHY=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:NNCA3xQMDidJNyDxurVMurgs6WQ= sha1:uVu21fcn+FBQ9HeJ9f9TqOySLmQ= Bytes: 3601 Anton Shepelev writes: > Kaz Kylheku to Stefan Ram: > >>>> A "famous security bug": >>>> >>>> void f( void ) >>>> { char buffer[ MAX ]; >>>> /* . . . */ >>>> memset( buffer, 0, sizeof( buffer )); } >>>> >>>> . Can you see what the bug is? >> >> I don't know about "the bug", but conditions can be >> identified under which that would have a problem >> executing, like MAX being in excess of available automatic >> storage. >> >> If the /*...*/ comment represents the elision of some >> security sensitive code, where the memset is intended to >> obliterate secret information, of course, that >> obliteration is not required to work. >> >> After the memset, the buffer has no next use, so the all >> the assignments performed by memset to the bytes of buffer >> are dead assignments that can be elided. >> >> To securely clear memory, you have to use a function for >> that purpose that is not susceptible to optimization. > > I think this behavior (of a C compiler) rather stupid. In a > low-level imperative language, the compiled program shall > do whatever the programmer commands it to do. If he > commands it to clear the buffer, it shall clear the buffer. > This optimisation is too high-level, too counter-inituitive, > even deceitful. The optimiser is free to perform the task > in the fastest manner possible, but it shall not ignore the > programmer's order to zero-fill the buffer, especially > without emitting a warning about (potentially!) redundant > code, which it is the programmer's reponsibility to confirm > and remove. > > Redundant code shall be dealt with in the source, rather than > in the executable. I have a couple of reactions. One is that the ship has sailed. Somewhere between 35 and 40 years ago the people who wrote the C standard decided on a semantic model that allows optimizations like this, and that is not going to change. Certainly there are people who would prefer to think of C as being a "low-level imperative language" like what you describe, but the C community as a whole has accepted the view taken by the authors of the C standard. The second reaction is that, to be somewhat blunt, what is being suggested is naive. I expect you do not yet appreciate the ramifications of what you are suggesting. It is hard, indeed I would say very hard, to define a semantic model that faithfully represents the behaviors you would like to impose. You might want to look into that, and what has been tried previously along these lines, before pursuing this advocacy any further.