Ben Greenbaum wrote:
As I expected, there has been a flood of responses to the news about ISC's
plan for a bind-members program. Rather than approve each, I have
summarized many of them here.
Personally, from what I'm seeing in these responses, a lot of people are
jumping to conclusions, and
Sorry for the strong words, but the ISC is fucked up, apparently. But I
should have guessed that when I first (tried to) read the later versions
of bind source (with apologies to Bill Norton the original project
manager for that development). I just had to be slapped in the face with
it
When I first saw this, I thought the same as most others. However,
it's possible that this approach may have merit. If I found a hole
and could update the root servers before disclosure, I'd certainly
do it.
The more people you can inform without tipping off the black hats,
the better. I guess
---
Immunix OS Security Advisory
Packages updated: glibc
Effected products: Immunix OS 6.2
Bugs Fixed: immunix/1322
Date: February 1, 2001
Advisory ID:
How did this get approved, did anyone test it or review it?
Didn't you? - I'd rather see the information despatched to us quickly and
treat it with caution, than have delays introduced whilst the code is
rigorously tested. The moderators already have a lot on their plate without
dumping this
On Wed, 31 Jan 2001, Theo de Raadt wrote:
What does the community think of this change in direction?
(Myself, I think it is a terrible idea to charge money for security
information access, and that closing BIND up like this is also going
to be harmful)
Ok, just some comments that I haven't
It would be interesting to see how many of the bugs in BIND have been found
by Whitehats and how many have been found by Blackhats.
Any bug that has been found by a Blackhat should be made public instantly,
because by the time Whitehats find out about the bug, it is already being used.
IMHO,
On Thu, Feb 01, 2001 at 02:20:20PM +0100, Tomasz Kuzniar wrote:
Hi,
bug same as provious in man on debian (suse also?).
Just look:
mezon@beata$ m4 -G %x%x%x%x
m4: 40012a48380491e00: No such file or directory
mezon@beata$
or
mezon@beata$ m4 -G %p
m4: 0x40012a48: No such file or
Someone, please, tell me there
is an another
alternative - because with the direction it's headed now, the
Internet based on
bind isn't looking like it's going to be a very good, reliable, or secure,
network.
regrets,
--dr
We've all managed to survive using BIND for the past x years - I
On Wed, Jan 31, 2001 at 02:22:01PM -, Joao Gouveia wrote:
: The man package that ships with SuSe Linux ( at least versions 6.1 throught
: 7.0 ) has a format string vulnerability. Also debian 2.2r2 ( at least ), is
: confirmed to have the same problem.
:
: quote
: jroberto@spike:~ man -l
Hello!
We have found a bug in the GoAhead WebServer, v.2.0 and v.2.1.
Attacker can get any file from the drive, where web-server was installed.
try follow request
http://www.somehost.com/..\..\..\..\..\..\autoexec.bat
This vulnerability may allow an attacker to execute code with the
Michael Bryan wrote:
I get the feeling people saw "members only" and "fee-based",
and immediately assumed -everything- was changing. But it's not.
In discussions with my colleagues, the concern isn't that "everything is
changing"... the concern is the "slippery slope".
- Arf, JT
In message [EMAIL PROTECTED], Hendy * writes:
On Wed, Jan 31, 2001 at 02:13:07PM -0500, Lucas Holt wrote:
Hiding a version number does not someone who knows what they are doing, but
it
does stop script kiddies out there. If a 14 year old kid can not figure ou
t what
they are dealing
Hi folks,
Something i came across while testing some of our WebSphere installations
(these have been fixed in the current versions of vanilla Apache, so i assume
these are just an inherited problem from the old Apache codebase.. Makes
you wonder what else there is? :^) )
Retreiving:
Hi,
RedHat 6.1/6.2 also have this problem:
REDHAT 6.2
[root@haendel mmh]# m4 -G %pm4: 0x401091ec: No
existe el fichero o el directorio
REDHAT 6.1
[root@mandanga mmh]# m4 -G %pm4: 0x4010548c: No
existe el fichero o el directorio
Manuel Martinez.
Cooper [EMAIL PROTECTED] writes:
Now, could someone explain to me why a select list of individuals should
get an earlier warning?
I think this is the crux of the matter. Before you can say that this
is a good idea, you first have to show that some people should get
early notice. Quite
1. Inform the BIND developers.
They will privately handle the issue, create some sort of patch or
update and then send out a notification so that people know they need to
upgrade. A day or so later the exploit for the problem can go public and
everybody's happy. This is probably the way
Hi all,
Do we really need to be worried that much about ISC's decision to create a
fee-based membership forum? I think that the major problem is with the
wording Paul Vixie's `pre-announcement.' The line below is somewhat
ambiguous to me:
2. Vendors who include BIND in their
On Fri, 2 Feb 2001, Shalon Wood wrote:
Cooper [EMAIL PROTECTED] writes:
Now, could someone explain to me why a select list of individuals should
get an earlier warning?
I think this is the crux of the matter. Before you can say that this
is a good idea, you first have to show that some
Shalon Wood wrote:
Cooper [EMAIL PROTECTED] writes:
Now, could someone explain to me why a select list of individuals should
get an earlier warning?
I think this is the crux of the matter. Before you can say that this
is a good idea, you first have to show that some people should get
On Fri, Feb 02, 2001 at 07:06:23AM -0600, Shalon Wood ([EMAIL PROTECTED]) was heard to
have said:
Cooper [EMAIL PROTECTED] writes:
Now, could someone explain to me why a select list of individuals should
get an earlier warning?
I think this is the crux of the matter. Before you can say
On Fri, 2 Feb 2001, Shalon Wood wrote:
So, my question to Paul and company is: Why *should* anyone other than
critical infrastructure get that notice? I'm willing to be convinced;
I just haven't seen an answer to this question yet. And note that
'They bitched and screamed because we didn't
Jan Vroonhof writes:
If you are using XEmacs we suggest upgrading to XEmacs 21.1.14
that contains this version (or 21.2.35 if you are running betas).
Err.. that's 21.2.43
Klaus
SUMMARY
All currently available versions of gnuserv for unix prior to 3.12 are
vulnerable to remote exploit due to a buffer overflow and weak
security. Gnuserv is a remote control facility for Emacsen. Gnuserv
ships with XEmacs but is also available stand-alone from various
sources for use with
Vendor: Netscape
Product: Enterprise Server 3.5.1 (and others?)
Specifics: Netscape Web Publisher
Vulnerability Briefing: A very wide problem with ACL settings and default
settings with Netscape Enterprise Server (Publisher).
Description:
With the default installation of Netscape Enterprise
On Fri, Feb 02, 2001 at 08:03:09PM +0100, Przemyslaw Frasunek wrote:
BTW. Old BSD derived ftpd is also used in opieftpd and SSLftpd. Both are
vulnerable to this attack.
In case anyone is wondering how old is old:
revision 1.5
date: 1996/11/20 22:12:50;
On Fri, Feb 02, 2001 at 03:04:31PM -0800, Kris Kennaway wrote:
BTW. Old BSD derived ftpd is also used in opieftpd and SSLftpd. Both are
vulnerable to this attack.
In case anyone is wondering how old is old:
The same problem persists in heimdal / kerberosIV ftpd implementation:
"Dragos" == Dragos Ruiu [EMAIL PROTECTED] writes:
Dragos Not only is it NOT solid according to past record
So I suppose the 10-12,000 DNS queries that get answered every second
by a.root-servers.net or the ~5,000/second that f.root-servers.net
answers are handled by something that
28 matches
Mail list logo
