Date: Tue, 22 Apr 2014 13:16:54 +0100 (BST) From: Alfred Hegemeier <molybdanstahl-hh@yahoo.co.uk> To: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: Re: freebsd-security Digest, Vol 484, Issue 2 Message-ID: <1398169014.53411.YahooMailNeo@web28902.mail.ir2.yahoo.com> In-Reply-To: <mailman.96.1398168002.43518.freebsd-security@freebsd.org> References: <mailman.96.1398168002.43518.freebsd-security@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
What a load of nonsense here: no, I don't think we should further extend th= e 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 pr= ogram..especially if it is security related code, shouldn't anybody=A0 ?! = =0A=0AThis 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 nu= mber between 1 and 10 even if you tell them, but check it, omg.=0A=0AOMG=0A= =0A=0A=0AOn Tuesday, 22 April 2014, 14:00, "freebsd-security-request@freebs= d.org" <freebsd-security-request@freebsd.org> wrote:=0A =0ASend freebsd-sec= urity mailing list submissions to=0A=A0=A0=A0 freebsd-security@freebsd.org= =0A=0ATo subscribe or unsubscribe via the World Wide Web, visit=0A=A0=A0=A0= http://lists.freebsd.org/mailman/listinfo/freebsd-security=0Aor, via email= , send a message with subject or body 'help' to=0A=A0=A0=A0 freebsd-securit= y-request@freebsd.org=0A=0AYou can reach the person managing the list at=0A= =A0=A0=A0 freebsd-security-owner@freebsd.org=0A=0AWhen replying, please edi= t your Subject line so it is more specific=0Athan "Re: Contents of freebsd-= security digest..."=0A=0A=0AToday's Topics:=0A=0A=A0 1. Re: De Raadt + FBS= D + OpenSSH + hole? (Garance A Drosehn)=0A=A0 2. Re: De Raadt + FBSD + Ope= nSSH + hole? (Kimmo Paasiala)=0A=A0 3. Re: De Raadt + FBSD + OpenSSH + hol= e? (Robison, Dave)=0A=A0 4. Re: De Raadt + FBSD + OpenSSH + hole? (Ronald = F. Guilmette)=0A=A0 5. Re: De Raadt + FBSD + OpenSSH + hole? (Christian Kr= atzer)=0A=A0 6. Re: De Raadt + FBSD + OpenSSH + hole? (hcoin)=0A=A0 7. Re= : De Raadt + FBSD + OpenSSH + hole? (Ronald F. Guilmette)=0A=A0 8. Re: De = Raadt + FBSD + OpenSSH + hole? (Ronald F. Guilmette)=0A=A0 9. Re: De Raadt= + FBSD + OpenSSH + hole? (hcoin)=0A=0A=0A---------------------------------= -------------------------------------=0A=0AMessage: 1=0ADate: Mon, 21 Apr 2= 014 11:13:24 -0400=0AFrom: "Garance A Drosehn" <drosih@rpi.edu>=0ATo: "Jami= e Landeg-Jones" <jamie@dyslexicfish.net>=0ACc: hcoin@quietfountain.com, fre= ebsd-security@freebsd.org=0ASubject: Re: De Raadt + FBSD + OpenSSH + hole?= =0AMessage-ID: <5C4F945A-E156-4AAB-8C59-1D9385BE467A@rpi.edu>=0A=0A=0AOn 20= Apr 2014, at 23:06, Jamie Landeg-Jones wrote:=0A=0A> "hcoin" <hcoin@quietf= ountain.com> wrote:=0A>=0A>> local variables) harms performance.=A0 It's a= lso true doing both of these=0A>> things would not fix the flaw that 'opene= d the window' onto these data.=0A>> However it is true that doing so would = make the exploit valueless as=0A>> 'opening a window' onto erased data woul= d reveal nothing and could erase=0A>> trojan/virus 'hijack via code-injecti= on then trampoline' opportunities.=0A>=0A> In the heartbleed case, was the = bug returning stale freed memory, though?=0A> Couldn't it just as easily ha= ve been that the over-read was returning any=0A> other memory that the proc= ess has had allocated for other variables - data=0A> that was still in use?= =0A=0AThe heardbleed case is totally an error in openssl, because it does n= ot=0Areally use the system malloc/free.=A0 It mallocs a huge chunk of memor= y from=0Athe system when it starts up, and then it has it's own routines wh= ich manages=0Athat memory.=A0 As far as the operating system is concerned, = it can't touch any=0Aof that memory, even though openssl is using it over-a= nd-over for whatever it=0Aneeds memory for.=A0 Openssl did this, of course,= for performance reasons.=0A=0ASo in the case of openssl, the problem was t= hat the code *never* returned=0Amemory, no matter how stale and unreference= d the data was.=0A=0A-- =0AGarance Alistair Drosehn=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =3D=A0 =A0 drosih@rpi.edu=0ASenior Systems Programmer=A0 =A0 =A0 = =A0 =A0 =A0 =A0 or=A0 gad@FreeBSD.org=0ARensselaer Polytechnic Institute;= =A0 =A0 =A0 =A0 =A0 =A0 Troy, NY;=A0 USA=0A=0A=0A-------------------------= -----=0A=0AMessage: 2=0ADate: Mon, 21 Apr 2014 18:23:07 +0300=0AFrom: Kimmo= Paasiala <kpaasial@icloud.com>=0ATo: Jamie Landeg-Jones <jamie@dyslexicfis= h.net>=0ACc: freebsd-security@freebsd.org=0ASubject: Re: De Raadt + FBSD + = OpenSSH + hole?=0AMessage-ID: <89978872-0943-417C-9A96-9DB24E5D6CB8@icloud.= com>=0AContent-Type: text/plain; charset=3D"windows-1252"=0A=0A=0AOn 21.4.2= 014, at 6.06, Jamie Landeg-Jones <jamie@dyslexicfish.net> wrote:=0A=0A> "hc= oin" <hcoin@quietfountain.com> wrote:=0A> =0A>> local variables) harms perf= ormance.=A0 It's also true doing both of these =0A>> things would not fix = the flaw that 'opened the window' onto these data.=A0 =0A>> However it is t= rue that doing so would make the exploit valueless as =0A>> 'opening a wind= ow' onto erased data would reveal nothing and could erase =0A>> trojan/viru= s 'hijack via code-injection then trampoline' opportunities.=0A> =0A> In th= e heartbleed case, was the bug returning stale freed memory, though?=0A> Co= uldn't it just as easily have been that the over-read was returning any=0A>= other memory that the process has had allocated for other variables - data= =0A> that was still in use?=0A=0ANo, the problem was another type of progra= mming error that is endemic in C programming. It?s called failure to valida= te input parameters before using the input parameters or derived values fro= m the input parameters as array indices. =0A=0Ahttps://en.wikipedia.org/wik= i/Bounds_checking=0A=0AThe bug allowed an attacker to request any number of= bytes from memory that followed the buffer that the client was usually all= owed to access (depending on how the index was interpreted it might have be= en possible to request memory before the buffer as well). The part of memor= y that followed the buffer very probably contained some very sensitive info= rmation, possibly secret keys that were loaded in memory (memory that was c= onstantly in use and not free()?d until the process terminates) in unprotec= ted form (plain text essentially) for fast access during encryption and dec= ryption.=0A=0A-Kimmo=0A=0A-------------- next part --------------=0AA non-t= ext attachment was scrubbed...=0AName: signature.asc=0AType: application/pg= p-signature=0ASize: 496 bytes=0ADesc: Message signed with OpenPGP using GPG= Mail=0AURL: <http://lists.freebsd.org/pipermail/freebsd-security/attachment= s/20140421/dc7e964d/attachment-0001.sig>=0A=0A-----------------------------= -=0A=0AMessage: 3=0ADate: Mon, 21 Apr 2014 11:06:19 -0700=0AFrom: "Robison,= Dave" <david.robison@fisglobal.com>=0ATo: <freebsd-security@freebsd.org>= =0ASubject: Re: De Raadt + FBSD + OpenSSH + hole?=0AMessage-ID: <53555E1B.1= 060705@fisglobal.com>=0AContent-Type: text/plain; charset=3D"ISO-8859-1"=0A= =0AOn 04/19/2014 18:46, Mikhail wrote:=0A>> On 4/14/2014 7:32 AM, Jamie Lan= deg-Jones wrote:=0A>>> Matt Dawson <matt@chronos.org.uk> wrote:=0A>>>=0A>>>= > My first thought when I saw this was "ego over ethics," which says more= =0A>>>> about Theo than FreeBSD.=0A>>>=0A> =0A> I believe that Theo just br= owbeat. Reasons? It was looooong ago, I think=0A> very few still remember, = but Theo definitely does:=0A> =0A> http://lists.freebsd.org/pipermail/freeb= sd-security/2005-March/002719.html=0A> ____________________________________= ___________=0A=0A=0ATheo has maliciously impacted the FreeBSD project at le= ast twice that I=0Acan recall.=0A=0ANobody should expect any less from him.= =0A=0A=0A=0A=0A-- =0ADave Robison=0ASales Solution Architect II=0AFIS Banki= ng Solutions=0A510/621-2089 (w)=0A530/518-5194 (c)=0A510/621-2020 (f)=0Adav= er@vicor.com=0Adavid.robison@fisglobal.com=0A=0A_____________=0AThe informa= tion contained in this message is proprietary and/or confidential. If you a= re not the intended recipient, please: (i) delete the message and all copie= s; (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 m= essage addressed to our domain is subject to archiving and review by person= s other than the intended recipient. Thank you.=0A=0A=0A-------------------= -----------=0A=0AMessage: 4=0ADate: Mon, 21 Apr 2014 13:39:17 -0700=0AFrom:= "Ronald F. Guilmette" <rfg@tristatelogic.com>=0ATo: freebsd-security@freeb= sd.org=0ASubject: Re: De Raadt + FBSD + OpenSSH + hole?=0AMessage-ID: <9771= 1.1398112757@server1.tristatelogic.com>=0A=0A=0AIn message <53546795.905030= 4@quietfountain.com>, =0A"hcoin" <hcoin@quietfountain.com> wrote:=0A=0A>...= It is for the community to decide whether it is 'worth it' =0A>on a case b= y case basis given there is no way to prove a program =0A>'correct' from a = security perspective.=0A=0AI guess that I was sick that day in software sch= ool.=0A=0ADid I just hear you tell me that I can't prove the following prog= ram=0Ais "secure"?=0A=0A=0Aint=0Amain (void)=0A{=0A=A0 return 0;=0A}=0A=0A= =0A------------------------------=0A=0AMessage: 5=0ADate: Mon, 21 Apr 2014 = 23:28:26 +0200 (CEST)=0AFrom: Christian Kratzer <ck-lists@cksoft.de>=0ATo: = "Ronald F. Guilmette" <rfg@tristatelogic.com>=0ACc: freebsd-security@freebs= d.org=0ASubject: Re: De Raadt + FBSD + OpenSSH + hole?=0AMessage-ID: <alpin= e.BSF.2.00.1404212324520.32719@pohjola.cksoft.de>=0AContent-Type: TEXT/PLAI= N; charset=3DUS-ASCII; format=3Dflowed=0A=0AHi,=0A=0AOn Mon, 21 Apr 2014, R= onald F. Guilmette wrote:=0A>=0A> In message <53546795.9050304@quietfountai= n.com>,=0A> "hcoin" <hcoin@quietfountain.com> wrote:=0A>=0A>> ... It is for= the community to decide whether it is 'worth it'=0A>> on a case by case ba= sis given there is no way to prove a program=0A>> 'correct' from a security= perspective.=0A>=0A> I guess that I was sick that day in software school.= =0A>=0A> Did I just hear you tell me that I can't prove the following progr= am=0A> is "secure"?=0A>=0A>=0A> int=0A> main (void)=0A> {=0A>=A0 return 0;= =0A> }=0A=0Ain an ideal world you could propably.=A0 The difficulty ist tha= t even=0Aabove seemingly trival snippet of code is run after initialization= of=0Athe c runtime library and some pre processing of argc, argv.=0A=0AIt = gets more complex with c++ contstructors run before main.=0A=0AIf gets even= more complex the more software components interact in=0Awierd and wonderfu= ll ways.=0A=0AGreetings=0AChristian=0A=0A-- =0AChristian Kratzer=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 CK Software GmbH=0AEmail:=A0 ck@cksoft.de=A0 =A0 = =A0 =A0 =A0 =A0 =A0 Wildberger Weg 24/2=0APhone:=A0 +49 7032 893 997 - 0= =A0 =A0 =A0 D-71126 Gaeufelden=0AFax:=A0 =A0 +49 7032 893 997 - 9=A0 =A0 = =A0 HRB 245288, Amtsgericht Stuttgart=0AMobile:=A0 +49 171 1947 843=A0 =A0= =A0 =A0 =A0 Geschaeftsfuehrer: Christian Kratzer=0AWeb:=A0 =A0 http://www= .cksoft.de/=0A=0A=0A------------------------------=0A=0AMessage: 6=0ADate: = Mon, 21 Apr 2014 16:35:26 -0500=0AFrom: "hcoin" <hcoin@quietfountain.com>= =0ATo: freebsd-security@freebsd.org=0ASubject: Re: De Raadt + FBSD + OpenSS= H + hole?=0AMessage-ID: <53558F1E.1010308@quietfountain.com>=0AContent-Type= : text/plain; charset=3DISO-8859-1; format=3Dflowed=0A=0A=0AOn 04/21/2014 0= 3:39 PM, Ronald F. Guilmette wrote:=0A>=0A> In message <53546795.9050304@qu= ietfountain.com>,=0A> "hcoin" <hcoin@quietfountain.com> wrote:=0A>=0A>> ...= It is for the community to decide whether it is 'worth it'=0A>> on a case = by case basis given there is no way to prove a program=0A>> 'correct' from = a security perspective.=0A> I guess that I was sick that day in software sc= hool.=0A>=0A> Did I just hear you tell me that I can't prove the following = program=0A> is "secure"?=0A>=0A>=0A> int=0A> main (void)=0A> {=0A>=A0 =A0 r= eturn 0;=0A> }=0A> _______________________________________________=0A>=0AGo= od one.=A0 There were efforts, some years ago, to prove 'software =0Acorrec= tness' with a similar understanding of 'correct' as mathematicians =0Ahave = when regarding a theorem as 'true'.=A0 The alligators in the =0Acomplexity= swamp ate those efforts before breakfast.=A0 First you have to =0Aprove th= e microcode in the processors correct, then you have to prove =0Athe compil= ers 'correctly' translate your favorite language into machine =0Acode, then= you have to prove the OS is both 'correct' and doesn't =0A'break' the corr= ectness in the running application.=A0 To manage that you =0Ahave to extend= logical expression to manage asynchronous events, no =0Asmall thing.=A0 Ou= r logical tools are pretty bound to linear 'if then' =0Abricks-upon-other-b= ricks concepts.=0A=0AAnd then, after all that is proven, the question of wh= ether the program =0Ayou wrote is 'correct' can be engaged.=0A=0AThe new-is= h language Haskell takes an 'outside the box' approach to the =0Aquestion, = by shifting what a 'program' is to be closer to 'what should =0Athe result = be' than 'what step should happen next'.=A0 There's more hope =0Asuch a lan= guage could specify provably correct programs than C-ish or =0Aobject-orien= ted cousins, but that still leaves the whole =0Amachine-language domain una= ddressed.=0A=0AImagine the size of a number made up of every settable optio= n bit in the =0Aprocessor and support chips, and add more for each occasion= the order in =0Awhich those bits are set or reset matters.=A0 Each combina= tion of those =0Abits calls for the correctness proof to be rechecked.=0A= =0AEven in that little program you wrote, is it a security hole if, left on= =0Athe stack upon return, the perhaps unused arguments remain? Just becaus= e =0Ayou're paranoid doesn't mean they really aren't after you.=0A=0A=0A=0A= =0A=0A=0A------------------------------=0A=0AMessage: 7=0ADate: Mon, 21 Apr= 2014 14:49:45 -0700=0AFrom: "Ronald F. Guilmette" <rfg@tristatelogic.com>= =0ATo: freebsd-security@freebsd.org=0ASubject: Re: De Raadt + FBSD + OpenSS= H + hole?=0AMessage-ID: <98152.1398116985@server1.tristatelogic.com>=0A=0A= =0AIn message <alpine.BSF.2.00.1404212324520.32719@pohjola.cksoft.de>, =0AC= hristian Kratzer <ck-lists@cksoft.de> wrote:=0A=0A>On Mon, 21 Apr 2014, Ron= ald F. Guilmette wrote:=0A>>=0A>> In message <53546795.9050304@quietfountai= n.com>,=0A>> "hcoin" <hcoin@quietfountain.com> wrote:=0A>>=0A>>> ... It is = for the community to decide whether it is 'worth it'=0A>>> on a case by cas= e basis given there is no way to prove a program=0A>>> 'correct' from a sec= urity perspective.=0A>>=0A>> I guess that I was sick that day in software s= chool.=0A>>=0A>> Did I just hear you tell me that I can't prove the followi= ng program=0A>> is "secure"?=0A>>=0A>>=0A>> int=0A>> main (void)=0A>> {=0A>= >=A0 return 0;=0A>> }=0A>=0A>in an ideal world you could propably.=A0 The d= ifficulty ist that even=0A>above seemingly trival snippet of code is run af= ter initialization of=0A>the c runtime library and some pre processing of a= rgc, argv.=0A>=0A>It gets more complex with c++ contstructors run before ma= in.=0A>=0A>If gets even more complex the more software components interact = in=0A>wierd and wonderfull ways.=0A=0A=0AAt the risk of stating the obvious= ...=0A=0A=A0 =A0 Complexity !=3D Impossibility=0A=0AI think that we need be= tter tools.=0A=0ABut then again, I have always thought that, and undoubtedl= y always will.=0A=0A=0ARegards,=0Arfg=0A=0A=0A-----------------------------= -=0A=0AMessage: 8=0ADate: Mon, 21 Apr 2014 18:38:45 -0700=0AFrom: "Ronald F= . Guilmette" <rfg@tristatelogic.com>=0ATo: freebsd-security@freebsd.org=0AS= ubject: Re: De Raadt + FBSD + OpenSSH + hole?=0AMessage-ID: <99496.13981307= 25@server1.tristatelogic.com>=0A=0A=0AIn message <53558F1E.1010308@quietfou= ntain.com>, =0A"hcoin" <hcoin@quietfountain.com> wrote:=0A=0A>=0A>On 04/21/= 2014 03:39 PM, Ronald F. Guilmette wrote:=0A>>=0A>> In message <53546795.90= 50304@quietfountain.com>,=0A>> "hcoin" <hcoin@quietfountain.com> wrote:=0A>= >=0A>>> ... It is for the community to decide whether it is 'worth it'=0A>>= > on a case by case basis given there is no way to prove a program=0A>>> 'c= orrect' from a security perspective.=0A>> I guess that I was sick that day = in software school.=0A>>=0A>> Did I just hear you tell me that I can't prov= e the following program=0A>> is "secure"?=0A>>=0A>>=0A>> int=0A>> main (voi= d)=0A>> {=0A>>=A0 =A0 return 0;=0A>> }=0A>> _______________________________= ________________=0A>>=0A>Good one.=0A=0AThank you.=A0 I wish that I could s= ay that I had written that program all=0Aby myself, but...=0A=0A>There were= efforts, some years ago, to prove 'software =0A>correctness' with a simila= r understanding of 'correct' as mathematicians =0A>have when regarding a th= eorem as 'true'.=A0 The alligators in the =0A>complexity swamp ate those e= fforts before breakfast.=0A=0AWell, um, yes.=0A=0A>First you have to =0A>pr= ove the microcode in the processors correct, then you have to prove =0A>the= compilers 'correctly' translate your favorite language into machine =0A>co= de, then you have to prove the OS is both 'correct' and doesn't =0A>'break'= the correctness in the running application.=0A=0ASure, if one wanted to be= really anal about it.=A0 But the semantics of a=0Agiven C program are spec= ified by the ANSI/ISO C standard.=0A=0A>The new-ish language Haskell takes = an 'outside the box' approach to the ...=0A=0AFunny you should mention that= .=0A=0AJust after I wrote the message to which you responded, it occured to= me=0Athat I had not read anything at all about denotational senatics for a= bout=0Athe last 20 years (and even the stuff that I did read, way back then= , was=0Aprobably over my head).=A0 So just today, I went and looked at the = entry for=0A"denotational semantics" in Wikipedia.=A0 That Wikipedia entry = did mention=0Aone language in particular... Haskell.=0A=0AI guess that I'll= be looking into that.=A0 (I currently know zip about Haskell,=0Abut am alw= ays eager to learn new things.)=0A=0A>Even in that little program you wrote= , is it a security hole if, left on =0A>the stack upon return, the perhaps = unused arguments remain?=0A=0AI suspect that you and I have different defin= itions of the term "security=0Ahole".=0A=0A>Just because you're paranoid do= esn't mean they really aren't after you.=0A=0AOn this, at least, we agree c= ompletely.=0A=0AOne last thought...=0A=0AIn the aftermath of this whole Ope= nSSL brouhaha... which none other than=0ABruce Schneier publically pronounc= ed to be a 12, on a scale from 1 to 10,=0Ain terms of awfulness... I do won= der if anyone has taken the time or effort=0Ato run the OpenSSL sources thr= ough any kind of analyzer to try to obtain=0Asome of the standard sorts of = software science metrics on it.=0A=0AI suspect that a whole lot of folks mi= ght be either (a) red faced or else=0A(b) deeply concerned if a scientifica= lly derived estimate of the number of=0A*remaining* (and as-yet undiscovere= d) bugs in that package were published.=0A=0A=0ARegards,=0Arfg=0A=0A=0AP.S.= =A0 I do think that Schneier has seriously overstated the criticality of = =0AHeartbleed.=A0 So far, I am not aware of -any- banks or other financial= =0Ainstitutions which have been confirmed to have been affected, and by and= =0Alarge, life goes on and the world has not ended.=0A=0A=0A---------------= ---------------=0A=0AMessage: 9=0ADate: Mon, 21 Apr 2014 21:54:47 -0500=0AF= rom: "hcoin" <hcoin@quietfountain.com>=0ATo: freebsd-security@freebsd.org= =0ASubject: Re: De Raadt + FBSD + OpenSSH + hole?=0AMessage-ID: <5355D9F7.2= 010208@quietfountain.com>=0AContent-Type: text/plain; charset=3DISO-8859-1;= format=3Dflowed=0A=0AOn 04/21/2014 08:38 PM, Ronald F. Guilmette wrote:=0A= <snipping good stuff before this good stuff>=0A> I suspect that a whole lot= of folks might be either (a) red faced or else=0A> (b) deeply concerned if= a scientifically derived estimate of the number of=0A> *remaining*=A0 (and= as-yet undiscovered) bugs in that package were published.=0AYes indeed.=A0= I think your comment 'as-yet undiscovered' is of an =0Aaspirational charac= ter.=0A=0AImagine if your job, every day, is to take all the same talent an= d =0Atraining involved in creating all this to find exploits.=A0 A person w= hose =0Amind isn't absorbed with knowing everything about one area enough t= o =0Amove it's art ahead, but enough about all the areas with emphasis on = =0Atheir interfaces and edge conditions.=A0 For example, just the right =0A= compiler quirk or processor microcode quirk with just the right OS quirk = =0Ain just the right library routine, or a quirk in the firmware of any =0A= device able to generate memory read bus cycles (smart network interface =0A= chips and hardware RAID cards come to mind, and, oh my -- graphics =0Aproce= ssors.... Every time device memory is mapped into user space ... =0Aworry.)= .=A0 The folks that do that are good at not sharing, and using them =0Aspar= ingly.=0A=0AIt's the same problem faced by any defender:=A0 the defenders h= ave to be =0Aentirely right all the time, while the exploit finder only has= to be =0Aright once.=A0 Only rigor approaching the level of math theorems = applied =0Ato software security (a trace easier than 'software correctness'= I =0Aexpect) can offer trustworthy assurances about blocking software-only= =0Aexploits.=0A=0AThe semantics of all our current popular languages, for = reasons to do =0Awith making early 8 bit processors deliver value,=A0 are s= ilent about what =0Ahappens to data that 'goes out of scope' or 'is freed',= most of the time =0Athe OS just marks the memory page 'unused' without kno= wing whether it's =0Aof importance to wipe.=A0 A few little-used languages= had 'garbage =0Acollection routines' that could have been good at wiping.= =A0 But mostly =0Aour languages struggled to do the right thing with data p= eople cared =0Aabout to bother much with what happened to it when 'done'.= =A0 There was no =0Aperformance that could be spared to "protect against da= ta =0Adumpster-divers".=A0 =A0 And wow look at what happened to programming= =0Adiscipline, particularly application programming, when throwing another= =0Agigabyte of ram or another processor into a machine cost less than =0At= uning a routine.=0A=0AMost of the time it's not worth the processor time to= wipe old data as =0Athe pages are bits from an old movie data anyhow.=A0 B= ut most of the time =0Aisn't all of the time.=0A=0APerhaps we should consid= er adding a variable attribute like 'secure' =0Amuch like 'volatile' was ad= ded, to cause the compiler to generate code =0Awiping such variables when t= hey go out of scope, force initialize them =0Ato a known bit pattern, and o= nly allocate those variables to pages that =0Aare wiped on free and that ca= n't be referenced by pointer or other means =0Aexcept by a function or proc= edure that also has a 'secure' attribute.=0A=0AI'll go back to lurking now!= =A0 Thanks for all your efforts.=0A=0AH=0A=0A=0A=0A=0A=0A=0A=0A------------= ------------------=0A=0ASubject: Digest Footer=0A=0A_______________________= ________________________=0Afreebsd-security@freebsd.org mailing list=0Ahttp= ://lists.freebsd.org/mailman/listinfo/freebsd-security=0ATo unsubscribe, se= nd any mail to "freebsd-security-unsubscribe@freebsd.org"=0A=0A------------= ------------------=0A=0AEnd of freebsd-security Digest, Vol 484, Issue 2=0A= ************************************************ From owner-freebsd-security@FreeBSD.ORG Tue Apr 22 19:00:53 2014 Return-Path: <owner-freebsd-security@FreeBSD.ORG> Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F89715A for <freebsd-security@freebsd.org>; Tue, 22 Apr 2014 19:00:53 +0000 (UTC) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00C341CF5 for <freebsd-security@freebsd.org>; Tue, 22 Apr 2014 19:00:52 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from mail-out.apple.com by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) id <0N4G00B004NU7800@local.mail-out.apple.com> for freebsd-security@freebsd.org; Tue, 22 Apr 2014 12:00:09 -0700 (PDT) Received: from relay5.apple.com ([17.128.113.88]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N4G009EN4RNYEB0@local.mail-out.apple.com>; Tue, 22 Apr 2014 12:00:09 -0700 (PDT) X-AuditID: 11807158-f79c66d00000166b-8c-5356bc3936d7 Received: from [17.149.224.243] (Unknown_Domain [17.149.224.243]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 3F.5F.05739.93CB6535; Tue, 22 Apr 2014 12:00:09 -0700 (PDT) Subject: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Charles Swiger <cswiger@mac.com> In-reply-to: <99496.1398130725@server1.tristatelogic.com> Date: Tue, 22 Apr 2014 12:00:08 -0700 Message-id: <DC2F9726-881B-4D42-879F-61377CA0210D@mac.com> References: <99496.1398130725@server1.tristatelogic.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUiOPXBZ13LPWHBBjuWC1v0bHrCZvHq8is2 ByaPGZ/ms3jc39TIHMAUxWWTkpqTWZZapG+XwJWxfMoZ5oLLghUL9hQ2MP7l7WLk4JAQMJH4 3lbRxcgJZIpJXLi3nq2LkYtDSKCfSeJR1yRWkASzgJbEjX8vmUDqeQX0JLb/kgMJCwt4SFzc u4MFJMwmoCYxYSIPSJhTwFJi7qw/YJ0sAqoSZ9YtYoOYoiAxef53ZghbW2LZwtdgNq+AlcTn hZuYQGwhAQuJydMug9WLCOhLLN37lBHiNFmJ0+ees0xg5J+F5KBZCAfNQjJ1ASPzKkaBotSc xEpTvcSCgpxUveT83E2MoFBrKIzYwfh/mdUhRgEORiUeXonlYcFCrIllxZW5hxglOJiVRHil VwOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+ox+wcLCaQnlqRmp6YWpBbBZJk4OKUaGO+pXNvU n6/Fs+j8yfU5Dft/TvkWxOWY47JK893lIInDap0Hf21+wG+t9nnaTAHu0t/fzFP+HpdR2uXf csGyb5WR8dRnNgd/ha14+PfJolUPnH5sOPtzlc0144r1H00PKCXeLWqdJtqXE73W7t0Z5zvn rYPM3UtaT+xQeFI3o7b2Urcf58Mk22QlluKMREMt5qLiRAB+Gi1SMQIAAA== Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" <freebsd-security.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-security>, <mailto:freebsd-security-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security/>; List-Post: <mailto:freebsd-security@freebsd.org> List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, <mailto:freebsd-security-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 22 Apr 2014 19:00:53 -0000 On Apr 21, 2014, at 6:38 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote: > 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. Sure. Running clang's static analyzer against openssl-1.0.1g yields: Bug Type Quantity All Bugs 182 Dead store Dead assignment 121 Dead increment 12 Dead initialization 2 Logic error Assigned value is garbage or undefined 3 Branch condition evaluates to a garbage value 1 Dereference of null pointer 27 Division by zero 1 Result of operation is garbage or undefined 9 Uninitialized argument value 2 Unix API 4 The "division by zero" is ssl/t1_enc.c:267 and has 15 steps to reach; one of the null pointer cases, crypto/asn1/f_string.c:191, has a path length of 39. [ ... ] > 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. Most of the large financial institutions use hardware crypto-accelerators to speed up SSL; devices like F5's BIG-IP, Brocade's ServerIrons, Citrix NetScalers, etc. These vendors and their hardware tend to be conservative and were generally sticking with capabilities mirroring OpenSSL 0.9.8, rather than chasing TLS v1.2, perfect forward secrecy and the like from OpenSSL 1.x. Just as an FYI, I'd heard a rumbling or two about Heartbleed on Friday April 4, but the first open publication I saw of this was on Ars Technica thread here: http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens-two-thirds-of-the-web-to-eavesdropping Note that around comment #78 by raphidae, that user ran the exploit against Ars and was able to grab username+passwords and login as other users. Regards, -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1398169014.53411.YahooMailNeo>