Hi All,
Multiple Ventors SSH Server Remote Buffer Overflow Vulnerability
http://www.securityfocus.com/bid/17958
This is a _server_ side vulnerability, but what a coincidence!!!
You guys without Putty: Are you sure that there was _never_
any remote connection as root from any side?
Frank
I had problems starting at the exact same time but on Solaris, where
they manifested as a EINVAL return from pthread_cond_tomedwait. After a
day of tracing the problem with debug builds and working with my
sysadmin to track what changed (of course, nothing had) I cam to the
same 1 billion
dhogaza@PACIFIER.COM wrote:
I have three servers running identical installations of
AOLserver/3.3.1+ad13. On two (development and production, very low and
relatively low traffic volumes respectively) all scheduled procs have
stopped firing.
My God, it sounds to me like you're all being
'Jesus' Jeff Rogers wrote:
I had problems starting at the exact same time but on Solaris, where
they manifested as a EINVAL return from pthread_cond_tomedwait. After
a day of tracing the problem with debug builds and working with my
sysadmin to track what changed (of course, nothing had) I
On May 19, 2006, at 1:04 PM, 'Jesus' Jeff Rogers wrote:
The only bug is that Ns_CondTimedWait doesn't do any wraparound on
the time parameter. All the same, I've been enjoying telling
people that I hit my first y2038 bug.
So are you saying you've fixed it, or just that you've narrowed it
On 2006.05.19, 'Jesus' Jeff Rogers [EMAIL PROTECTED] wrote:
Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on my
database connections.
Ahahaha! Yes, in the back of my head I always wondered (and never
bothered to compute) when that silly value of 10^9 would bite someone.
I fixed it by simply changing my MaxOpen/MaxIdle settings to 0 which
is interpreted as forever which is probably what the original one
BILLION seconds was undoubtedly intended to be.
It probably wouldn't hurt for Ns_AdjTime (in nsthread/time.c) to check
for negative seconds and have it fail
Ahhh good detective work.
Problem solved.
Thanks!!!
Zach Shaw
Web Developer, Library and Technology Services
Brandeis University
[EMAIL PROTECTED]
781-736-4206
On May 19, 2006, at 4:32 PM, 'Jesus' Jeff Rogers wrote:
I fixed it by simply changing my MaxOpen/MaxIdle settings to 0
which
Stan Kaufman wrote:
Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on
my database connections. My system is ACS-derived, so I wouldn't be
surprised if these database settings are common in other ACS-derived
systems.
What do you think is the reason that not all systems
On 5/19/06, 'Jesus' Jeff Rogers [EMAIL PROTECTED] wrote:
I imagine on Linux it manifests differently; on Solaris I got the EINVAL
return from pthread_cond_timedwait (of course it isn't documented that
this can mean a bad time, it usually means a bad pointer) but on linux
with a different
dhogaza@PACIFIER.COM wrote:
My God, it sounds to me like you're all being bit by the Y2.006K
problem! :)
That answer is closer than you think (at least if everyone is having the
same problem I was) ... actually it's Y2.038K
Yes, indeed, I suspect everyone here on the list is aware of the
On 2006.05.19, 'Jesus' Jeff Rogers [EMAIL PROTECTED] wrote:
Ahahaha! Yes, in the back of my head I always wondered (and never
bothered to compute) when that silly value of 10^9 would bite someone.
Guess it's May 12, 2006. :-)
Can everyone who's affected go and change MaxIdle and MaxOpen
On 2006.05.19, 'Jesus' Jeff Rogers [EMAIL PROTECTED] wrote:
I admit I've not been paying as close attention to this thread as I might,
as I've not used 3.3 in years.
Next time remind me that this is a good reason to think before posting,
folks!
--
AOLserver - http://www.aolserver.com/
To
On Fri, May 19, 2006 at 02:30:54PM -0700, dhogaza@PACIFIER.COM wrote:
(which I think was done to work around some ancient bug in an ancient
version of the nsoracle driver) then you get the problem.
I think the problem was in the oracle library (OCI), but it's been a long,
long time.
Yep.
'Jesus' Jeff Rogers wrote:
Simple, because it's a config file setting, not anything to do with
the underlying system. If your config file has
[ns/db/pool/main]
MaxOpen=10
MaxIdle=10
(which I think was done to work around some ancient bug in an ancient
version of the nsoracle
Stan Kaufman wrote:
Not defining these two vars must have been the way the 3.2.5 config
file was distributed back in the day
Yup, that was the case: http://openacs.org/doc/openacs-3/nsd.txt
Interesting that that inoculated OpenACS 3.2.5 systems from this problem.
--
AOLserver -
On Fri, May 19, 2006 at 02:30:54PM -0700, dhogaza@PACIFIER.COM wrote:
# You can also set
# them to zero, but at the time the bug was discovered, AOLserver had
# a bug that prevented you from setting them to zero.
Yeah, I knew there was a reason a big number rather than zero was chosen,
On 2006.05.19, Stan Kaufman [EMAIL PROTECTED] wrote:
Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on
my database connections.
My system is ACS-derived, so I wouldn't be surprised if these database
settings are common in other ACS-derived systems.
What do you think is
On 2006.05.19, dhogaza@PACIFIER.COM dhogaza@PACIFIER.COM wrote:
The billion seconds added to the current time when the database handle's
created is causing the problem, with Solaris being nice enough to toss an
error, Linux just screwing up.
To be fair, Linux isn't screwing up -- the
On 2006.05.19, dhogaza@PACIFIER.COM dhogaza@PACIFIER.COM wrote:
On Fri, May 19, 2006 at 02:30:54PM -0700, dhogaza@PACIFIER.COM wrote:
# You can also set
# them to zero, but at the time the bug was discovered, AOLserver had
# a bug that prevented you from setting them to zero.
Dossy Shiobara wrote:
Generally, the only time I've seen people config the MaxOpen and MaxIdle
to 1B seconds is when they're using an ACS or OpenACS recommended
configuration.
It might be a good idea for the OpenACS folks to edit/update their
documentation and sample configs to correct this, as
On 2006.05.19, Stan Kaufman [EMAIL PROTECTED] wrote:
It might be a good idea for the OpenACS folks to edit/update their
documentation and sample configs to correct this, as well ... although
it'll never be May 13, 2006 ever again, so maybe it's a non-issue. :-)
Now that zero works, we'll
If only folks chose 10^8 instead of 10^9 ... it would have been 1157
days or 3.1 years worth of MaxOpen/MaxIdle, and we wouldn't have
encountered this weird thread hanging bug until Nov 18, 2034. :-)
-- Dossy
Shit like this happens when you know your software platform's reliable and
may not
If only folks chose 10^8 instead of 10^9 ... it would have been 1157
days or 3.1 years worth of MaxOpen/MaxIdle, and we wouldn't have
encountered this weird thread hanging bug until Nov 18, 2034. :-)
-- Dossy
Shit like this happens when you know your software platform's reliable! :)
--
24 matches
Mail list logo
