Re: DSA 438 - bad server time, bad kernel version or information delayed?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings,
> > > >> Does this mean, that a well known exploit was kept back for nearly
> > > >> three weeks, just because some odd vendors were unable to build
> > > >> there kernels in time?
> > > >
> > > > Yes, this is the norm. Debian hides security bugs from its users for
> > > > extended periods of time.
> > >
> > > Yes but this have a reason. Before upload a fix this need be available
> > > in all supported archs and tested since major or users install it
> > > trusting Debian Security Team and 'cause of this, should not fail ;-)
> >
> > Well, of course you might have quite good reasons for doing so, but for
> > me, this is quite a good reason for changing the distri or os.
> > Hiding unfixed holes is one thing (and I appreciate that partly) but
> > hiding already fixed packages is quite astonishing and you cannot tell me
> > you need more than two weeks to test a simple correction.
>
> Take it easy.
I take security threads serious. Think of beeing avoidable vulnerable for
nearly three weeks is a pain in my stomach.
> Maybe you are right, you should switch to another O/S. I
> bet you they coordinate and delay disclosure as well. Or better yet,
> you can switch to MS, which you are lucky if you get a patch in 2 weeks
> time.
M$, you are kidding ;)
> Look at it this way:
>
> Debian Security Team (DST) finds out about a security bug from an
> organization (let's say CERT for the sake of discussion). CERT asks
> Debian to prepare for release but delay disclosure until further notice
> so all the CERT Coordinated Vendors (I believe Debian is one) can get on
> board. Debian decides to go against CERT and release immediately after
> the fix is made. CERT then decides they will no longer tell DST in
> advance since they breached trust. DST then finds out about the
> vulnerability the same time the "rest" of the world does. DST then
> rushes about (after the announcement) to put together a package and
> release a DSA. By now they are several hours or a day behind everyone
> else.
>
> Would you still prefer DST ignore coordinated release schedules? If
> so...perhaps you are correct...you could switch to a different O/S or
> Distro. Let's see:
>
> RedHat....Going Commercial..hope you have a deep pocket book. (BTW, they
> obey coordinated releases also).
> Fedora....Still in it's infancy and organizing from the RedHat break
> off.
> Mandrake...They have Coordinated releases too.
> Any other distro....do they have security releases?
But the dominance of the CERT is excactly the point I'm criticising. Even it
is necessary to coordinate the sec affords - imho fixies should be applied if
they are ready and not if some organisation say so.
> Anyhow, please sit back, take a few deep breaths and stop throwing such
> a stink.
ok.
> > May I ask you what local / remote root exploit-fixes are you holding back
> > currently? Should I switch of my sshd for the next few days or does the
> > current bash have an unfixed local root exploit?
>
> Not worth answering
Please don't take it serious - it was meant to be ironic. I beg you pardon, if
you are insulted by that.
> > This is exactly the same policy M$ have - but the point is, you could at
> > least inform your users.
>
> Yes, inform the users, let the ENTIRE hack community know, don't provide
> a fix. Then the release coordinator (CERT) gets mad at you...see above.
> How is this any better?
This is not what I'm talking about - unfixed vuln. must be held back.
> > An unknown local root exploit was one of the key parts in the debian
> > server compromise and we have all seen the consequences.
>
> Yes, it was. There are probably several hundred "unknown local root
> exploits". The source code is open, why not put your words into action
> and start finding some flaws?
I neither have the knowlegde nor the time for doing that.
But the point at is, that these vuln. are not avoidable at the moment - the
last has been avoidable for nearly three weeks.
> > Surely, you can see, that I want to keep this risk as small as possible
> > on my servers.
>
> I do also.
well, it seems, that we agreed at last ;)
Keep smiling
yanosz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iQIVAwUBQDPmqNAHMQ8GQaYRAQJRPA//QsTfQrTC4AS6TGwZMQz6mo2t+0TI5Ulq
93bquRnk+mXSYTgOoOC925YJ5O5Vj/9qUMqk8aQq0LQx5g+qOM31vTKRCUBY8XIp
aWuVXiL1iMvncwJGURzyweew0QHb1RYsl7zr9RMZS2M1QwxdfnI2INcevwaBUG3n
QDUnxWAokSxkNMRDlojaFEzzlW3iFauVrzPqr1AfO0+xv78mi6YGxBVvLIWbx/0S
lw0yc2Pm0Cd3YzSFx5tqKortMeTYt1rkiCyPPlq/uCSLoIygtHrII4N/IuBPKFMW
I3xAuNs2cHM92V33Oac4juUs7j35jaQecEZPNKQZ0QPp4pgcSSQ2Mda56/bNC0sl
SzjLJPiVN6akLx4naxssmF2Rw61J/Z9PiEXnwX2/kc6gCs2y4+s5SFY8FKnyIjVe
7tBdilImLMt63CgdRRb332Ji3MNXjmdx8lbyJep0wHvvixslAwhfKjkv0bV/6+lB
r+7c2bQ5uOvWS+TXZg9GCVeuBH2l8tRcWnuN7OWfV7H5XdAWGZ6ewVxgg6Vf2FFC
bgqJ79PMDHFj8/zBmihedefKXu06qGQs/4tCBqQH3xKmgsArmSvsfxLx4CFfB5/X
J6Bt66N2S58ZMkrRp+wiQqkFrI24euAPcHxQLloi2zSYuItilMF3/Stqkedgr/09
BSms9+Cean8=
=Sp85
-----END PGP SIGNATURE-----
Reply to: