Re: [Caml-list] How to secure an OCaml server

[Yutaka OIWA <oiwa@yl.is.s.u-tokyo.ac.jp>]

Hello David, 

>> On Sat, 28 Feb 2004 16:10:08 +0100, David MENTRE <dmentre@linux-france.org> said:

David> Hello,
David> I'm currently writing a server in Objective Caml. This server is using a
David> specific protocol (in XDR format) over TCP sockets.

David> I would like to secure my server against usual attacks (buffer overflow,
David> etc.).

David> While there is plenty of doc for C and C++, there is nothing for
David> OCaml. At what kind of issues should I look to avoid attacks? Has
David> anybody written a documentation or a tool to secure OCaml applications?

Programming in Objective Caml (and other "safe languages") is
relatively safe.  However, in my opinion, it is wise to care about
almost same kind of safety issues as those for C language, except
dangling pointers.

Unlike C and C++, Objective Caml has strong builtin protection for
array boundary overflow.  You can expect that inputs which usually
cause arbitrary code execution (like viruses and worms) do not cause
such catastrophe, but only make your programs report runtime exception
and then halt.  However, you should not rely on this feature in
production code, especially if you are writing your own decoders or
encoders for existing protocols.  If an encoded data packet contains
both secure and insecure data, improper handling of data length fields
in a decoding routine may cause other security problems such as data
leakage or memory exhaustion.

Dangling pointers never appear in Objective Caml program; the garbage
collector frees only unused data, unlike free() in C and delete
operator in C++. It also prevents memory leakage in many cases.

Other security issues such as sanitizing of user-input data like
username, pathname, HTML fragment, etc. should be handled carefully in
the same manner as in other languages.  The things you referred as
"plenty of doc" may help you.

In general, effective use of high-level language features such as
builtin string, list type, and user-defined datatype may reduce
cumbersome needs for boundary checking outside codec routines.  The
garbage collection helps this style of programming, since with GC
you can use those high-level data structures without fearing about
memory leakage or dangling pointers.

-- 
Yutaka Oiwa              Yonezawa Lab., Dept. of Computer Science,
      Graduate School of Information Sci. & Tech., Univ. of Tokyo.
                    <oiwa@yl.is.s.u-tokyo.ac.jp>, <yutaka@oiwa.jp>
PGP fingerprint = C9 8D 5C B8 86 ED D8 07  EA 59 34 D8 F4 65 53 61

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners