What a load of nonsense here: no, I don't think we should further extend the boundaries of mathematical logic in order to avoid such bugs, and I don't think we should now change our programming habits and use the magic power of Haskell - I actually think, somebody should read the code that others program..especially if it is security related code, shouldn't anybody ?!
This is a bug which children get taught to avoid when programming and how to avoid, namely check the input, don't rely on the user entering a number between 1 and 10 even if you tell them, but check it, omg. OMG On Tuesday, 22 April 2014, 14:00, "freebsd-security-requ...@freebsd.org" <freebsd-security-requ...@freebsd.org> wrote: Send freebsd-security mailing list submissions to freebsd-security@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-security or, via email, send a message with subject or body 'help' to freebsd-security-requ...@freebsd.org You can reach the person managing the list at freebsd-security-ow...@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-security digest..." Today's Topics: 1. Re: De Raadt + FBSD + OpenSSH + hole? (Garance A Drosehn) 2. Re: De Raadt + FBSD + OpenSSH + hole? (Kimmo Paasiala) 3. Re: De Raadt + FBSD + OpenSSH + hole? (Robison, Dave) 4. Re: De Raadt + FBSD + OpenSSH + hole? (Ronald F. Guilmette) 5. Re: De Raadt + FBSD + OpenSSH + hole? (Christian Kratzer) 6. Re: De Raadt + FBSD + OpenSSH + hole? (hcoin) 7. Re: De Raadt + FBSD + OpenSSH + hole? (Ronald F. Guilmette) 8. Re: De Raadt + FBSD + OpenSSH + hole? (Ronald F. Guilmette) 9. Re: De Raadt + FBSD + OpenSSH + hole? (hcoin) ---------------------------------------------------------------------- Message: 1 Date: Mon, 21 Apr 2014 11:13:24 -0400 From: "Garance A Drosehn" <dro...@rpi.edu> To: "Jamie Landeg-Jones" <ja...@dyslexicfish.net> Cc: hc...@quietfountain.com, freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <5c4f945a-e156-4aab-8c59-1d9385be4...@rpi.edu> On 20 Apr 2014, at 23:06, Jamie Landeg-Jones wrote: > "hcoin" <hc...@quietfountain.com> wrote: > >> local variables) harms performance. It's also true doing both of these >> things would not fix the flaw that 'opened the window' onto these data. >> However it is true that doing so would make the exploit valueless as >> 'opening a window' onto erased data would reveal nothing and could erase >> trojan/virus 'hijack via code-injection then trampoline' opportunities. > > In the heartbleed case, was the bug returning stale freed memory, though? > Couldn't it just as easily have been that the over-read was returning any > other memory that the process has had allocated for other variables - data > that was still in use? The heardbleed case is totally an error in openssl, because it does not really use the system malloc/free. It mallocs a huge chunk of memory from the system when it starts up, and then it has it's own routines which manages that memory. As far as the operating system is concerned, it can't touch any of that memory, even though openssl is using it over-and-over for whatever it needs memory for. Openssl did this, of course, for performance reasons. So in the case of openssl, the problem was that the code *never* returned memory, no matter how stale and unreferenced the data was. -- Garance Alistair Drosehn = dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ------------------------------ Message: 2 Date: Mon, 21 Apr 2014 18:23:07 +0300 From: Kimmo Paasiala <kpaas...@icloud.com> To: Jamie Landeg-Jones <ja...@dyslexicfish.net> Cc: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <89978872-0943-417c-9a96-9db24e5d6...@icloud.com> Content-Type: text/plain; charset="windows-1252" On 21.4.2014, at 6.06, Jamie Landeg-Jones <ja...@dyslexicfish.net> wrote: > "hcoin" <hc...@quietfountain.com> wrote: > >> local variables) harms performance. It's also true doing both of these >> things would not fix the flaw that 'opened the window' onto these data. >> However it is true that doing so would make the exploit valueless as >> 'opening a window' onto erased data would reveal nothing and could erase >> trojan/virus 'hijack via code-injection then trampoline' opportunities. > > In the heartbleed case, was the bug returning stale freed memory, though? > Couldn't it just as easily have been that the over-read was returning any > other memory that the process has had allocated for other variables - data > that was still in use? No, the problem was another type of programming error that is endemic in C programming. It?s called failure to validate input parameters before using the input parameters or derived values from the input parameters as array indices. https://en.wikipedia.org/wiki/Bounds_checking The bug allowed an attacker to request any number of bytes from memory that followed the buffer that the client was usually allowed to access (depending on how the index was interpreted it might have been possible to request memory before the buffer as well). The part of memory that followed the buffer very probably contained some very sensitive information, possibly secret keys that were loaded in memory (memory that was constantly in use and not free()?d until the process terminates) in unprotected form (plain text essentially) for fast access during encryption and decryption. -Kimmo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140421/dc7e964d/attachment-0001.sig> ------------------------------ Message: 3 Date: Mon, 21 Apr 2014 11:06:19 -0700 From: "Robison, Dave" <david.robi...@fisglobal.com> To: <freebsd-security@freebsd.org> Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <53555e1b.1060...@fisglobal.com> Content-Type: text/plain; charset="ISO-8859-1" On 04/19/2014 18:46, Mikhail wrote: >> On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote: >>> Matt Dawson <m...@chronos.org.uk> wrote: >>> >>>> My first thought when I saw this was "ego over ethics," which says more >>>> about Theo than FreeBSD. >>> > > I believe that Theo just browbeat. Reasons? It was looooong ago, I think > very few still remember, but Theo definitely does: > > http://lists.freebsd.org/pipermail/freebsd-security/2005-March/002719.html > _______________________________________________ Theo has maliciously impacted the FreeBSD project at least twice that I can recall. Nobody should expect any less from him. -- Dave Robison Sales Solution Architect II FIS Banking Solutions 510/621-2089 (w) 530/518-5194 (c) 510/621-2020 (f) da...@vicor.com david.robi...@fisglobal.com _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ------------------------------ Message: 4 Date: Mon, 21 Apr 2014 13:39:17 -0700 From: "Ronald F. Guilmette" <r...@tristatelogic.com> To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <97711.1398112...@server1.tristatelogic.com> In message <53546795.9050...@quietfountain.com>, "hcoin" <hc...@quietfountain.com> wrote: >... It is for the community to decide whether it is 'worth it' >on a case by case basis given there is no way to prove a program >'correct' from a security perspective. I guess that I was sick that day in software school. Did I just hear you tell me that I can't prove the following program is "secure"? int main (void) { return 0; } ------------------------------ Message: 5 Date: Mon, 21 Apr 2014 23:28:26 +0200 (CEST) From: Christian Kratzer <ck-li...@cksoft.de> To: "Ronald F. Guilmette" <r...@tristatelogic.com> Cc: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <alpine.bsf.2.00.1404212324520.32...@pohjola.cksoft.de> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi, On Mon, 21 Apr 2014, Ronald F. Guilmette wrote: > > In message <53546795.9050...@quietfountain.com>, > "hcoin" <hc...@quietfountain.com> wrote: > >> ... It is for the community to decide whether it is 'worth it' >> on a case by case basis given there is no way to prove a program >> 'correct' from a security perspective. > > I guess that I was sick that day in software school. > > Did I just hear you tell me that I can't prove the following program > is "secure"? > > > int > main (void) > { > return 0; > } in an ideal world you could propably. The difficulty ist that even above seemingly trival snippet of code is run after initialization of the c runtime library and some pre processing of argc, argv. It gets more complex with c++ contstructors run before main. If gets even more complex the more software components interact in wierd and wonderfull ways. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ------------------------------ Message: 6 Date: Mon, 21 Apr 2014 16:35:26 -0500 From: "hcoin" <hc...@quietfountain.com> To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <53558f1e.1010...@quietfountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 04/21/2014 03:39 PM, Ronald F. Guilmette wrote: > > In message <53546795.9050...@quietfountain.com>, > "hcoin" <hc...@quietfountain.com> wrote: > >> ... It is for the community to decide whether it is 'worth it' >> on a case by case basis given there is no way to prove a program >> 'correct' from a security perspective. > I guess that I was sick that day in software school. > > Did I just hear you tell me that I can't prove the following program > is "secure"? > > > int > main (void) > { > return 0; > } > _______________________________________________ > Good one. There were efforts, some years ago, to prove 'software correctness' with a similar understanding of 'correct' as mathematicians have when regarding a theorem as 'true'. The alligators in the complexity swamp ate those efforts before breakfast. First you have to prove the microcode in the processors correct, then you have to prove the compilers 'correctly' translate your favorite language into machine code, then you have to prove the OS is both 'correct' and doesn't 'break' the correctness in the running application. To manage that you have to extend logical expression to manage asynchronous events, no small thing. Our logical tools are pretty bound to linear 'if then' bricks-upon-other-bricks concepts. And then, after all that is proven, the question of whether the program you wrote is 'correct' can be engaged. The new-ish language Haskell takes an 'outside the box' approach to the question, by shifting what a 'program' is to be closer to 'what should the result be' than 'what step should happen next'. There's more hope such a language could specify provably correct programs than C-ish or object-oriented cousins, but that still leaves the whole machine-language domain unaddressed. Imagine the size of a number made up of every settable option bit in the processor and support chips, and add more for each occasion the order in which those bits are set or reset matters. Each combination of those bits calls for the correctness proof to be rechecked. Even in that little program you wrote, is it a security hole if, left on the stack upon return, the perhaps unused arguments remain? Just because you're paranoid doesn't mean they really aren't after you. ------------------------------ Message: 7 Date: Mon, 21 Apr 2014 14:49:45 -0700 From: "Ronald F. Guilmette" <r...@tristatelogic.com> To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <98152.1398116...@server1.tristatelogic.com> In message <alpine.bsf.2.00.1404212324520.32...@pohjola.cksoft.de>, Christian Kratzer <ck-li...@cksoft.de> wrote: >On Mon, 21 Apr 2014, Ronald F. Guilmette wrote: >> >> In message <53546795.9050...@quietfountain.com>, >> "hcoin" <hc...@quietfountain.com> wrote: >> >>> ... It is for the community to decide whether it is 'worth it' >>> on a case by case basis given there is no way to prove a program >>> 'correct' from a security perspective. >> >> I guess that I was sick that day in software school. >> >> Did I just hear you tell me that I can't prove the following program >> is "secure"? >> >> >> int >> main (void) >> { >> return 0; >> } > >in an ideal world you could propably. The difficulty ist that even >above seemingly trival snippet of code is run after initialization of >the c runtime library and some pre processing of argc, argv. > >It gets more complex with c++ contstructors run before main. > >If gets even more complex the more software components interact in >wierd and wonderfull ways. At the risk of stating the obvious... Complexity != Impossibility I think that we need better tools. But then again, I have always thought that, and undoubtedly always will. Regards, rfg ------------------------------ Message: 8 Date: Mon, 21 Apr 2014 18:38:45 -0700 From: "Ronald F. Guilmette" <r...@tristatelogic.com> To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <99496.1398130...@server1.tristatelogic.com> In message <53558f1e.1010...@quietfountain.com>, "hcoin" <hc...@quietfountain.com> wrote: > >On 04/21/2014 03:39 PM, Ronald F. Guilmette wrote: >> >> In message <53546795.9050...@quietfountain.com>, >> "hcoin" <hc...@quietfountain.com> wrote: >> >>> ... It is for the community to decide whether it is 'worth it' >>> on a case by case basis given there is no way to prove a program >>> 'correct' from a security perspective. >> I guess that I was sick that day in software school. >> >> Did I just hear you tell me that I can't prove the following program >> is "secure"? >> >> >> int >> main (void) >> { >> return 0; >> } >> _______________________________________________ >> >Good one. Thank you. I wish that I could say that I had written that program all by myself, but... >There were efforts, some years ago, to prove 'software >correctness' with a similar understanding of 'correct' as mathematicians >have when regarding a theorem as 'true'. The alligators in the >complexity swamp ate those efforts before breakfast. Well, um, yes. >First you have to >prove the microcode in the processors correct, then you have to prove >the compilers 'correctly' translate your favorite language into machine >code, then you have to prove the OS is both 'correct' and doesn't >'break' the correctness in the running application. Sure, if one wanted to be really anal about it. But the semantics of a given C program are specified by the ANSI/ISO C standard. >The new-ish language Haskell takes an 'outside the box' approach to the ... Funny you should mention that. Just after I wrote the message to which you responded, it occured to me that I had not read anything at all about denotational senatics for about the last 20 years (and even the stuff that I did read, way back then, was probably over my head). So just today, I went and looked at the entry for "denotational semantics" in Wikipedia. That Wikipedia entry did mention one language in particular... Haskell. I guess that I'll be looking into that. (I currently know zip about Haskell, but am always eager to learn new things.) >Even in that little program you wrote, is it a security hole if, left on >the stack upon return, the perhaps unused arguments remain? I suspect that you and I have different definitions of the term "security hole". >Just because you're paranoid doesn't mean they really aren't after you. On this, at least, we agree completely. One last thought... In the aftermath of this whole OpenSSL brouhaha... which none other than Bruce Schneier publically pronounced to be a 12, on a scale from 1 to 10, in terms of awfulness... I do wonder if anyone has taken the time or effort to run the OpenSSL sources through any kind of analyzer to try to obtain some of the standard sorts of software science metrics on it. I suspect that a whole lot of folks might be either (a) red faced or else (b) deeply concerned if a scientifically derived estimate of the number of *remaining* (and as-yet undiscovered) bugs in that package were published. Regards, rfg P.S. I do think that Schneier has seriously overstated the criticality of Heartbleed. So far, I am not aware of -any- banks or other financial institutions which have been confirmed to have been affected, and by and large, life goes on and the world has not ended. ------------------------------ Message: 9 Date: Mon, 21 Apr 2014 21:54:47 -0500 From: "hcoin" <hc...@quietfountain.com> To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <5355d9f7.2010...@quietfountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 04/21/2014 08:38 PM, Ronald F. Guilmette wrote: <snipping good stuff before this good stuff> > I suspect that a whole lot of folks might be either (a) red faced or else > (b) deeply concerned if a scientifically derived estimate of the number of > *remaining* (and as-yet undiscovered) bugs in that package were published. Yes indeed. I think your comment 'as-yet undiscovered' is of an aspirational character. Imagine if your job, every day, is to take all the same talent and training involved in creating all this to find exploits. A person whose mind isn't absorbed with knowing everything about one area enough to move it's art ahead, but enough about all the areas with emphasis on their interfaces and edge conditions. For example, just the right compiler quirk or processor microcode quirk with just the right OS quirk in just the right library routine, or a quirk in the firmware of any device able to generate memory read bus cycles (smart network interface chips and hardware RAID cards come to mind, and, oh my -- graphics processors.... Every time device memory is mapped into user space ... worry.). The folks that do that are good at not sharing, and using them sparingly. It's the same problem faced by any defender: the defenders have to be entirely right all the time, while the exploit finder only has to be right once. Only rigor approaching the level of math theorems applied to software security (a trace easier than 'software correctness' I expect) can offer trustworthy assurances about blocking software-only exploits. The semantics of all our current popular languages, for reasons to do with making early 8 bit processors deliver value, are silent about what happens to data that 'goes out of scope' or 'is freed', most of the time the OS just marks the memory page 'unused' without knowing whether it's of importance to wipe. A few little-used languages had 'garbage collection routines' that could have been good at wiping. But mostly our languages struggled to do the right thing with data people cared about to bother much with what happened to it when 'done'. There was no performance that could be spared to "protect against data dumpster-divers". And wow look at what happened to programming discipline, particularly application programming, when throwing another gigabyte of ram or another processor into a machine cost less than tuning a routine. Most of the time it's not worth the processor time to wipe old data as the pages are bits from an old movie data anyhow. But most of the time isn't all of the time. Perhaps we should consider adding a variable attribute like 'secure' much like 'volatile' was added, to cause the compiler to generate code wiping such variables when they go out of scope, force initialize them to a known bit pattern, and only allocate those variables to pages that are wiped on free and that can't be referenced by pointer or other means except by a function or procedure that also has a 'secure' attribute. I'll go back to lurking now! Thanks for all your efforts. H ------------------------------ Subject: Digest Footer _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" ------------------------------ End of freebsd-security Digest, Vol 484, Issue 2 ************************************************ _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
