Re: [Caml-list] stl?

[Richard Jones <rich@annexia.org>]

On Thu, Mar 05, 2009 at 01:49:01PM +0300, malc wrote:
> You lost me here.

Look at the patch I linked to [1].

> > - (Possibly) handling 32 and 64 bit quantities.
> 
> Not possibly, definitely (in case of better being applied to current
> implementation of OCaml)

I'm not sure I mentioned OCaml, just a high level language.  Anyway
you can't make an argument about low level languages being better and
then arbitrarily restrict my choice of high level language based on
your definition of "current implementation".  What does that mean?
Only things published by INRIA?  Maybe we shouldn't be allowed to use
anything but the standard library too, to make this more "fair"
towards low level languages?

> > CVE-2008-0928:
> > | Qemu 0.9.1 and earlier does not perform range checks for block device
> > | read or write requests, which allows guest host users with root
> > | privileges to access arbitrary memory and escape the virtual machine.
> 
> I don't see how C per se is at fault here.

Lack of a bounds check has _everything_ to do with C being at fault.
The fact that this allows you to try out root exploits against the
host from a guest is also everything to do with C.

http://marc.info/?l=debian-security&m=120343592917055&w=2

> > CVE-2008-5714
> > | Fix off-by-one bug limiting VNC passwords to 7 chars 
> > (Problem in C's sizeof:
> > http://lists.gnu.org/archive/html/qemu-devel/2008-11/msg01224.html )
> 
> The problem is not C's sizeof but the one who used it.

The problem is entirely with C.  These fencepost errors to do with
sizeof and strlen are frequent causes of errors in C.  How many C
programmers can honestly claim they haven't written this sort of thing
at least once in their lives:

  buf = malloc (strlen (str));
  strcpy (buf, str);

Referring back to the original patch, in a high level language it
wouldn't be necessary to pass a string + length into a function,
because in a high level language we'd assume the function can just
allocate a string of the required size.  For this password case we
would pass in the desired maximum length, so just the number '8'.
_Far_ more obvious and less error prone.

It's 2009, we shouldn't expect programmers to have to think about such
stupid low-level stuff, and we shouldn't expect reviewers to check for
it.

Do you know how expensive it is to fix these security isses?

Each one requires hundreds of man-hours building and validating
packages, and then sending them out to sysadmins at all our customers
who individually verify and install them.  This is a vast undertaking
which swamps the minute % increase in performance that C may (or even
may not) give you.

> > CVE-2007-1366
> > | QEMU 0.8.2 allows local users to crash a virtual machine via the
> > | divisor operand to the aam instruction, as demonstrated by aam 0x0,
> > | which triggers a divide-by-zero error.
> 
> Well this has nothing to do with C, which brings us to another
> interesting point, division by zero is UB as per 6.5.5#5, OCaml
> guarantees Division_by_zero being thrown in case of second operand
> by zero and the code it generates here on PPC to provide that is
> consequently suboptimal (cmp + branch per every division)

I'm not sure what your point is.  Bounds checking introduces some tiny
overhead too.  But if you don't do it, your untrusted guests can own
your hosting service.  Fair trade-off?

Rich.

[1] http://lists.gnu.org/archive/html/qemu-devel/2009-02/txtzqRjC0boEM.txt

-- 
Richard Jones
Red Hat