At 8:45 AM -0500 12/30/06, Leichter, Jerry wrote:

> [MJoderator:  This is likely beyond the point of general interest to sc-l]

Actually, I disagree, in that it seems to expose a set of vulnerabilities
not known even to language implementors.

> On Fri, 29 Dec 2006, ljknews wrote:

> | But these are problems that have been solved by those who provided the
> | Ada implementation (ACT and Aonix come to mind for Unix), and thus are
> | not an issue for the high level language programmer.

> Presumably they do the create-the-file-and-immediately-delete-it trick.
> Since the file must, however briefly, have an entry in some directory.
> General purpose code can't make assuptions about what directories
> are available for writing, so pretty much has to put the entry in
> a known, public place - almost always /tmp or /var/tmp.  Unless one
> does this very carefully, it's open to various attacks.  (For one
> trivial example, there is no way to tell the open() call to *always*
> create a new file - you can only tell it "if the file already exists,
> don't open it, return an error instead".  The code had better check
> for that error and do something appropriate or it can be fooled into
> using a file an attacker created and already has access to.)

Certainly code that does not check for errors is inadequate.

> The techniques for doing this are complex enough - and the attacks
> if you don't do it *exactly* right obscure enough - that after all
> these years, attacks based on "insecure temporary file creation"
> are still reported regularly.  (Frankly, even though I know that
> these problems exist, if you were to ask me to write a secure
> temporary file creator right now, I wouldn't try - I'd look for
> some existing code, because I doubt I'd get it right.)

Which is what one does when using the existing language implementation
(except for the defect reported by Florian Weimer in this thread.
Larry Kilgallen
Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Reply via email to