Shachar Shemesh <[EMAIL PROTECTED]> writes:and also
Also, has anybody checked what other versions are affected?
Nothing before 7.4, at least by the known implications of this issue. Again, if we wait a while and let Ken keep running his analysis tool, he might turn up other stuff we need to fix. Maybe even stuff that needs a fix much worse than this does.
I frankly think that this discussion is emblematic of all the worstI totally agree. That's why I suggested preventing the automatic public disclosure for Ken's next bugs, as well as anyone else's. This way, if we do need a few extra days, we can have them while still limiting the window of exposure.
tendencies of the security community. Have you forgotten the fable
about the boy who cried "wolf"?
I repeat: in my estimation this is not a bug that needs a fix yesterday.I'm sorry. Maybe it's spending too many years in the security industry (I've been Check Point's "oh my god we have a security problem" process manager for over two years). Maybe it's knowing how to actually exploit these problems. Maybe it's just seeing many of the good guys (OpenBSD's Theo included) fall flat on their faces after saying "This is a DoS only". In my book, a buffer overrun=arbitrary code execution.
AFAICS it would be very difficult to cause more than a nuisance DOS with
it, and there are plenty of other ways for authenticated database users
to cause those.
For a now famous example of a bug declared "non exploitable", followed by an exploit, see http://www.theinquirer.net/?article=4053. I have been on the mailing lists at the time. The problem was declared "unexploitable on i386" by some of the best known names in the security industry of the time.
regards, tom lanePlease. I'm not saying "Release now". I'm saying "get a mechanism for smarter handling of future events".
Shachar
-- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
