freebsd-security Digest, Vol 484, Issue 2
Alfred Hegemeier
molybdanstahl-hh at yahoo.co.uk
Tue Apr 22 12:23:44 UTC 2014
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-request at freebsd.org" <freebsd-security-request at freebsd.org> wrote:
Send freebsd-security mailing list submissions to
freebsd-security at 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-request at freebsd.org
You can reach the person managing the list at
freebsd-security-owner at 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" <drosih at rpi.edu>
To: "Jamie Landeg-Jones" <jamie at dyslexicfish.net>
Cc: hcoin at quietfountain.com, freebsd-security at freebsd.org
Subject: Re: De Raadt + FBSD + OpenSSH + hole?
Message-ID: <5C4F945A-E156-4AAB-8C59-1D9385BE467A at rpi.edu>
On 20 Apr 2014, at 23:06, Jamie Landeg-Jones wrote:
> "hcoin" <hcoin at 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 = drosih at rpi.edu
Senior Systems Programmer or gad at FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA
------------------------------
Message: 2
Date: Mon, 21 Apr 2014 18:23:07 +0300
From: Kimmo Paasiala <kpaasial at icloud.com>
To: Jamie Landeg-Jones <jamie at dyslexicfish.net>
Cc: freebsd-security at freebsd.org
Subject: Re: De Raadt + FBSD + OpenSSH + hole?
Message-ID: <89978872-0943-417C-9A96-9DB24E5D6CB8 at icloud.com>
Content-Type: text/plain; charset="windows-1252"
On 21.4.2014, at 6.06, Jamie Landeg-Jones <jamie at dyslexicfish.net> wrote:
> "hcoin" <hcoin at 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.robison at fisglobal.com>
To: <freebsd-security at freebsd.org>
Subject: Re: De Raadt + FBSD + OpenSSH + hole?
Message-ID: <53555E1B.1060705 at 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 <matt at 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)
daver at vicor.com
david.robison at 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" <rfg at tristatelogic.com>
To: freebsd-security at freebsd.org
Subject: Re: De Raadt + FBSD + OpenSSH + hole?
Message-ID: <97711.1398112757 at server1.tristatelogic.com>
In message <53546795.9050304 at quietfountain.com>,
"hcoin" <hcoin at 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-lists at cksoft.de>
To: "Ronald F. Guilmette" <rfg at tristatelogic.com>
Cc: freebsd-security at freebsd.org
Subject: Re: De Raadt + FBSD + OpenSSH + hole?
Message-ID: <alpine.BSF.2.00.1404212324520.32719 at 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.9050304 at quietfountain.com>,
> "hcoin" <hcoin at 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: ck at 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" <hcoin at quietfountain.com>
To: freebsd-security at freebsd.org
Subject: Re: De Raadt + FBSD + OpenSSH + hole?
Message-ID: <53558F1E.1010308 at 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.9050304 at quietfountain.com>,
> "hcoin" <hcoin at 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" <rfg at tristatelogic.com>
To: freebsd-security at freebsd.org
Subject: Re: De Raadt + FBSD + OpenSSH + hole?
Message-ID: <98152.1398116985 at server1.tristatelogic.com>
In message <alpine.BSF.2.00.1404212324520.32719 at pohjola.cksoft.de>,
Christian Kratzer <ck-lists at cksoft.de> wrote:
>On Mon, 21 Apr 2014, Ronald F. Guilmette wrote:
>>
>> In message <53546795.9050304 at quietfountain.com>,
>> "hcoin" <hcoin at 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" <rfg at tristatelogic.com>
To: freebsd-security at freebsd.org
Subject: Re: De Raadt + FBSD + OpenSSH + hole?
Message-ID: <99496.1398130725 at server1.tristatelogic.com>
In message <53558F1E.1010308 at quietfountain.com>,
"hcoin" <hcoin at quietfountain.com> wrote:
>
>On 04/21/2014 03:39 PM, Ronald F. Guilmette wrote:
>>
>> In message <53546795.9050304 at quietfountain.com>,
>> "hcoin" <hcoin at 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" <hcoin at quietfountain.com>
To: freebsd-security at freebsd.org
Subject: Re: De Raadt + FBSD + OpenSSH + hole?
Message-ID: <5355D9F7.2010208 at 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 at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
------------------------------
End of freebsd-security Digest, Vol 484, Issue 2
************************************************
More information about the freebsd-security
mailing list