valgrind and openssl - Openssl

This is a discussion on valgrind and openssl - Openssl ; > What I _wouldn't_ be happy with is a PRNG which has been fed only known > data, but enough of it at startup that it agrees to provide output to > the user. There are a terrible lot of ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 74 of 74

Thread: valgrind and openssl

  1. RE: valgrind and openssl


    > What I _wouldn't_ be happy with is a PRNG which has been fed only known
    > data, but enough of it at startup that it agrees to provide output to
    > the user. There are a terrible lot of these around, and pretending that
    > stack contents are random is a great way to accidentally build them.


    Fortunately, OpenSSL does not pretend the stack contents are random.

    People sometimes accidentally shoot themselves because they handle a gun as
    if it was unloaded when it's loaded. But it doesn't make sense to ensure the
    gun is loaded just to ensure you handle it as if it was loaded. However,
    this is essentially your argument -- don't do something that can only help
    because if you relied on just that you might be in trouble.

    Sorry, I reject that argument.

    > Not feeding in data which you have a pretty darned good idea will be
    > predictable -- potentially as the first bits in at RNG startup -- is to
    > my mind one thing one can should do to avoid the problem.
    >
    > Thor


    You are honestly arguing that the best way to avoid handling a gun as if it
    were unloaded is to ensure it is loaded before handling it. Isn't that
    clearly crazy?

    Why do something that can only hurt you? That you might get in trouble if
    you rely on it is an argument not to rely on it, not an argument not to do
    it.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  2. Re: valgrind and openssl



    On Thu, 15 May 2008, Bodo Moeller wrote:

    > On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo
    > wrote:
    > > Goetz Babin-Ebell wrote:

    >
    > >> But here the use of this uninitialized data is intentional
    > >> and the programmer are very well aware of what they did.

    >
    > > The use of unititialized data in this case is stupid because the
    > > entropy of this random data is close to zero.

    >
    > It may be zero, but it may be more, depending on what happened earlier
    > in the program if the same memory locations have been in use before.
    > This may very well include data that would be unpredictable to
    > adversaries -- i.e., entropy; that's the point here.


    on the other hand it may be a known plaintext attack.

    what are you guys smoking?

    -dean
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  3. RE: valgrind and openssl

    On Mon, 19 May 2008, David Schwartz wrote:

    >
    > > any special case changes for testing means you're not testing the REAL
    > > CODE.

    >
    > You mean you're not testing *all* of the real code. That's fine, you can't
    > debug everythign at once.


    if you haven't tested your final production binary then you haven't tested
    anything at all.


    > Good luck finding people who agree with you. I've been a professional
    > software developer for about 18 years and I've worked on debugging with


    i've been a professional for longer than you. big whoop.

    -dean
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: valgrind and openssl

    >> The problems occur on Red Hat 5.1 server x86_64. For what it's worth,
    >> I don't get errors on (updated Ubuntu 7.10.
    >>
    >> I do get errors even with Bodo's addition to randfile.c. I'd be happy
    >> to post the valgrind output if that would be helpful.

    >
    > If this is environment/OS-specific, then it's probably indicative of a libc
    > (or valgrind, or gcc) issue with the fixed-in-the-past versions of those
    > packages on RH5.1-64bit. If compiling and running the same openssl source on
    > a different system doesn't give you problems, that would seem to imply that
    > the problem appears and disappears based on elements that vary rather than
    > elements that are invariant. :-)


    It's environment dependent. I'm not able to reproduce the valgrind
    errors even on other 64 bit RH5.1 machines. As far as I'm concerned,
    openssl valgrinds clean with ./config no-asm -DPURIFY: my goals are
    achieved.

    -JP
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  5. Re: valgrind and openssl

    On Mon, May 19, 2008 at 10:48 PM, dean gaudet wrote:
    >
    >
    > On Thu, 15 May 2008, Bodo Moeller wrote:
    >
    >> On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo
    >> wrote:
    >> > Goetz Babin-Ebell wrote:

    >>
    >> >> But here the use of this uninitialized data is intentional
    >> >> and the programmer are very well aware of what they did.

    >>
    >> > The use of unititialized data in this case is stupid because the
    >> > entropy of this random data is close to zero.

    >>
    >> It may be zero, but it may be more, depending on what happened earlier
    >> in the program if the same memory locations have been in use before.
    >> This may very well include data that would be unpredictable to
    >> adversaries -- i.e., entropy; that's the point here.

    >
    > on the other hand it may be a known plaintext attack.


    OK, so I'll seed my random number generator with a bunch of bits you
    don't know, then you give me however much known plaintext you want,
    and I'll update the state with that too. Then, I'll start generating
    random numbers. If you can guess them, you win! Right?

    Essentially what you're claiming is that you can predict the output of
    SHA-1 when you know part of the input, but not all of the input.
    Please explain how!

    -JP

    > what are you guys smoking?
    >
    > -dean
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > Development Mailing List openssl-dev@openssl.org
    > Automated List Manager majordomo@openssl.org
    >

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  6. RE: valgrind and openssl


    > > You mean you're not testing *all* of the real code. That's
    > > fine, you can't
    > > debug everythign at once.


    > if you haven't tested your final production binary then you
    > haven't tested
    > anything at all.


    You: Two plus two is five.

    Me: Are you crazy? Two plus two is not five.

    You: If you don't realize that three plus three is six, then you don't know
    any math at all.

    Err, what?!

    What does testing your final production binary have to do with debugging on
    code other than your final production binary?

    > > Good luck finding people who agree with you. I've been a professional
    > > software developer for about 18 years and I've worked on debugging with

    >
    > i've been a professional for longer than you. big whoop.
    >
    > -dean


    It really doesn't matter how long you've been doing it when you spout
    nonsense like the above.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  7. RE: valgrind and openssl


    > on the other hand it may be a known plaintext attack.
    >
    > what are you guys smoking?
    >
    > -dean


    This argument has already been refuted in the posts you are replying to.

    Such an "attack" would require the algorithm to not meet its specific design
    security objectives. In other words, you are arguing that this might be a
    problem if the algorithm is fundamentally broken. Well, duh, using it might
    be a problem if the algorithm is fundamentally broken.

    A primary security objective of the PRNG is that mixing in known data can
    never, ever hurt you. It may not increase the entropy in the PRNG, but it
    cannot decrease it. This is a specific design object, and you can rely on
    the PRNG to meet this object. If you don't think the PRNG meets this
    objective, you should not use it at all because this is one of its primary
    objectives and the entire design is premised on it.

    The only issue is that you might not mix in enough unknown data. Mixing in
    known data can never hurt you. If it can, the PRNG is totally and completely
    broken.

    If you have any reason to think it is, please explain why. We will all
    change the algorithm because this would be a major breakage.

    You might as well argue that after you sign something with RSA, you should
    keep the signature secret. After all, there might be some attack where the
    signature leaks parts of the private key. Sure, there might be. But if you
    really thought there was any chance of that, you'd abandon the signature
    algorithm, not work harder to keep the signatures secret.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  8. Re: valgrind and openssl

    > on the other hand it may be a known plaintext attack.

    Using those words in this context makes it sound that you not only don't
    understand what is being discussed right here and now, but also that you
    don't understand the term you just used. Are you sure you understood,
    e.g., Ted Tso's postings in this thread? Perhaps I'm missing something,
    but can you show me something that talks about known plaintext attacks in
    the context of hashing/digests?

    > what are you guys smoking?


    Indeed.

    /r$

    --
    STSM, DataPower Chief Programmer
    WebSphere DataPower SOA Appliances
    http://www.ibm.com/software/integration/datapower/


  9. Re: valgrind and openssl

    On Monday 19 May 2008 15:27:24 dean gaudet wrote:
    > > Note that you should always build with "no-asm" if you're doing this kind
    > > of debug analysis. The assembly optimisations are likely to operate at
    > > granularities and in ways that valgrind could easily complain about. I
    > > don't know that this is the case, but it would certainly make sense to
    > > compare before posting a bug report.

    >
    > you know, this is sheer stupidity.
    >
    > you're suggesting that testing the no-asm code is a valid way of testing
    > the assembly code?


    Whoa, you're getting a tad trigger happy there. I'm not suggesting that
    testing the no-asm code is a valid way of testing the assembly code, you're
    putting words in my mouth. I think my last sentence is pretty clear.
    Debugging and optimising the assembly code is a different ball-game than
    identifying C-level leaks or other bugs in openssl. That's why I suggested
    comparing with a no-asm build. If valgrind sees equivalent problems in both,
    fine. If it sees it only with the assembly optimisations, that's useful
    information too, right?

    > additionally the suggestion of -DPURIFY as a way of testing the code is
    > also completely broken software engineering practice.


    No, it's not. This is a PRNG, not a menu widget. You might also want to test
    with support for symbols and core-dumps, but run without either in
    production. Heisenburgs can also up when running in a debugger vs not running
    a debugger, using optimisation flags selectively, [...]. We have a PRNG, the
    accent is on the "R", not the "P". This is not valgrind's fault, just a
    one-off incompatibility with the notion that "uninitialised"=="catastrophe".

    > any special case changes for testing means you're not testing the REAL
    > CODE.


    With respect, please check the "though shalts" at the door, thanks.

    > for example if you build -DPURIFY then you also won't get notified of
    > problems with other PRNG seeds which are supposed to be providing random
    > *initialized* data.


    This is not true. -DPURIFY does *NOT* compile out the use of *initialised*
    data - that is the whole point. It compiles out any use of *uninitialized*
    data. (Or at least it's supposed to, Bodo thinks there's another case where
    an #ifdef would be needed in the corner case where there's a short width
    parameter - that's beside the point.)

    > not to mention that a system compiled that way is
    > insecure -- so you either have to link your binaries static (to avoid the
    > danger of an insecure shared lib), or set up a chroot for testing.


    Also not true.

    > in any event YOU'RE NOT TESTING THE REAL CODE. which is to say you're
    > wasting your time if you test under any of these conditions.


    You haven't got your facts straight. In fact, I'm starting to suspect you've
    got them deliberately organised in a circle, for the sake of argument. Please
    make sure you're aware of *precisely* what's going on here, and *precisely*
    what -DPURIFY changes in openssl. Otherwise your second sentence is
    theologic, at best.

    > openssl should not be relying on uninitialized data for anything. even if
    > it doesn't matter from the point of view of the PRNG, it should be pretty
    > damn clear it's horrible software engineering practice.


    More "thou shalts". As for your other mail;

    On Monday 19 May 2008 23:48:14 dean gaudet wrote:
    > On Thu, 15 May 2008, Bodo Moeller wrote:
    > > > The use of unititialized data in this case is stupid because the
    > > > entropy of this random data is close to zero.

    > >
    > > It may be zero, but it may be more, depending on what happened earlier
    > > in the program if the same memory locations have been in use before.
    > > This may very well include data that would be unpredictable to
    > > adversaries -- i.e., entropy; that's the point here.

    >
    > on the other hand it may be a known plaintext attack.


    For that sentence to be other than BS, it is a minimum requirement that the
    PRNG be fundamentally broken algorithmically. Please publish, or refrain from
    muddling the issue.

    > what are you guys smoking?


    The charred remains of a debian package, it's very noxious.

    Cheers,
    Geoff
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  10. Re: valgrind and openssl

    On Tue, 20 May 2008, Richard Salz wrote:

    > > on the other hand it may be a known plaintext attack.

    >
    > Using those words in this context makes it sound that you not only don't
    > understand what is being discussed right here and now, but also that you
    > don't understand the term you just used. Are you sure you understood,
    > e.g., Ted Tso's postings in this thread? Perhaps I'm missing something,
    > but can you show me something that talks about known plaintext attacks in
    > the context of hashing/digests?


    yes i abused the term.

    the so-called "uninitialized" data is actually from the stack right? an
    attacker generally controls that (i.e. earlier use of the stack probably
    includes char buf[] which is controllable). i don't know what ordering
    the entropy is added to the PRNG, but if all the useful entropy goes in
    first then an attacker might get to control the last 1KiB passed through
    the SHA1.

    yes it's unlikely given what we know today that an attacker could
    manipulate the state down to a sufficiently small number of outputs, but i
    really don't see the point of letting an attacker have that sort of
    control.

    -dean
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  11. Re: valgrind and openssl

    Think back to what tripped this whole discussion.

    valgrind isn't complaining because the data has been pre-filled, it's
    complaining because it's never been touched.
    i.e if it were attacker providable "buffer contents" then this whole
    discussion wouldn't have happened.

    If the "attacker" can pre-seed uninitialized data in the process, then they
    can read generated keys directly - and that's far easier than by trying to
    second guess the RNG.

    Peter




    From: dean gaudet

    To: openssl-dev@openssl.org

    Date: 05/21/2008 03:44 PM

    Subject: Re: valgrind and openssl






    On Tue, 20 May 2008, Richard Salz wrote:

    > > on the other hand it may be a known plaintext attack.

    >
    > Using those words in this context makes it sound that you not only don't
    > understand what is being discussed right here and now, but also that you
    > don't understand the term you just used. Are you sure you understood,
    > e.g., Ted Tso's postings in this thread? Perhaps I'm missing something,
    > but can you show me something that talks about known plaintext attacks in


    > the context of hashing/digests?


    yes i abused the term.

    the so-called "uninitialized" data is actually from the stack right? an
    attacker generally controls that (i.e. earlier use of the stack probably
    includes char buf[] which is controllable). i don't know what ordering
    the entropy is added to the PRNG, but if all the useful entropy goes in
    first then an attacker might get to control the last 1KiB passed through
    the SHA1.

    yes it's unlikely given what we know today that an attacker could
    manipulate the state down to a sufficiently small number of outputs, but i
    really don't see the point of letting an attacker have that sort of
    control.

    -dean
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org



    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  12. Re: valgrind and openssl

    Peter Waltenberg wrote:
    > Think back to what tripped this whole discussion.
    >
    > valgrind isn't complaining because the data has been pre-filled, it's
    > complaining because it's never been touched.
    > i.e if it were attacker providable "buffer contents" then this whole
    > discussion wouldn't have happened.
    >
    > If the "attacker" can pre-seed uninitialized data in the process, then they
    > can read generated keys directly - and that's far easier than by trying to
    > second guess the RNG.
    >

    Consider this little piece of code:

    #include
    #include

    void f(void)
    {
    char buf[80];

    printf("Please enter a line: ");
    fflush(stdout);
    fgets(buf, sizeof buf, stdin);
    }

    void g(void)
    {
    char buf[80];

    /* Use uninitialized buffer content... */
    printf("Buf contains %s\n", buf);
    }

    int main(void)
    {
    f();
    g();
    return 0;
    }

    On my system, this yields:

    nils@darkstar:~/src$ gcc buf.c
    nils@darkstar:~/src$ ./a.out
    Please enter a line: blark foo
    Buf contains blark foo

    nils@darkstar:~/src$

    :-) The reason this works is that when fgets writes into the stack
    memory, this memory is reused in the function g() without being
    reinitialized.

    So, it is sometimes possible indeed that an attacker will be able to
    provide (some of) the content of uninitialized memory, if he gets to
    interact with the program in some way.

    Regards,

    --
    Nils Gösche
    "Don't ask for whom the tolls."

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  13. Re: valgrind and openssl

    The PRNG is initialized when you initialize OpenSSL, and I'll concede,
    someone COULD use fgets() before that, but it's a really improbable
    scenario and in any case - the PRNG being vulnerable is the least of your
    worries then ....

    Sure you can stuff known data into there - if you are running in the same
    process address space (just read the keys), if you are in the kernel (just
    read the keys), if you have the same UID (or root UID) - (just read the
    keys), you can even do it via fgets(), no argument, your example is valid -
    but can you do it before OpenSSL has been initialized ? - well, maybe some
    badly written code COULD do that, but it doesn't matter, if you controlthe
    stack to that extent you can also engineer a buffer overrun, insert your
    own code and simply read the generated keys - which is much simpler than
    cracking the PRNG.

    As MANY others pointed out - simply putting known data in there doesn't
    decrease the entropy - worst case it's exactly what it was before. (The
    hash function is irreversible in this case - effectively it's compressing
    the data). So best case, you do have data there which is machine or
    instance dependent and the PNG is even less predictable that it was, worst
    case it's as strong as it was before you added the known data.

    I'm not claiming this is "best practice", but it's not intrinsically bad
    either.


    Peter





    From: Nils Gösche

    To: openssl-dev@openssl.org

    Date: 05/21/2008 07:57 PM

    Subject: Re: valgrind and openssl






    Peter Waltenberg wrote:
    > Think back to what tripped this whole discussion.
    >
    > valgrind isn't complaining because the data has been pre-filled, it's
    > complaining because it's never been touched.
    > i.e if it were attacker providable "buffer contents" then this whole
    > discussion wouldn't have happened.
    >
    > If the "attacker" can pre-seed uninitialized data in the process, then

    they
    > can read generated keys directly - and that's far easier than by trying

    to
    > second guess the RNG.
    >

    Consider this little piece of code:

    #include
    #include

    void f(void)
    {
    char buf[80];

    printf("Please enter a line: ");
    fflush(stdout);
    fgets(buf, sizeof buf, stdin);
    }

    void g(void)
    {
    char buf[80];

    /* Use uninitialized buffer content... */
    printf("Buf contains %s\n", buf);
    }

    int main(void)
    {
    f();
    g();
    return 0;
    }

    On my system, this yields:

    nils@darkstar:~/src$ gcc buf.c
    nils@darkstar:~/src$ ./a.out
    Please enter a line: blark foo
    Buf contains blark foo

    nils@darkstar:~/src$

    :-) The reason this works is that when fgets writes into the stack
    memory, this memory is reused in the function g() without being
    reinitialized.

    So, it is sometimes possible indeed that an attacker will be able to
    provide (some of) the content of uninitialized memory, if he gets to
    interact with the program in some way.

    Regards,

    --
    Nils Gösche
    "Don't ask for whom the tolls."

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org



    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  14. Re: valgrind and openssl

    On Tue, May 20, 2008 at 10:43:27PM -0700, dean gaudet wrote:
    > the so-called "uninitialized" data is actually from the stack right? an
    > attacker generally controls that (i.e. earlier use of the stack probably
    > includes char buf[] which is controllable). i don't know what ordering
    > the entropy is added to the PRNG, but if all the useful entropy goes in
    > first then an attacker might get to control the last 1KiB passed through
    > the SHA1.
    >
    > yes it's unlikely given what we know today that an attacker could
    > manipulate the state down to a sufficiently small number of outputs, but i
    > really don't see the point of letting an attacker have that sort of
    > control.


    If this is true, then all digital signatures, certificates, that use
    SHA-1 would have to be discarded. The PRNG will be the least of your
    problems. Consider that if I were to digitally sign this reply, I am
    including in this message text I didn't write (namely, the text which
    you are replying). Or an attacker which gets to "control" network
    packets which are sent out via integrity-protected IPSEC connections.
    Crypto checksums have to be able to deal with this sort of thing, and
    no, they're not affected.

    Controlling the last megabyte of data passed through SHA1 wouldn't
    matter; if you could, then you could induce hash collisions, and SHA-1
    would be totally broken as an crypto checksum.

    - Ted
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4