Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #67617
| 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) |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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