headers
Dennis den Brok | 8 Apr 2009 21:05
Picon

ssl issues in 4.x?

I was wondering whether the recent issues with OpenSSL don't apply
to netbsd-4, as I haven't seen any pullups or requests thereof
regarding them. Is that so, or has this just been forgotten about?

Regards,

Dennis den Brok
Permalink | Reply | 0 comments |
headers
Matthias Drochner | 9 Apr 2009 12:56
Picon
Picon
Favicon

Re: ssl issues in 4.x?


> I haven't seen any pullups or requests

I forgot about 4.x. Just checked: CMS was added later,
so CVE-2009-0591 does not apply.
The ASN1 printing crash (CVE-2009-0590) seems to apply.
The Invalid ASN1 clearing check (CVE-2009-0789) might
apply, but since this is only an issue with the windows
ABI we don't need to take the risk.
Could you (or someone else) pull the patches into
a 4.x tree and check whether everything still builds
(and works)? That would be:

cvs rdiff -u -r1.9 -r1.10 src/crypto/dist/openssl/crypto/asn1/asn1.h
cvs rdiff -u -r1.1.1.8 -r1.2 src/crypto/dist/openssl/crypto/asn1/asn1_err.c
cvs rdiff -u -r1.8 -r1.9 src/crypto/dist/openssl/crypto/asn1/tasn_dec.c

In the tasn_dec.c patch, the first two hunks (removal of a NULL
assignment) belong to CVE-2009-0789. As said, I'd leave them out
for now.

thanks
Matthias

-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich

Sitz der Gesellschaft: Juelich
(Continue reading)

Permalink | Reply | 501 comments |
headers
Dennis den Brok | 9 Apr 2009 14:24
Picon

Re: ssl issues in 4.x?

Matthias Drochner <M.Drochner <at> fz-juelich.de> schrieb:
> Could you (or someone else) pull the patches into
> a 4.x tree and check whether everything still builds
> (and works)? That would be:
>
> cvs rdiff -u -r1.9 -r1.10 src/crypto/dist/openssl/crypto/asn1/asn1.h
> cvs rdiff -u -r1.1.1.8 -r1.2 src/crypto/dist/openssl/crypto/asn1/asn1_err.c
> cvs rdiff -u -r1.8 -r1.9 src/crypto/dist/openssl/crypto/asn1/tasn_dec.c
>

I will, unless somebody beats me to it, as I probably won't get
around to doing so before next week. Thanks already for the
information.

Regards,

Dennis den Brok
Permalink | Reply | 501 comments |
headers
Dennis den Brok | 17 Apr 2009 11:11
Picon

net/pptp is not vulnerable to RH bug 492090

The bug report refers to a helper application called "pptpsetup",
apparently supplied with linux versions, but this does not seem to
exxist in the pkgsrc package. I'm not sure how this should reflect
in pkg-vulnerabilities, but a false warning by audit-packages seems
wrong to me.

Regards,
Dennis den Brok
Permalink | Reply | 0 comments |
headers
Elad Efrat | 20 Apr 2009 03:23
Picon

secmodel_{,de}register()

Hi,

I'm a little bit concerned that secmodel_deregister() just lowers the
number of secmodels registered without asking for too much. Obviously
this isn't a problem yet, but I'm trying to think if we are letting
newly introduced kernel code (say, a module) simply neutralize kauth(9)
for the entire system.

Since a kauth(9) listener does not have to be part of a secmodel, we
can't really rely on the answers we're getting from listeners if at all
to decide whether we *really* don't have a secmodel or nsecmodels was
just lowered by repeated calls to secmodel_deregister() (that's possible
on non-DIAGNOSTIC kernels).

One thing I thought about was to add some sort of "key" that would be
generated and returned by secmodel_register(). This key is to be used
when calling secmodel_deregister(), to make sure the caller did register
a secmodel.

Of course, this solves potential API abuse only.

Given the fact that we're talking about kernel code, and that we
don't yet have a solution for protecting from simply accessing the
nsecmodels variable (or the list of keys if we decide to solve it
using the above), do we still want to prevent the possible API abuse?

Thanks,

-e.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Antti Kantee | 20 Apr 2009 04:20
Picon
Picon

Re: secmodel_{,de}register()

On Mon Apr 20 2009 at 04:23:45 +0300, Elad Efrat wrote:
> Hi,
> 
> I'm a little bit concerned that secmodel_deregister() just lowers the
> number of secmodels registered without asking for too much. Obviously
> this isn't a problem yet, but I'm trying to think if we are letting
> newly introduced kernel code (say, a module) simply neutralize kauth(9)
> for the entire system.
> 
> Since a kauth(9) listener does not have to be part of a secmodel, we
> can't really rely on the answers we're getting from listeners if at all
> to decide whether we *really* don't have a secmodel or nsecmodels was
> just lowered by repeated calls to secmodel_deregister() (that's possible
> on non-DIAGNOSTIC kernels).
> 
> One thing I thought about was to add some sort of "key" that would be
> generated and returned by secmodel_register(). This key is to be used
> when calling secmodel_deregister(), to make sure the caller did register
> a secmodel.
> 
> Of course, this solves potential API abuse only.
> 
> Given the fact that we're talking about kernel code, and that we
> don't yet have a solution for protecting from simply accessing the
> nsecmodels variable (or the list of keys if we decide to solve it
> using the above), do we still want to prevent the possible API abuse?

What are you trying to protect against?  bugs?  Sounds like quite a
radical bug.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Elad Efrat | 20 Apr 2009 10:30
Picon

Re: secmodel_{,de}register()

On Mon, Apr 20, 2009 at 5:20 AM, Antti Kantee <pooka <at> cs.hut.fi> wrote:

> What are you trying to protect against?  bugs?  Sounds like quite a
> radical bug.

Ideally, trying to protect against malicious kernel code degrading the
security of the system, but I guess we're not there yet (google for
KERNSEAL).

> Why not just register an unremovable allow-all secmodel and get rid
> of special case nsecmodels==0 completely (or is it necessary for
> bootstrapping)?

Because it doesn't solve the problem I really care about.

Anyway, I was just putting it out there, but the more I think of it the
more I realize it's not something we should care about at this point.

Sorry for the noise,
-e.
Permalink | Reply | 0 comments |

Gmane