Re: ISP network registration virus scan
Sean Donelan wrote: The university netreg lists has a frequently asked question if its possible to perform a virus scan of new computers as part of the network registration process. So far, people have only been able to do a network scan (e.g. open ports), or some version of proxy check or nessus. The University of Florida has implemented something like this. Apparently, they have a client-side app that detects malware...and P2P apps. Interesting concept but it's understandably not being received well. http://yro.slashdot.org/yro/03/10/03/1643202.shtml apl
Heads up -- potential problems in 3.7, too? [Fwd: OpenSSH Security Advisory: buffer.adv]
3.7.1 was just released.
Two patches for similar issues in a very short timeframe. Who do they
think they are -- Microsoft?
apl
Original Message
Subject: OpenSSH Security Advisory: buffer.adv
Date: Wed, 17 Sep 2003 01:13:30 +0200
From: Markus Friedl <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
This is the 2nd revision of the Advisory.
This document can be found at: http://www.openssh.com/txt/buffer.adv
1. Versions affected:
All versions of OpenSSH's sshd prior to 3.7.1 contain buffer
management errors. It is uncertain whether these errors are
potentially exploitable, however, we prefer to see bugs
fixed proactively.
Other implementations sharing common origin may also have
these issues.
2. Solution:
Upgrade to OpenSSH 3.7.1 or apply the following patch.
===
Appendix A: patch for OpenSSH 3.6.1 and earlier
Index: buffer.c
===
RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
retrieving revision 1.16
retrieving revision 1.18
diff -u -r1.16 -r1.18
--- buffer.c26 Jun 2002 08:54:18 - 1.16
+++ buffer.c16 Sep 2003 21:02:39 - 1.18
@@ -23,8 +23,11 @@
void
buffer_init(Buffer *buffer)
{
- buffer->alloc = 4096;
- buffer->buf = xmalloc(buffer->alloc);
+ const u_int len = 4096;
+
+ buffer->alloc = 0;
+ buffer->buf = xmalloc(len);
+ buffer->alloc = len;
buffer->offset = 0;
buffer->end = 0;
}
@@ -34,8 +37,10 @@
void
buffer_free(Buffer *buffer)
{
- memset(buffer->buf, 0, buffer->alloc);
- xfree(buffer->buf);
+ if (buffer->alloc > 0) {
+ memset(buffer->buf, 0, buffer->alloc);
+ xfree(buffer->buf);
+ }
}
/*
@@ -69,6 +74,7 @@
void *
buffer_append_space(Buffer *buffer, u_int len)
{
+ u_int newlen;
void *p;
if (len > 0x10)
@@ -98,11 +104,13 @@
goto restart;
}
/* Increase the size of the buffer and retry. */
- buffer->alloc += len + 32768;
- if (buffer->alloc > 0xa0)
+
+ newlen = buffer->alloc + len + 32768;
+ if (newlen > 0xa0)
fatal("buffer_append_space: alloc %u not supported",
- buffer->alloc);
- buffer->buf = xrealloc(buffer->buf, buffer->alloc);
+ newlen);
+ buffer->buf = xrealloc(buffer->buf, newlen);
+ buffer->alloc = newlen;
goto restart;
/* NOTREACHED */
}
Index: channels.c
===
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.194
retrieving revision 1.195
diff -u -r1.194 -r1.195
--- channels.c 29 Aug 2003 10:04:36 - 1.194
+++ channels.c 16 Sep 2003 21:02:40 - 1.195
@@ -228,12 +228,13 @@
if (found == -1) {
/* There are no free slots. Take last+1 slot and expand the array. */
found = channels_alloc;
- channels_alloc += 10;
if (channels_alloc > 1)
fatal("channel_new: internal error: channels_alloc %d "
"too big.", channels_alloc);
+ channels = xrealloc(channels,
+ (channels_alloc + 10) * sizeof(Channel *));
+ channels_alloc += 10;
debug2("channel: expanding %d", channels_alloc);
- channels = xrealloc(channels, channels_alloc * sizeof(Channel *));
for (i = found; i < channels_alloc; i++)
channels[i] = NULL;
}
===
Appendix B: patch for OpenSSH 3.7
Index: buffer.c
===
RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- buffer.c16 Sep 2003 03:03:47 - 1.17
+++ buffer.c16 Sep 2003 21:02:39 - 1.18
@@ -23,8 +23,11 @@
void
buffer_init(Buffer *buffer)
{
- buffer->alloc = 4096;
- buffer->buf = xmalloc(buffer->alloc);
+ const u_int len = 4096;
+
+ buffer->alloc = 0;
+ buffer->buf = xmalloc(len);
+ buffer->alloc = len;
buffer->offset = 0;
buffer->end = 0;
}
@@ -34,8 +37,10 @@
void
buffer_free(Buffer *buffer)
{
- memset(buffer->buf, 0, buffer->alloc);
- xfree(buffer->buf);
+ if (buffer->alloc > 0) {
+ memset(buffer->buf, 0, buffer->alloc);
+ xfree(buffer->buf);
+ }
}
/*
Index: channels.c
===
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.194
retrieving revision 1.195
diff -u -r1.194 -r1.195
--- channels.c 29 Aug 2003 10:04:36 - 1.194
+++ channels.c 16 Sep 20
Re: What *are* they smoking?
"The information provided through the VeriSign Services is not necessarily complete and may be supplied by VeriSign's commericial licensors, advertisers or others." There's something immoral about *shoving it down our throats*, then, VeriSign. apl Adam 'Starblazer' Romberg wrote: Can they realistically enforce a TOS on a site like that, and how can they provide a remedy for it? I, for one, do not agree to their terms of service. Thanks -a- Adam 'Starblazer' Romberg Appleton: 920-738-9032 System Administrator ExtremePC LLC-=- http://www.extremepcgaming.net
Re[2]: What *are* they smoking?
I called VeriSign the registrar and got a supervisor, Forsyth. I spoke to him briefly about this filthy practice. He said that VeriSign GRS deals *only* with registrars; customer support at NetSOL (great abbreviation) can't even get in contact with them. It doesn't seem like they have much communications or unification between the GRS (which handles the TLDs), the registrar (which does actual registrations), and their security arm. He relayed me to the corporate office, and gave me this contact information: 487 East Middlefield Road Mountain View, CA 94043 1 (650)-961-7500 Good luck! :) apl Alex Lambert wrote: http://www.verisign.com/corporate/about/contact/index.html Give 'em hell. apl Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. -- Niels.
Re: What *are* they smoking?
http://www.verisign.com/corporate/about/contact/index.html Give 'em hell. apl Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. -- Niels.
Re: Sea sponge builds a better glass fiber
I'm still waiting for the discovery of its natural enemy, the Backhoeiosaur. apl Eric Kuhnke wrote: http://www.msnbc.com/news/954985.asp?0dm=C12MT Associated Press Scientists say they have identified an ocean sponge living in the darkness of the deep sea that grows thin glass fibers capable of transmitting light at least as well as industrial fiber optic cables used for telecommunication. The natural glass fibers also are much more flexible than manufactured fiber optic cable that can crack if bent too far. "YOU CAN ACTUALLY tie a knot in these natural biological fibers and they will not break -- it's really quite amazing," said Joanna Aizenberg, who led the research at Bell Laboratories.
Re: Power outage in North East
CNN reports that Toronto is out, also. apl Damian Gerow wrote: Thus spake Joel Perez ([EMAIL PROTECTED]) [14/08/03 16:27]: Has anyone heard of a big Power outage in the North east? I just got a call from one of my tech's in the GBLX bldg in Newark, NJ at 1085 raymond and they are telling him that they lost power! But I also got a call from AT&T in NY that they also lost Power! It looks like a rather large power outage -- we're in South Western Ontario, Canada, and power is out in Waterloo, Cambridge, Guelph, Hespler, and (I'm pretty sure) London as well. Can't say about Toronto. - Damian
Re: State Super-DMCA Too True
> From: "Stephen Sprunk" <[EMAIL PROTECTED]> > Common carrier status exists for this very reason. Unfortunately, it > probably means we'll have to stop filtering things like spam and DoS, since > filtering on content inherently violates common carrier protection -- see > the smut suit against AOL a few years ago. Allow me to continue to pummel the poor horse -- What about the customer that requests that the telco block calls from certain numbers? I don't think that affects common carrier status, but IANAL. apl
Re: State Super-DMCA Too True
> If you price your product on the assumption that the average customer only > uses 5% of their bandwidth then it doesn't take many customers using 50% > or 100% of it to really spoil your economics Personal Telco has some interesting opinions on this: http://www.personaltelco.net/index.cgi/StealingBandwidth?action=highlight&va lue=CategoryPhilosophy (quoting) "Traditional broadband providers cry foul when users take their cable modem or DSL connections and beam them to friends, family and passsers-by through Wi-Fi networks. "It constitutes a theft of service per our user agreement," says AT&T Broadband's Sarah Eder. But at least one very important observer doesn't buy that. "I don't think it's stealing by any definition of law at the moment," says FCC chairman Michael Powell. "The truth is, it's an unintended use." apl
Re: Odd DNS responses for www.neopets.com
> Maybe it's just me, but isn't there something odd about a DNS query > coming back with 78 entries for the same host? It sends back an UDP > packet that gets truncated and the DNS resolver reverts to TCP to get > the full list. This is often used for server pools (as I'm guessing you know). > It seems to cause problems with Windows clients and/or Windows DNS > servers. Seems like overkill. The 78 addresses listed here are all in one bit of a /24. In the cases I've seen, there are a few servers listed in several different locations, network- (and location-) wise. I agree that this looks really weird. Perhaps they use it as a cheap load balancer? Cheers, Alex Lambert [EMAIL PROTECTED] - Original Message - From: "Stephen Milton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 05, 2003 6:47 PM Subject: Odd DNS responses for www.neopets.com
