Re: CVE request: crypt_blowfish 8-bit character mishandling

[Josh Bressers <bressers () redhat com>]

Please use CVE-2011-2483.

Sorry I missed this yesterday. I suspect I got caught up reading up on it.

-- 
    JB


----- Original Message -----
> Steve -
>
> Can I have a CVE id, please? ASAP, or I am releasing without referring
> to a CVE id.
>
> On Mon, Jun 20, 2011 at 03:43:20PM +0000, The Fungi wrote:
> > No, I agree your proposed approach lends a more general solution
> > which could be applied to the use cases I was considering. I saw you
> > mention it over on the crypto list as well, but it sounded like you
> > were trying to find ways to avoid a new hash encoding identifier in
> > the wild which could conflict with something OpenBSD might consider
> > assigning for some other purpose at a later date (though assuming
> > this workaround makes it onto their radar, that seems an unlikely
> > situation anyway).
>
> Of course, I need to inform them that we're taking "$2x$" for our
> backwards compatibility feature.
>
> Here's how I am dealing with the issue in code:
>
> Bug fix, plus a backwards compatibility feature:
>
> http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/crypt_blowfish.c.diff?r1=1.9;r2=1.10
>
> 8-bit test vectors added, for both modes (correct and buggy):
>
> http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/wrapper.c.diff?r1=1.9;r2=1.10
>
> These are only used by "make check", which I felt was not enough -
> many
> people are taking just the main C file and use it in their programs.
> Obviously, my "make check" would not exist in their source code trees.
> So if those programs are ever miscompiled or otherwise broken, it
> might
> not be detected. To deal with this, I added:
>
> Quick self-test on every use:
>
> http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/crypt_blowfish.c.diff?r1=1.10;r2=1.11
>
> I am likely to go ahead and release this.
>
> Alexander