Re: Secure C library

<websnarf@xxxxxxxxx> wrote in message
news:1126564715.536854.113280@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

> P.J. Plauger wrote:
>> "David Wagner" <daw@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> > In general, the interface doesn't seem like it has been designed; it
>> > seems like someone just took the existing string-related functions and
>> > tweaked them with a max str len. But some of the old unbounds-checked
>> > string functions don't make much sense once you add bounds-checking
>> > (if they ever did). It seems like if one had put some thought into
>> > designing an interface just for the purpose of reducing the frequency
>> > of security bugs, and studied the history of problems in the current
>> > interfaces, one could do better.
>>
>> Well, that's in fact exactly what Microsoft did. They came up with a
>> library that could be incrementally retrofit to existing C code to
>> make buffer size decisions more visible, in response to their extensive
>> data about the commonest sources of bugs and security gaffes. They
>> then spent a couple of years refining the library *and converting
>> millions of lines of C code to use it*.
>
> You are looking to Microsoft for leadership on making code safer? Even
> if you believe they knew something, Microsoft has only *very recently*
> paid serious attention to security. They are relative newcomers.

So what? They're doing *something*. They put together a *proposal*.
That's better than the bystanders who keep telling us what we're
doing wrong and how we should do it better under their tutelage
(but without their hard work).

> The fact that they can convert 7 million lines of code, is a testament
> to the amount of proprietary code they own, and their ability to push a
> matra throughout their corporation, but I can't tell whether this is
> being driven by a PR message or by a truly deep technical motivation.

Again, so what? If they produce evidence that their proposed new
library makes a difference, it's worth considering, IMO.

> By comparison, from what I know, David has been really looking very
> closely at security for about a decade (remember the Netscape random
> number generator exploit? I believe he was somehow involved.) So
> amongst security experts (that don't work for Microsoft), what kind of
> feedback are you getting for this proposal? I'm not an expert, but my
> reaction to the proposal itself is basically identical to David's.

People who identify themselves as actively involved in the security
community have attended recent WG14 meetings. While they do radiate
a general air of superiority, I haven't heard any of them yet press
for dumping the Secure C TR altogether because it is terminally
naive. (But then, maybe they're uncharacteristically shy on this
particular point.)

>> Maybe an opaque buffer type would be safer in the end, but it's a
>> bigger jump from existing C practice.
>
> Ok, first of all the "smaller change" (TR 24731) will give you a
> smaller benefit. The buffer overflow issue in this proposal relies on
> an accurate synchronization of the buffer size with the extra rsize_t
> parameter.
>
> As we all know buffer overflows themselves come from lazy, or just poor
> programming in general.

NO!!! I consider myself a professional programmer, and I've hired
any number of professional programmers over the past several decades.
We all generate buffer overflows from time to time. I know I'm
neither poor nor lazy, and I don't hire such programmers.
IM(extensive)E, making buffer size decisions more visible is a
genuine aid to competent programmers and the organizations that
check their work. Your offhand remark simply smacks of misplaced
elitism.

> One simple *lazy* thing that a programmer can
> do is pass RSIZE_MAX as the rsize_t parameter, and just proceed to use
> the library as they were using the original C functions. Of course
> this defeats the whole point, and puts you back to where you started.
> And none of this speaks to the endless kinds of "cut-and-paste" errors
> that can cause missynchronizations between the lengths. If the buffer
> comes from strange sources, or has been malloced to some dynamic
> length, then using these new library functions still require real grey
> cells to move towards anyways.

And writing in C is no improvement over writing in assembly language
if you're lazy, inattentive, and sloppy. Your point is then?

> David's proposal has a lot of merit to it -- the size of the buffer is
> associated with the buffer, so why not just stick the two in struct?

I haven't seen a "proposal" yet, just a few off-the-cuff remarks
in a newsgroup.

> .....
>> [...] That raises the cost of
>> retrofitting code, and lowers the chance that subgroups will budget
>> to do it.
>
> I'm not sure David's approach is actually a *bigger jump*, since he
> doesn't need to add in extra parameters synchronized to some other
> magical value in the source.

Well I am.

>> [...] Maybe you can come up with a better design than Microsoft's,
>> but they at least did this experiment on a rather large scale and
>> then saw fit to share their results with the rest of us.
>
> Right, so you are saying that as a barrier to entry, anyone who has an
> idea has to get themselves 7 million lines of code ported to it?

Nope, I'm saying that as a barrier to entry, anyone who has an idea
has to prepare a sufficiently detailed proposal that:

a) WG14 will feel moved to request a New Work Item from SC22

