This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFH: Annotating ELF binaries


On Mon, Nov 07, 2016 at 03:28:12PM +0100, Florian Weimer wrote:
> On 11/04/2016 07:34 PM, Richard W.M. Jones wrote:
> 
> >Also the hardening stuff often doesn't apply in safe languages, so the
> >tools you build around this shouldn't automatically assume
> >no hardening == bad; or that 'long double' or 'wchar_t' are meaningful.
> 
> Sorry, this isn't true.  As long as you don't have a bytecode
> interpreter (which is a very attractive target for code injection
> attacks, to the degree that additional hardening may not matter at
> all), even supposedly memory-safe languages have type system
> trapdoors, or perhaps they do not enforce memory safety in the
> presence of data races.  This means that many of the hardening
> settings still matter.

I did say "often".

If we take the OCaml case, then stack hardening is fairly useless
since only simple values and pointers are stored there; and racing
threads isn't possible.  (Stronger enforcement of object boundaries on
the minor heap could be a useful thing to have -- in 2015 a compiler
bug caused a CVE which allowed you to overwrite object headers on the
heap if you could cause an allocation of a certain very large size --
but by default it's not possible to over- or under-run an object
allocation.)

What you really want to know for OCaml code is whether it was compiled
with the -unsafe flag which turns off bounds checking and/or any
unsafe_* functions were called (same) or any Obj.* functions (subverts
type safety).  These would be very useful flags to have but are really
nothing to do with C hardening settings -- they are OCaml-specific and
they are "un-"hardening.  They are also source code red flags which we
already check for.

My point anyway is that OCaml code is hardened by default and you have
to take explicit steps or (in the CVE case) exploit a compiler bug to
remove that hardening.  Very different from C where even a careful and
conscientous programmer can introduce security bugs by accident even
when the compiler is working perfectly and so we have to do all this
work to add second line defenses to our C compilers.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]