Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #67617

Re: How security holes happen

References <lf22t1$sgh$1@ger.gmane.org> <mailman.7670.1393885170.18130.python-list@python.org> <roy-F4C234.18050803032014@news.panix.com>
Date 2014-03-04 10:36 +1100
Subject Re: How security holes happen
From Chris Angelico <rosuav@gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.7681.1393889767.18130.python-list@python.org> (permalink)

Show all headers | View raw


On Tue, Mar 4, 2014 at 10:05 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.7670.1393885170.18130.python-list@python.org>,
>  Cameron Simpson <cs@zip.com.au> wrote:
>
>> On 03Mar2014 09:17, Neal Becker <ndbecker2@gmail.com> wrote:
>> >  Charles R Harris <charlesr.harris@gmail.com> Wrote in message:
>> > >
>> >
>> > Imo the lesson here is never write in low level c. Use modern
>> >  languages with well designed exception handling.
>>
>> What, and rely on someone else's low level C?
>
> Don't laugh.  http://c2.com/cgi/wiki?TheKenThompsonHack

I don't think malicious interference with C compilers is the issue
here, so much as the constant discovery of flaws in honestly-written C
code.

Currently, I'm porting a MUD client from C++ to Pike. On average, a
hunk of code shrinks by about 50% during the translation, mainly
because I can let memory management happen elsewhere. (Sometimes the
difference is even more dramatic. I wrote my own binary tree in the
C++ client, because the compiler I was targeting at the time didn't
provide a suitable mapping type; now, I just call on the language's
facilities, and it's more efficient and takes no code whatsoever.
That's basically one entire module eliminated.) Along the way, I'm
noticing myriad little issues around the place, where too much data
would result in something being truncated (I was careful in most
places to ensure that it couldn't blow the stack, although I certainly
wouldn't bet money that I was perfect on that score), and the
truncation could have unexpected results. Malformed data coming in
over a TCP socket would eventually consume all the buffer space and
then make the client think the other end had closed its connection.
That one I knew about and didn't care, but there were others that were
weird and esoteric and would *most likely* never happen.

Writing low level code opens you up to a huge collection of weird
behaviours that might, at best, become bug reports that you spend
hours trying to solve. At worst, they become exploits. Yes, high level
languages have their own attack vectors, but I'd much rather have the
entire python-dev team working to solve my problems than me alone :)

ChrisA

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: How security holes happen Cameron Simpson <cs@zip.com.au> - 2014-03-04 09:19 +1100
  Re: How security holes happen Roy Smith <roy@panix.com> - 2014-03-03 18:05 -0500
    Re: How security holes happen Chris Angelico <rosuav@gmail.com> - 2014-03-04 10:36 +1100
  Re: How security holes happen Andrew Cooper <root@127.0.0.1> - 2014-03-05 00:52 +0000
    Re: How security holes happen Gene Heskett <gheskett@wdtv.com> - 2014-03-04 23:27 -0500
    Re: How security holes happen 88888 Dihedral <dihedral88888@gmail.com> - 2014-03-05 18:39 -0800

csiph-web