Re: Clearing sensitive in-memory data in perl
On 2005-09-18, Ian G wrote: Greg Black wrote: The problem is bad programmers. No, the problem is good programmers. When K R wrote C in the early 70s K R did not write C, they wrote a book about C. R was the creator of the language, with some inspiration and collaboration from some others at Bell Labs, mainly Ken Thompson. For the history, see DMR's paper The Development of the C Language at http://cm.bell-labs.com/cm/cs/who/dmr/chist.html. Re the book, BWK wrote the descriptive part and DMR wrote the appendix that described the language. Not surprisingly, BWK's part has most of the real errors (as distinct from typos). , programming was a real heavy duty science, and K R were in a place which was one of the meccas of the art. They wrote a language for not only good programmers, but for great programmers. Dennis wrote C for Ken (and for his own amusement). It was adopted by other people at Bell when they saw how useful it was and escaped for the same reason. Their world is not the world we live in Indeed it's not. In particular, our world has bad guys and cheap, powerful hardware with no constraints on memory or particular needs for efficiency. If somebody like Ritchie sat down today to write a new language to replace C, then it would indeed be different and people with real work to do might even switch to it. But not one language that has appeared since C is as useful and every language that has appeared since then has had significant disadvantages in comparison. The only languages that strike me as being in any way comparable are the Lisp family -- but they are useless for system programming, and so people like me tend to stick to C since it can do everything. (Of course, I use other languages as well; but C is the basis of everything I do.) PS: if one is forced to use C, what is the best recommendation for string / array processing? One is never /forced/ to use C. One chooses the tools to best do the job. One day, I'll package up my string library, which would then be my recommendation. As it is now, it's used in quite a few places where I have consulted (since working with software teams almost always involves teaching them to use C effectively). The only string library that I'm aware of that's freely available is Dan Bernstein's stralloc[1] library and its array library[2] successor: [1] http://cr.yp.to/lib/stralloc.html [2] http://cr.yp.to/lib/array.html These both have disadvantages common to all DJB code: weird licensing, unreadable style, and somewhat fanatic admiration of his own work in preference to all other work. However, for somebody wanting some ideas for implementation of their own library, these might make a useful starting point. Bear in mind that, even though we are not all Ritchies, those of us who work with software can learn to use sharp tools if we take the time to do it and put in the work required. If that's really too much, then there are always buses that need drivers. Greg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Generally speaking, I think software with a security impact should not be written in C. Hooey. The C language is not the problem. The C library is not the problem. Both of these things were fixed during ANSI standardization, so that standard-conforming programs will not fail runtime checks for overrunning arrays (strings are just arrays of characters). There have been various C implementations that did these checks, including both compilers and interpreters. Some are free, some are proprietary. (I proposed to fund adding these checks to GCC, but the price I was quoted was too high for me.) I fault the people who don't use such tools -- not the C language. (Aside: What ever happened to Saber C? Oh, it was renamed to Centerline CodeCenter, never made it out of the Unix workstation market, used FlexLM per-cpu licensing crap, has gone morbid, and was acquired a year ago by ICS.com, a graphics library company, with a promise to port it to Linux. There's no evidence of such a port, and the product support matrix was last updated in June 2001. The product doesn't appear on ICS's product pages. I wonder how cheaply the source could be bought and freed up, to bring it back to life? It was a nice product, fifteen years ago.) The reason there's fewer security bugs in PL/1 programs than C programs is because almost nobody has written programs in PL/1 since about 1985. Google did find me a compiler you can download -- it runs on VMS, on Vaxes or Alphas. Anybody still running those space-heaters is welcome to program in PL/1. The rest of us have real work to do, and it's likely to get done in C or C++. John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Victor Duchovni wrote: On Thu, Sep 15, 2005 at 08:51:02PM -0700, Bill Frantz wrote: On 9/13/05, [EMAIL PROTECTED] (Perry E. Metzger) wrote: Generally speaking, I think software with a security impact should not be written in C. I agree. I also note that Paul A. Karger and Roger R. Schell, in their paper, Thirty Years Later: Lessons from the Multics Security Evaluation state: While some of the fault is perhaps in the core language, my contention is that the real problem is the anemic standard C-library. When working on C projects that have (and uniformly use) their own mature string handling libraries (I was a contributor to Tcl in the 90's and am now working in Postfix) I found that buffer overflows (and with Tcl for reasons I won't go into here also memory leaks) were a non-issue in those systems. With either Tcl_DString or VSTRING (Postfix), one simply loses the habit of needing to keep track of buffer lengths. When combined with a compatible I/O interface (say VSTREAM), argument vector library (ARGV) hash table library, ... one no longer in practice manipulates bare null-terminated string buffers except when passing (usually read-only) content to system calls via the C-library. I continue to write code in C, free of buffer overflows and memory leaks, not because I am more manly than the next programmer, but because I am attracted to working on well-designed systems, whose designers took the time to develop a richer set of idioms in which to construct their work. My view is that C is fine, but it needs a real library and programmers who learn C need to learn to use the real library, with the bare-metal C-library used only by library developers to bootstrap new safe primitives. So wouldn't the world be a better place if we could all agree on a single such library? Or at least, a single API. Like the STL is for C++. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Sat, Sep 17, 2005 at 11:53:20AM +0100, Ben Laurie wrote: My view is that C is fine, but it needs a real library and programmers who learn C need to learn to use the real library, with the bare-metal C-library used only by library developers to bootstrap new safe primitives. So wouldn't the world be a better place if we could all agree on a single such library? Or at least, a single API. Like the STL is for C++. Yes, absolutely, but who is going to do it? -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Sat, Sep 17, 2005 at 11:40:26AM -0400, Victor Duchovni wrote: | On Sat, Sep 17, 2005 at 11:53:20AM +0100, Ben Laurie wrote: | | My view is that C is fine, but it needs a real library and programmers | who learn C need to learn to use the real library, with the bare-metal | C-library used only by library developers to bootstrap new safe | primitives. | | So wouldn't the world be a better place if we could all agree on a | single such library? Or at least, a single API. Like the STL is for C++. | | | Yes, absolutely, but who is going to do it? The glibc people? The openbsd people? I recall that for a while if you used gets, the linker would complain. I can't recall what platform this was on. BSDi, maybe? Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Victor Duchovni wrote: So wouldn't the world be a better place if we could all agree on a single such library? Or at least, a single API. Like the STL is for C++. Yes, absolutely, but who is going to do it? One could argue it has already been done. There exists a widely available, freely available, well-implemented example of something just like the STL for C++. It is called the STL for C++. a) Writing in C++ is easier than writing in C. b) Porting legacy C to C++ isn't rocket surgery. It can be done incrementally. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
[Moderator's note: forwarded on Jerry's behalf -- he's having mail problems.] | So wouldn't the world be a better place if we could all agree on a | single such library? Or at least, a single API. Like the STL is for C++. | | | | Yes, absolutely, but who is going to do it? | | One could argue it has already been done. | | There exists a widely available, freely available, well-implemented | example of something just like the STL for C++. It is called | the STL for C++. | | a) Writing in C++ is easier than writing in C. | | b) Porting legacy C to C++ isn't rocket surgery. It can be done | incrementally. And the STL is safer than C ... in what sense? STL iterators are modeled on C pointers - warts and all. An STL iterator can point to random memory just as easily as a C pointer. An indexing operation into an STL vector or similar data structure is subject to exactly as much range checking as a C indexing operation. Yes, there exist implementations of the STL that check such things - just as there exist implementations of C that check such things. None appear to be widely used. And, of course, while no standard *forbids* such checks, none *require* them, so (a) availability is spotty; (b) compilers typically contain no optimizations aimed at making such things efficient. RISKS had a large number of messages on this topic back in 2002. I wrote one long commentary (in RISKS 21.85 - see http://catless.ncl.ac.uk/Risks/21.85 for one on-line source) that I stand by to this day. Very little has changed. (Actually, there has been a *bit* of improvement: Microsoft submitted a proposal for a set of new string - and related - functions for standardization in the C library. They differ from the classic functions in always having an explicit output buffer length. Personally, I find the particular API typical of Microsoft - butt-ugly and a pain to use - and I *think* that the standards groups may be re-working them. But one way or another, after all these years, we may eventually have safe alternatives - once we work throught the standardization process and get the stuff out there (I'd guess another 2 years at least before you can safely assume that it'll be available). -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Adam Shostack wrote: On Sat, Sep 17, 2005 at 11:40:26AM -0400, Victor Duchovni wrote: | On Sat, Sep 17, 2005 at 11:53:20AM +0100, Ben Laurie wrote: | | My view is that C is fine, but it needs a real library and programmers | who learn C need to learn to use the real library, with the bare-metal | C-library used only by library developers to bootstrap new safe | primitives. | | So wouldn't the world be a better place if we could all agree on a | single such library? Or at least, a single API. Like the STL is for C++. | | | Yes, absolutely, but who is going to do it? The glibc people? The openbsd people? I recall that for a while if you used gets, the linker would complain. I can't recall what platform this was on. BSDi, maybe? gets is so not the problem. Using strings that _can_ overflow is the problem. That means wrapping the entire standard library. And, of course, the issue is that every other library in the universe uses C-style strings (etc.), so unless we can all agree on a better paradigm, we're screwed. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Sat, Sep 17, 2005 at 08:36:11PM +0100, Ben Laurie wrote: | Adam Shostack wrote: | On Sat, Sep 17, 2005 at 11:40:26AM -0400, Victor Duchovni wrote: | | On Sat, Sep 17, 2005 at 11:53:20AM +0100, Ben Laurie wrote: | | | | My view is that C is fine, but it needs a real library and programmers | | who learn C need to learn to use the real library, with the bare-metal | | C-library used only by library developers to bootstrap new safe | | primitives. | | | | So wouldn't the world be a better place if we could all agree on a | | single such library? Or at least, a single API. Like the STL is for | C++. | | | | | | Yes, absolutely, but who is going to do it? | | The glibc people? The openbsd people? | | I recall that for a while if you used gets, the linker would | complain. I can't recall what platform this was on. BSDi, maybe? | | gets is so not the problem. Using strings that _can_ overflow is the | problem. That means wrapping the entire standard library. | | And, of course, the issue is that every other library in the universe | uses C-style strings (etc.), so unless we can all agree on a better | paradigm, we're screwed. I didn't mean to imply that gets was the issue, only that when your linker laughed at you for trying to use a function, it was an encouragement to move to other functions. That is it possible to get people to move, when there's something to move to. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Ben Laurie wrote: gets is so not the problem. Using strings that _can_ overflow is the problem. That means wrapping the entire standard library. And, of course, the issue is that every other library in the universe uses C-style strings (etc.), so unless we can all agree on a better paradigm, we're screwed. note that various infrastructures ... have made the length field an integral characteristic of nearly every piece of storage and that automatic use the length values an integral piece of every operation; extended from the lowest level interrupt handlers and device drivers ... up thru the most complex application code. it isn't just a characteristic of the high level application libraries ... but nearly every aspect of the operation environment. these length-based paradigms aren't only limited to programming languages (other than C) ... but can also be found in infrastructures that are pure assembler code. the other way of viewing the string issue is that the length isn't explicit ... the default c-based length paradigm is implicit based on the pattern of data in a buffer ... which tends to create length related vulnerabilities from simple data manipulation operations (you might generalize this as a dual-use vulnerability). this is further compounded when there is a field/buffer that is empty and doesn't yet have any data to establish an implicit data-pattern defined length. explicitly separating the length attribute from any data pattern characteristic would make the infrastructure less vulnerable to length mistakes resulting from simple data manipulation operations. it would also enable a single, consistant length paradigm for both field/buffers that contain data patterns and field/buffers that are empty and don't contain data patterns. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On 2005-09-17, Jerrold Leichter wrote (without retaining attributions): So wouldn't the world be a better place if we could all agree on a single such library? Or at least, a single API. Like the STL is for C++. Yes, absolutely, but who is going to do it? One could argue it has already been done. It (the creation of such a library) has been done many times; admittedly, widespread adoption has not happened at all. There exists a widely available, freely available, well-implemented example of something just like the STL for C++. It is called the STL for C++. a) Writing in C++ is easier than writing in C. Only for people who find it easier to use a huge clunky tool they will never fully know than a clean simple language which can be used to write completely reliable software. Of course, C's simplicity is its danger: any idiot who can spend a few hours with a C for Dummies kind of book can imagine that he's competent to write in C. As with any sharp tool, careful use is mandatory to avoid nasty cuts; thorough understanding is needed to ensure safe handling. We don't expect people to fly commercial aircraft without taking the time to become suitably skilled. We don't expect people to start doing brain surgery without having appropriate training. Software is complex stuff; it takes time to acquire skills with it. For those with the skills, C is an excellent tool. It's not perfect, but it's the best thing we have and it's well able to do the things we ask of it. The problem is bad programmers. b) Porting legacy C to C++ isn't rocket surgery. It can be done incrementally. And the STL is safer than C ... in what sense? STL iterators are modeled on C pointers - warts and all. An STL iterator can point to random memory just as easily as a C pointer. An indexing operation into an STL vector or similar data structure is subject to exactly as much range checking as a C indexing operation. Yes, there exist implementations of the STL that check such things - just as there exist implementations of C that check such things. None appear to be widely used. And, of course, while no standard *forbids* such checks, none *require* them, so (a) availability is spotty; (b) compilers typically contain no optimizations aimed at making such things efficient. Agreed, the STL (and C++) is no answer. RISKS had a large number of messages on this topic back in 2002. I wrote one long commentary (in RISKS 21.85 - see http://catless.ncl.ac.uk/Risks/21.85 for one on-line source) that I stand by to this day. Very little has changed. While you make some valid points in that article, I take issue with much of it. For instance, you cite [a] large body of code that provides bad examples as one of the big faults with C. This is just not a valid argument. (Yes it's true: there is such a body of code, but it's not an argument.) The classic book of examples of bad programming, The Elements of Programming Style by Kernighan and Plauger, dates back to the days before C. Its examples are in Fortran and PL/1. It is full of the same kind of blunders we are talking about here. It's not the language, it's the programmers who are at fault. The only reason that we see much in C is that, for the past 25 years, most widely-seen software has been written in C. (Actually, there has been a *bit* of improvement: Microsoft submitted a proposal for a set of new string - and related - functions for standardization in the C library. They differ from the classic functions in always having an explicit output buffer length. Personally, I find the particular API typical of Microsoft - butt-ugly and a pain to use - and I *think* that the standards groups may be re-working them. But one way or another, after all these years, we may eventually have safe alternatives - once we work throught the standardization process and get the stuff out there (I'd guess another 2 years at least before you can safely assume that it'll be available). I haven't followed any news about that. Anything that comes out of Microsoft won't be worth considering -- nothing from there has been good in the past, so there's no reason to think that might change. More to the point, it takes many years before stuff like that becomes widely available (and therefore usable). We don't need new tools; we just to learn to use the ones we have effectively. The comments you make about seat belt and air bags don't make much sense either. Their purpose is to save our lives after we have made a potentially fatal mistake. After all, there's a big mess to clean up when those things are used, so it's not like we want them to play an active part. This is also a question of culture. Everybody thinks they have the right to drive but no responsibility to learn how to do it well. So, since bad driving causes so many deaths, governments mandate all sorts of after-the-accident safety gadgets. If they mandated proper skill and attitude
Re: Clearing sensitive in-memory data in perl
-- Ben Laurie [EMAIL PROTECTED] And, of course, the issue is that every other library in the universe uses C-style strings (etc.), so unless we can all agree on a better paradigm, we're screwed. We have a better paradigm: C++ Use const zero terminated strings where possible, use STL strings where they must be non const. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG nsfA32EGEKM0cU+MepqW0siOwFXqhO6L4ObDt/5P 4n7mr1z57RP4q1W6q39DjzRerUpSJz4w3SYQPtVCh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On 9/13/05, [EMAIL PROTECTED] (Perry E. Metzger) wrote: Generally speaking, I think software with a security impact should not be written in C. I agree. I also note that Paul A. Karger and Roger R. Schell, in their paper, Thirty Years Later: Lessons from the Multics Security Evaluation state: 2.3.1 Programming in PL/I for Better Security Multics was one of the first operating systems to be implemented in a higher level language.(1) While the Multics developers considered the use of several languages, including BCPL (an ancestor of C) and AED (Algol Extended for Design), they ultimately settled on PL/I [15]. Although PL/I had some influence on the development of C, the differences in the handling of varying length data structures between the two languages can be seen as a major cause of buffer overflows. In C, the length of all character strings is varying and can only be determined by searching for a null byte. By contrast, PL/I character strings may be either fixed length or varying length, but a maximum length must always be specified, either at compile time or in an argument descriptor or in another variable using the REFER option. When PL/I strings are used or copied, the maximum length specifications are honored by the compiled code, resulting in automatic string truncation or padding, even when full string length checking is not enabled. The net result is that a PL/I programmer would have to work very hard to program a buffer overflow error, while a C programmer has to work very hard to avoid programming a buffer overflow error. Multics added one additional feature in its runtime support that could detect mismatches between calling and called argument descriptors of separately compiled programs and raise an error. PL/I also provides richer features for arrays and structures. While these differences are not as immediately visible as the character string differences, an algorithm coded in PL/I will have less need for pointers and pointer arithmetic than the same algorithm coded in C. Again, the compiler will do automatic truncation or padding, even when full array bounds checking is not enabled. While neither PL/I nor C are strongly typed languages and security errors are possible in both languages, PL/I programs tend to suffer significantly fewer security problems than the corresponding C programs. (1) Burroughs’ use of ALGOL for the B5000 operating system was well known to the original Multics designers. 15. Corbató, F.J., PL/I As a Tool for System Programming. Datamation, May 1969. 15(5): p. 68-76. URL: http://home.nycap.rr.com/pflass/plisprg.htm Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Thu, Sep 15, 2005 at 08:51:02PM -0700, Bill Frantz wrote: On 9/13/05, [EMAIL PROTECTED] (Perry E. Metzger) wrote: Generally speaking, I think software with a security impact should not be written in C. I agree. I also note that Paul A. Karger and Roger R. Schell, in their paper, Thirty Years Later: Lessons from the Multics Security Evaluation state: While some of the fault is perhaps in the core language, my contention is that the real problem is the anemic standard C-library. When working on C projects that have (and uniformly use) their own mature string handling libraries (I was a contributor to Tcl in the 90's and am now working in Postfix) I found that buffer overflows (and with Tcl for reasons I won't go into here also memory leaks) were a non-issue in those systems. With either Tcl_DString or VSTRING (Postfix), one simply loses the habit of needing to keep track of buffer lengths. When combined with a compatible I/O interface (say VSTREAM), argument vector library (ARGV) hash table library, ... one no longer in practice manipulates bare null-terminated string buffers except when passing (usually read-only) content to system calls via the C-library. I continue to write code in C, free of buffer overflows and memory leaks, not because I am more manly than the next programmer, but because I am attracted to working on well-designed systems, whose designers took the time to develop a richer set of idioms in which to construct their work. My view is that C is fine, but it needs a real library and programmers who learn C need to learn to use the real library, with the bare-metal C-library used only by library developers to bootstrap new safe primitives. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Victor Duchovni wrote: While some of the fault is perhaps in the core language, my contention is that the real problem is the anemic standard C-library. When working on C projects that have (and uniformly use) their own mature string handling libraries (I was a contributor to Tcl in the 90's and am now working in Postfix) I found that buffer overflows (and with Tcl for reasons I won't go into here also memory leaks) were a non-issue in those systems. With either Tcl_DString or VSTRING (Postfix), one simply loses the habit of needing to keep track of buffer lengths. When combined with a compatible I/O interface (say VSTREAM), argument vector library (ARGV) hash table library, ... one no longer in practice manipulates bare null-terminated string buffers except when passing (usually read-only) content to system calls via the C-library. I continue to write code in C, free of buffer overflows and memory leaks, not because I am more manly than the next programmer, but because I am attracted to working on well-designed systems, whose designers took the time to develop a richer set of idioms in which to construct their work. My view is that C is fine, but it needs a real library and programmers who learn C need to learn to use the real library, with the bare-metal C-library used only by library developers to bootstrap new safe primitives. I've frequently observed in the past that some assembler language environments have also had very pervasive use of explicit lengths associated with most operations, system functions, and library routines resulted in very low frequency of buffer overflows ... some amount of collected past posts on the subject ... including the 30 years later article (when it first came out) http://www.garlic.com/~lynn/subpubkey.html#overflow minor connection the 30 years later article is about multics which was done on the 5th floor of 545 tech sq ... and some of the assembler stuff that i'm familiar with was done on the 4th floor (slight disclaimer i was on the 4th flr for some amount of the period) http://www.garlic.com/~lynn/subtopic.html#545tech some of the early stuff done on the 4th floor ... also was adapted to some number of commercial time-sharing services which had some fairly stringent integrity requirements http://www.garlic.com/~lynn/subtopic.html#timeshare - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Perry E. Metzger wrote: What the world really needs is something between C++ and C -- a language with very clean obvious semantics (like C) which does run time bounds checking and strong typing, though it also needs explicit escapes in the type system so you can write things like device drivers in it. It probably also should not require run time garbage collection, if only so kernel code can be written in it. Cyclone. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On 9/11/05, Jason Holt [EMAIL PROTECTED] wrote: Securely deleting secrets is hard enough in C, much less high level languages. But, but..Java is the be-all end-all! Three years ago I advised a business/tech guy to avoid Java for crypto and related purposes. I'll revise that somewhat in light of greater experience and developments: Java is ok if you control the platform it's running on and if the programmers were very careful. In practice, that means I'd be willing to do the server-side programming in Java if I (or my employer or client) controlled the server. I'm not happy about doing client-side programming in Java for arbitrary users, but users in a controlled business environment is ok. From a user's perspective, I'd be _really_ cautious about using a crypto app written in Java. FWIW, lately I've been earning my daily bread with Java server-side programming. Fortunately for me, it's been mostly crap work, where it doesn't really matter if data leaks or someone cracks in. Considering that I don't control any of the J2EE or database servers and for the most part they're administered by poorly-trained monkeys, I'd have a really tough ethical call if my clients wanted me to do some work where security really mattered. -- There are no bad teachers, only defective children. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
In message [EMAIL PROTECTED], Steve Furlong writes: On 9/11/05, Jason Holt [EMAIL PROTECTED] wrote: Securely deleting secrets is hard enough in C, much less high level language s. But, but..Java is the be-all end-all! Three years ago I advised a business/tech guy to avoid Java for crypto and related purposes. I'll revise that somewhat in light of greater experience and developments: Java is ok if you control the platform it's running on and if the programmers were very careful. In practice, that means I'd be willing to do the server-side programming in Java if I (or my employer or client) controlled the server. I'm not happy about doing client-side programming in Java for arbitrary users, but users in a controlled business environment is ok. From a user's perspective, I'd be _really_ cautious about using a crypto app written in Java. FWIW, lately I've been earning my daily bread with Java server-side programming. Fortunately for me, it's been mostly crap work, where it doesn't really matter if data leaks or someone cracks in. Considering that I don't control any of the J2EE or database servers and for the most part they're administered by poorly-trained monkeys, I'd have a really tough ethical call if my clients wanted me to do some work where security really mattered. There's an interesting tradeoff here: which is a bigger threat, crypto secrets lying around memory or buffer overflows? What's your threat model? For the average server, I suspect you're better off with Java, especially if you use some of its client-side security mechanisms to lock down the server. Under some circumstances, you could do a call-out to a C module just for the crypto, but it's by no means obvious that that's a major improvement. Again -- what is your threat model? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On 9/13/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: There's an interesting tradeoff here: which is a bigger threat, crypto secrets lying around memory or buffer overflows? What's your threat model? For the average server, I suspect you're better off with Java, especially if you use some of its client-side security mechanisms to lock down the server. Under some circumstances, you could do a call-out to a C module just for the crypto, but it's by no means obvious that that's a major improvement. Again -- what is your threat model? Other important questions for programmers are, how good are you? How good does the process allow you to be? My answers are, I'm quite a good programmer. (Pardon the ego.) I'm careful and methodical and very seldom have buffer overruns or unfreed memory even in my first drafts. For me, my expected code quality in C and C++ is balanced against the black box behaviour of Java's runtime engine. (To be clear: I don't suspect Sun of putting back doors in their engine.) And I'm experienced enough and old enough that I can hold my own in pissing contests with project managers who want to cut corners in order to ship a day earlier. Implementation quality could be considered in the threat model. I've generally taken the programmers into account when designing a system, but I hadn't explicitly thought of well-meaning-but-incompetent programmers as part of the threat. Guess I should. -- There are no bad teachers, only defective children. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Steve Furlong [EMAIL PROTECTED] writes: On 9/13/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: There's an interesting tradeoff here: which is a bigger threat, crypto secrets lying around memory or buffer overflows? What's your threat model? For the average server, I suspect you're better off with Java, especially if you use some of its client-side security mechanisms to lock down the server. Under some circumstances, you could do a call-out to a C module just for the crypto, but it's by no means obvious that that's a major improvement. Again -- what is your threat model? Other important questions for programmers are, how good are you? How good does the process allow you to be? My answers are, I'm quite a good programmer. (Pardon the ego.) I'm careful and methodical and very seldom have buffer overruns or unfreed memory even in my first drafts. For me, my expected code quality in C and C++ is balanced against the black box behaviour of Java's runtime engine. I think you're wrong to operate on the assumption that even a very good programmer can be more vigilant against buffer overflows than a language that performs bounds checking. Even extremely good programmers are human beings. I think I'm a very good programmer, but I make mistakes, and in security, mistakes cost big time. There is also the question of leverage -- if there is a bug in a bounds checker in a language implementation, fixing it stops huge numbers of bugs people didn't know about. Fixing buffer overflow bugs in a C program helps only that program. Generally speaking, I think software with a security impact should not be written in C. What the world really needs is something between C++ and C -- a language with very clean obvious semantics (like C) which does run time bounds checking and strong typing, though it also needs explicit escapes in the type system so you can write things like device drivers in it. It probably also should not require run time garbage collection, if only so kernel code can be written in it. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Tue, Sep 13, 2005 at 11:32:45AM -0400, Perry E. Metzger wrote: What the world really needs is something between C++ and C -- a language with very clean obvious semantics (like C) which does run time bounds checking and strong typing, though it also needs explicit escapes in the type system so you can write things like device drivers in it. It probably also should not require run time garbage collection, if only so kernel code can be written in it. There's been work on secure dialects of C. Cyclone (http://www.eecs.harvard.edu/~greg/cyclone) is one. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
Steve Furlong wrote: Other important questions for programmers are, how good are you? How good does the process allow you to be? My answers are, I'm quite a good programmer. (Pardon the ego.) I'm careful and methodical and very seldom have buffer overruns or unfreed memory even in my first drafts. For me, my expected code quality in C and C++ is balanced against the black box behaviour of Java's runtime engine. (To be clear: I don't suspect Sun of putting back doors in their engine.) And I'm experienced enough and old enough that I can hold my own in pissing contests with project managers who want to cut corners in order to ship a day earlier. Implementation quality could be considered in the threat model. I've generally taken the programmers into account when designing a system, but I hadn't explicitly thought of well-meaning-but-incompetent programmers as part of the threat. Guess I should. note that compared to some other languages a lot of C-language buffer overflows can be attributed to C requiring the programmer to keep track and manage various lengths (where in some number of other languages, buffer length characteristics are built into basic object characteristics and operations). i know of at least one production implemented tcp/ip stack done in pascal ... which had no known buffer related problems compared to the possibly hundreds of thousands that have appeared in c-language based implementations. large collection of past posts on buffer overflow related vulneabilities http://www.garlic.com/~lynn/subpubkey.html#overflow part of the issue is that there are hundreds of thousands of applicantations being written ... with possibly only a couple hundred mistake-free, careful programmers available world-wide. a possible solution is to create a time-machine that allows for the limited number of mistake-free, careful programmers to have several thousand hour work days (along with the medical support to allow them to never sleep). there are separate class of vulnerabilities related to dangling buffer pointers and syncronization problems ... which are common to languages that place the burden of allocation/deallocation burden on the programmer (however, that is a distinct vulneability from c-language placing burden of length management on the programmer ... and the resulting mistakces). some languages like apl ... large collection of past apl posts http://www.garlic.com/~lynn/subtopic.html#hone have abstracted both object length characteristics as well as storage allocation/deallocation operations. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Mon, 12 Sep 2005, Sidney Markowitz wrote: Does anyone know of an open source crypto package written in perl that is careful to try to clear sensitive data structures before they are released to the garbage collector? [...] Securely deleting secrets is hard enough in C, much less high level languages. I've often considered trying to write a C-based module for secret storage, but it's problematic (although the Taint stuff looks promising) and to my knowledge has never been done. -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Clearing sensitive in-memory data in perl
Does anyone know of an open source crypto package written in perl that is careful to try to clear sensitive data structures before they are released to the garbage collector? Failing that, does anyone know of an example that tries to deal with the particularly bad effect that at least on some perl platforms writing to a tied DB_File results in data from garbage collected strings appearing in the unused space between the logical end of file and the end of the allocated disk block? And failing that, how about a reference to how one would go about preventing leaking sensitive information in garbage collected strings when writing in perl. Google and reading perl documentation hasn't helped me so far, but I find it hard to believe that this has not been considered when writing crypto software in perl. Thanks, Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