b) about five National Bodies will commit to providing experts
to work on the project

c) SC22 will feel moved to approve the NWI, and

d) the proposer will come to meetings for a few years to shepherd
the work through to approval.

Of course, if you can demonstrate that you've converted a few tons
of code to advantage that can only help with a) and b), but it's
not a requirement (and I don't see how you can parse my words to
say that it is).

> I don't know anything about the process of getting something proposed
> to the ISO C standard, and I have no idea how receptive the committee
> is, but I've had a solution to the *string* problem for some time now:
>
> http://bstring.sf.net/ ("The Better String Library" / "Bstrlib")

Well, now you know what to do.

> .....
> I've been told twice to consider the possibility of submitting Bstrlib
> to the ISO standard. I wouldn't ordinarily bother, except it looks to
> me like ISO is going to go down a really suboptimal path with this TR
> 24731 proposal. Is this something I can/should do? Or do I need to
> port 7 million lines of code to it first?

Oh, let go of that straw man. Do it, or don't do it, but stop whingeing
that it ain't getting done.

> But on the issue of straight security, no more will be accomplished by
> adding secure paths, than can be accomplished by removing insecure
> paths. Besides the gets() function, there are a number of
> non-reentrant functions that you are trying to move programmers away
> from with TR 24731. Is there going to be consideration for deprecating
> those functions? You can built up a star wars defence shield, or you
> can just get rid of the nukes.

And there are a host of sane options in between.

> (The tmpnam(_s) issue that David brings up sounds complicated. To make
> sure there's no window in which an asynchronous action between fclose()
> and unlink() could take place, it means you have to give tmpnam(_s)
> sematics close to tmpfile(_s), where the file is deleted upon closing
> (or in Unix, its deleted as its opened.) But that changes it
> fundamentally, and so I don't know exactly what semantics are desired
> from tmpnam(_s). To know the file name, you are practically giving up
> on atomicity of the file over the lifetime of the program anyways -- so
> why isn't tmpfile(_s) really what you want? I.e., if a tmpfile_ex()
> function were designed that also popped out a filename, how would you
> ever use that filename given that the file will be deleted before you
> can do anything useful with that filename? I think, perhaps, I don't
> understand the issue.)

Uh huh, it's a complicated one.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


.

Relevant Pages

  • Re: Attention Windows Users
    ... A longer answer will include the fact that until recently, security just ... wasn't an issue that most programmers worried about. ... checked rigorously because a specification for the use of a buffer defines ... It's going to take a long time for all of the flaws in that ...
    (rec.aviation.piloting)
  • Re: Secure C library
    ... I read much of the new "security TR", and gee, I don't know. ... the buffer from the buffer size. ... It is not hard to design a better form of buffer and string handling. ... but this is just one example of how thoughtful interface design can ...
    (comp.std.c)
  • Re: Programming skills for Pen Testers
    ... each language has its own subset of security ... To elaborate further on the subject, figure that knowing about buffer ... programming does not inevitably take part of a pen-test. ... Download FREE Whitepaper "Role of Network Behavior Analysis and Response ...
    (Pen-Test)
  • [NT] Trend Micro ServerProtect Multiple Buffer Overflow Vulnerabilities
    ... Get your security news from a reliable source. ... Trend Micro ServerProtect Multiple Buffer Overflow Vulnerabilities ... The Trend ServerProtect service handles RPC requests on TCP ...
    (Securiteam)
  • [Full-disclosure] [NETRAGARD-20061109 SECURITY ADVISORY] [HP Tru64 libpthread buffer overflo
    ... The pthread library (libpthread) provides interfaces for developing ... crafted buffer and inserting it into the PTHREAD_CONFIG variable. ... managed security services which enable its clients to take a proactive ... provided in this advisory. ...
    (Full-Disclosure)