Re: [Full-Disclosure] Caching a sniffer

[Ian Latter]

> > While there's no way to be sure-sure ... you can get into your
> > local LAN segment and send ICMP(/whatever) requests to the
> > correct L3 address with the wrong L2 address and see if you
> > get a response; this will show you if hosts/devices are listening
> > promiscuously (which makes for a good starting point).
> 
> Not necessarily?
> 
> I thought that depended on the ip stack implementation.

Not sure what you're driving at .. do you mean you can't use the
same test on all stack implementations or that this test just won't 
work on all stack implementations?

One of the links sent through before had a link to a good read 
on the variations of the theme required for three specific 
implementations. From Tim's message you get this link;
http://seclists.org/lists/focus-ids/2004/Feb/0028.html

In turn, gives you this link;
http://www.securiteam.com/tools/AntiSniff_-
 _find_sniffers_on_your_local_network.html   [wr-wr-wrapped]

There they discuss NetBSD, Linux and Windows detection.

The assumption that I'm skirting around is that the sniffer is on an
existing host (pc/server/etc) .. and as such its not well prepared 
for the task; ie - that it is capable of being actively probed (that
it will respond).

I think the original post / first response included a reference to a 
site being physically accessed ... I guess that's when good 
physical access controls/records/etc become valuable.

As I said, its a good starting point (better than looking at a wiring
closet and your watch, and working out the latest time you can
order pizza).



--
Ian Latter
Internet and Networking Security Officer
Macquarie University

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Comcast using IPS to protect the Internet f rom their home user clients?

[Frank Knobbe]

On Wed, 2004-03-10 at 17:30, Richard Compton wrote:
> They are beta testing the TippingPoint IPS.


Now we're talking. That's a pretty confident statement you made there.
Care to explain how you can be so sure? Are you, or someone you know,
involved in the setup/execution of that beta?

Cheers,
Frank



signature.asc
Description: This is a digitally signed message part

RE: [Full-Disclosure] Comcast using IPS to protect the Internetfrom their home user clients?

[Frank Knobbe]

On Wed, 2004-03-10 at 22:50, Aditya, ALD [Aditya Lalit Deshmukh] wrote:
> i think you and i just said the same things, by traffic thresholds i
> ment total traffic, so it includes all your tunneled ones also, but as
> this is pure speculation and speculation is something that is not good
> so i will let this thread die here 

Oh, okay, I see what you meant. I don't think that's the case since I
had higher traffic volumes (for example, scp'ing a tar backup of a
remote server). Also, whisker scans ran fine. Pretty much same volume,
same hosts.

Regards,
Frank



signature.asc
Description: This is a digitally signed message part

Re: [Full-Disclosure] Caching a sniffer

[Cael Abal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ian Latter wrote:

> While there's no way to be sure-sure ... you can get into your
> local LAN segment and send ICMP(/whatever) requests to the
> correct L3 address with the wrong L2 address and see if you
> get a response; this will show you if hosts/devices are listening
> promiscuously (which makes for a good starting point).

Not necessarily?

I thought that depended on the ip stack implementation.

Cael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFAT/baR2vQ2HfQHfsRAgZ0AJ46xhi8rNDXAt5TIHUZL2Il/Lil1gCfeGsE
GiGW9xeSwCMYgGPl1JvLwNE=
=nLkQ
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Thomas Lakofski]

On Wed, 10 Mar 2004, Exibar wrote:

> Filtering should not be done by the ISPs, they should provide a
> pipe, and that's it.  Ok, there are some circumstances, like a DoS against
> your equipment, where the ISP is the only means of blocking the traffic,
> that's a different story.

Filtering is one thing, and I agree that it's a bad step to take for all
sorts of reasons.  Maybe, though, there are other ways to trap bad
traffic at the ISP level?  I ran LaBrea for a few months on the 3 spare
IPs in my /29, which tended to seize several thousand scanning threads
from all over the place, most of them indefinitely.  Some hosts
afflicted with particularly stupid scanners snarled hundreds of threads
for weeks.  This was at the cost of a staggering 1kB/s upstream
bandwidth.

I wonder if it would be worth it for ISPs to take a /16 or even a
/15s-worth of addresses, and channel all the traffic to a few hefty boxes
running something like LaBrea.  With judicious interleaving of the
tarpitted address space with subscriber pools, most scanners which
operate tiered scanning (local net, then /24, /16, /8 etc.) will fairly
quickly get their threads stuck in the local ISP tarpit.  The tarpit
would also make an ok compromised host detector too...

I'm not sure what the downsides are besides wasted address space, and
some (additional) wasted bandwidth within each ISP (or externally, if
they expose the tarpits).

Any opinions?

cheers,

-- 
Thomas Lakofski
gpg: 1024D/81FD4B43  2B72 53DB 8104 2041 BDB4  F053 4AE5 01DF 81FD 4B43

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Caching a sniffer

[David Vincent]

 
> How can i know if there a sniffer running in my network?

if you're lucky, they are stupid and are using microsoft's network monitor.
Tools --> Identify Network Monitor Users

http://www.comptechdoc.org/os/windows/ntserverguide/ntsnetmon.html

-

http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/
WINDOWS2000/techinfo/reskit/en-us/core/fneg_net_zrgm.asp?frame=true&hidetoc=
true

...

For security reasons, Windows 2000 Network Monitor captures only those
frames, including broadcast and multicast frames, sent to or from the local
computer. Network Monitor also displays overall network segment statistics
for broadcast frames, multicast frames, network utilization, total bytes
received per second, and total frames received per second.

In addition, to help protect your network from unauthorized use of Network
Monitor installations, Network Monitor can detect other installations of
Network Monitor that are running on the local segment of your network.
Network Monitor also detects all instances of the Network Monitor driver
being used remotely (by either Network Monitor from Systems Management
Server or the Network Segment object in System Monitor) to capture data on
your network.

When Network Monitor detects other Network Monitor installations running on
the network, it displays the following information:

* The name of the computer
* The name of the user logged on at the computer
* The state of Network Monitor on the remote computer (running,
capturing, or transmitting)
* The adapter address of the remote computer
* The version number of Network Monitor on the remote computer

In some instances, your network architecture might prevent one installation
of Network Monitor from detecting another. For example, if an installation
is separated from yours by a router that does not forward multicasts, your
installation cannot detect that installation.

...

-

but I digress.  a quick google:

http://www.packet-sniffer.co.uk/content/detect/
- the king!

http://www.gfi.com/news/en/lansniffer.htm
http://www.linux4biz.net/articles/articlesniff.htm

-d

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Worm.Cjdr.A and B questions

[Jarkko Turkulainen]

> Hello all. This is my first post, so be kind. I have been watching our mail
> servers virus logs and have seen at least 100 Worm.Cjdr.A and .B cleaned
> infections. These all appear in a file named p_usb.zip and have never been

Sounds familiar.. Look for "Sears Scam Trojan" in the Full-Disclosure
archives or google.


Regards,

--
Jarkko Turkulainen <[EMAIL PROTECTED]>

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Caching a sniffer

[Ian Latter]

While there's no way to be sure-sure ... you can get into your
local LAN segment and send ICMP(/whatever) requests to the
correct L3 address with the wrong L2 address and see if you
get a response; this will show you if hosts/devices are listening 
promiscuously (which makes for a good starting point).




- Original Message -
>From: "Gary E. Miller" <[EMAIL PROTECTED]>
>To: "Patricio Bruna V." <[EMAIL PROTECTED]>
>Subject:  Re: [Full-Disclosure] Caching a sniffer
>Date: Wed, 10 Mar 2004 18:51:07 -0800
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Yo Patricio!
> 
> On Wed, 10 Mar 2004, Patricio Bruna V. wrote:
> 
> > How can i know if there a sniffer running in my network?
> 
> If the hacker has had physical access to your network, even for just a
> few minutes, then there are many ways he can install a sniffer you can
> never find short of tearing everything apart.
> 
> If you care about your data, you better encrypt end to end.
> 
> RGDS
> GARY
> - ---
> Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
>   [EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD8DBQFAT9Qe8KZibdeR3qURAhDPAKCuNz7q8joqyij/T1AHy0DHBF00HgCfTl0i
> W5eaIQIRi3Zx+B87I3nZKZ0=
> =p/BH
> -END PGP SIGNATURE-
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: FW: [Full-Disclosure] Meth and hacking?

[madsaxon]

At 05:03 PM 3/10/2004 -0700, Vince wrote:

I believe Bob has reached  his highest level of
incompetence.  MSNBC will most likely promote him.
Yeah, maybe he and Verton can coauthor the Ultimate Guide
to Bullshit.
;-)

m5x

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Caching a sniffer

[Tim]

> How can i know if there a sniffer running in my network?


There was a long thread on this subject in February on focus-ids:
  http://seclists.org/lists/focus-ids/2004/Feb/0028.html

One link to an interesting paper posted there:
  http://www.securityfriday.com/promiscuous_detection_01.pdf

There may be other ways, but the approach described in the paper would
probably work in most cases provided the interface in question was
configured with an IP.  Then again, I may not know what the hell I am
talking about...

tim

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Harry Hoffman]

I'm sorry but I think that's a bunch of crap.

Enforcing the AUP towards the outside world is not enforcing the AUP. Comcast
has before and still does take the stand that they do not protect their End
Users. AUP's are used to protect the business from lawsuits by placing blame on
the customer (whether or not it was the customer's direct fault).
Otherwise the AUP would read "We will protect your from the other users on our
network by providing X, Y, and Z" instead of "If we find you doing certain
things that a) we aren't profiting on or b) are causing us to spend more on
infrastructure then you can expect us to go medieval on your ass!"

How can it be Comcast (or any other ISP) use an AUP to stifle communications to
the outside world yet still allow attacks within it's network from one customer
to another?

And it is indeed censorship! While the justification may be the safety of the
"net" in general aren't we currently dealing with that in our own country with
the Patriot Bill! It's an oft used method to scare everyone into submission.

Private company or not when a service becomes common-place it transcends what
the private company may or may not do. Consider things like the tel-co's,
privatized garbage collection or privatized public transit. Lots of times the
only difference is regulation/small subsidies from the govt. (which by the way
is the people!).

Don't forget that without the customer their wires aren't worth anything. The
unfortunate position is that the customers are tied into a service because of a
certain needs.

Quoting "Randal L. Schwartz" <[EMAIL PROTECTED]>:

*> But they also have the right/responsibility to enforce an AUP, and to
*> play "good net neighbor".
*> 
*> In this case, they are disconnecting users who are violating AUPs
*> or causing them to collectively no longer play "good net neighbor".
*> 
*> It's not censorship.  It's especially not "censorship" when it's a
*> private company (you can always take your business elsewhere).
*> 
*> "Freedom of the press" doesn't mean you get to use everyone's press
*> for free, or that everyone gets a free press.  Comcast is entirely
*> within their right to cut people off as clients or from the net or
*> both.  It's their wires.
*> 
*> --
*> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
*> <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
*> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
*> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
*> training!
*> 
*> ___
*> Full-Disclosure - We believe in it.
*> Charter: http://lists.netsys.com/full-disclosure-charter.html
*> 


-- 
Harry Hoffman
[EMAIL PROTECTED]
--
radical:
1) Someone waiting in line to become "The Establishment"

-
This mail sent through IpSolutions: http://www.ip-solutions.net/

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Caching a sniffer

[Chris Adams]

On Mar 10, 2004, at 13:13, Patricio Bruna V. wrote:
How can i know if there a sniffer running in my network?
You might catch someone sloppy with tricks like DNS resolution (send 
data with a hostname / IP and see who resolves it) or bugs in the way 
the sniffing host handles things like ARP resolution (search for 
antisniff if you want a tool which does this) - other than that, 
there's really no way to find a sniffer. Your best bet is to use strong 
encryption so it no longer matters if someone is sniffing traffic.

Chris


smime.p7s
Description: S/MIME cryptographic signature

RE: [Full-Disclosure] Comcast using IPS to protect the Internet f rom their home user clients?

[Richard Compton]

They are beta testing the TippingPoint IPS.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Frank Knobbe
Sent: Wednesday, March 10, 2004 12:53 PM
To: Chmielarski TOM-ATC090
Cc: [EMAIL PROTECTED]
Subject: RE: [Full-Disclosure] Comcast using IPS to protect the Internet
f rom their home user clients?
 
On Wed, 2004-03-10 at 07:46, Chmielarski TOM-ATC090 wrote:
> Yes, they say they are now doing this.
> http://www.infoworld.com/article/04/03/09/HNcomcastspam_1.html
But this article says they are shutting systems down once identified as
a spam/hack/dos zombie. This can be done easily by reconfiguring the
Cable modem or removing MAC addresses from filter/pass tables (don't
know what types of access controls are in place over there).
It doesn't say they are using an inline IDS/IPS. Where would those IPS's
be? At the major NAPs or peering points? Or distributed in regional
hubs? I'm curious how they are dealing with the performance impact.
Perhaps they are using ASIC based IPS's, or very limited signature sets
(which would explain why a whisker scan completes unimpeded, but a nikto
scans hangs at the same "spot").
So far, a couple others reported that they noticed the same behavior. I
haven't heard anyone say "my scans are not affected". To reproduce the
test, fire off a nikto scan against a remote web server (remember, get
permission first). See if nikto completes without getting stuck. (I used
a recent nikto from the FBSD ports tree).
Anyhow, finding spam sources and bandwidth hogs and turning them off
manually is one thing. Having an network-based intrusion prevention
system sitting in their wires is another. Perhaps they are beta testing
that as an additional method to weed out bad traffic?
Regards,
Frank
 
PS: I'm completely okay with them filtering as long as they allow me to
tunnel my traffic to corporate servers. Whatever it takes to get rid of
spam is fine with me... 
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster.

[Full-Disclosure] Possible Netsky.k Netsky.L attack on March 11, 2004 ..

[dotsecure]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Does anyone know if this is true. Apparently the war is between mydoom,
  creators vs netsky. According to inforworld magazine and few other
credible sources this variant of netsky is due to strike on March 11th.


Does anyone know any additional details or cited sources that have any
additional details regarding this possible attack. What are the chances
that its a hoax?

Here are the sources:

http://www.pandasoftware.com/about/press/viewNews.aspx?noticia=4852

http://informationweek.securitypipeline.com/news/18311790


Any additional details, netsky.k encounters, or suggestions would greatly
be appreciated.


Thanks

Martin M

Dotsecure
-BEGIN PGP SIGNATURE-
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.3

wkYEARECAAYFAkBPr2UACgkQHxPzbxnt5HTy8QCgv9P+ls/HWt8T8rI1bG5/Mz6xtd4A
n2uHSzzFB8IEP/NwQ3MHVaZlQBxi
=DpA4
-END PGP SIGNATURE-




Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Caching a sniffer

[Dave Horsfall]

On Wed, 10 Mar 2004, Patricio Bruna V. wrote:

> How can i know if there a sniffer running in my network?

When you wake up one day to find that you're 0wn3d :-)

Seriously, about the only way I can think of to detect a sniffer with
its transmit leads cut is with a Time Domain Reflectometer (TDR) and
look for an unexplained impedance bump.

-- 
Dave Horsfall  DTM  VK2KFU Loyal Unix user since 1975
Booted from Spamtools for dissing the moderator: www.horsfall.org/levine.mail

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Caching a sniffer

[Gary E. Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yo Patricio!

On Wed, 10 Mar 2004, Patricio Bruna V. wrote:

> How can i know if there a sniffer running in my network?

If the hacker has had physical access to your network, even for just a
few minutes, then there are many ways he can install a sniffer you can
never find short of tearing everything apart.

If you care about your data, you better encrypt end to end.

RGDS
GARY
- ---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAT9Qe8KZibdeR3qURAhDPAKCuNz7q8joqyij/T1AHy0DHBF00HgCfTl0i
W5eaIQIRi3Zx+B87I3nZKZ0=
=p/BH
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

FW: [Full-Disclosure] Meth and hacking?

[Vince]

>"The drugs and the crime fit neatly together; addicts strung 
out on meth
>can stay awake and focused for days at a time, making them 
expert
>hackers and mailbox thieves. And ID theft is easy money, the 
perfect
>income for drug addicts who have no other way to fund their 
habit."


-clip from msn site---
"Bob Sullivan is senior writer for MSNBC.com's Technology 
section, specializing in computer crime, electronic financial 
fraud, privacy, and the Internet Underground. His 
investigative reports have forced hundreds of companies to 
come clean about the theft of customer data by hackers, and 
he has regularly been the first to warn of potential identity 
theft. Bob was also the first to tell Americans that the FBI 
had developed a computer program, called Magic Lantern, 
designed to steal public encryption keys. Bobâs work has been 
read by millions and he has appeared on MSNBC TV, CNBC, NBC 
Nightly News, the Today Show, TechTV, and a variety of local 
NBC affiliates."
---

Bob is also the first to stick his foot in his mouth in front 
of the hacker community...and other savvy computer security 
professionals.

I believe Bob has reached  his highest level of 
incompetence.  MSNBC will most likely promote him.

Vince

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Worm.Cjdr.A and B questions

[Brandon]

Hello all. This is my first post, so be kind. I have been watching our mail 
servers virus logs and have seen at least 100 Worm.Cjdr.A and .B cleaned 
infections. These all appear in a file named p_usb.zip and have never been 
seen on our mail server up until today. I have searched the major antivirus 
vendors for information as to what kind of actions and other evil deeds the 
worm carries out, only to find nothing. I have also searched the standards 
like google and some of the hacker sites and chat rooms, but nothing. Any 
information would be appreciated.

<<<==>>>
Brandon Glaze
F.N.S.B.S.D.
Senior Network Technician
[EMAIL PROTECTED]
(907) 452-2000 ext.291
"I am the Master of my fate,
 I am the Captain of my soul..."
 --Invictus--
<<<==>>>
This message (and any associated files) is intended only for the use of the 
individual or entity to which it is addressed and may contain information that 
is confidential, subject to copyright or constitutes a trade secret. If you 
are not the intended recipient you are hereby notified that any dissemination, 
copying or distribution of this message, or files associated with this 
message, is strictly prohibited. If you have received this message in error, 
please notify us immediately by replying to the message and deleting it from 
your computer. Messages sent to and from 
Brandon Glaze (FNSBSD) may be monitored. 

Internet communications cannot be guaranteed to be secure or error-free as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. Therefore, we do not accept responsibility for 
any errors or omissions that are present in this 
message, or any attachment, that have arisen as a result of e-mail 
transmission. If verification is required, please request a hard-copy version.

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] MDKSA-2004:021 - Updated mozilla packages fix multiple vulnerabilities

[Vincent Danen]

On Mar 10, 2004, at 12:20, Florian Weimer wrote:

 A number of vulnerabilities were discovered in Mozilla 1.4:
Wow.  A GNU/Linux distributor who finally releases a security update  
for
Mozilla.  Isn't this a first?
Actually, no... it's a second (for Mandrake anyways).

http://www.mandrakesecure.net/en/advisories/advisory.php?name=MDKSA 
-2002:074

---
Mandrakesoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7  66F9 2043 D0E5 FE6F 2AFD}


PGP.sig
Description: This is a digitally signed message part

[Full-Disclosure] [SECURITY] [DSA 460-1] New sysstat packages fix insecure temporary file creation

[debian-security-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 460-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Matt Zimmerman
March 10th, 2004http://www.debian.org/security/faq
- --

Package: sysstat
Vulnerability  : insecure temporary file
Problem-Type   : local
Debian-specific: no
CVE Ids: CAN-2004-0108

Alan Cox discovered that the isag utility (which graphically displays
data collected by the sysstat tools), creates a temporary file without
taking proper precautions.  This vulnerability could allow a local
attacker to overwrite files with the privileges of the user invoking
isag.

For the current stable distribution (woody) this problem has been
fixed in version 5.0.1-1.

For the unstable distribution (sid) this problem will be fixed soon.

We recommend that you update your sysstat package.

Upgrade Instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.

Debian GNU/Linux 3.0 alias woody
- 

  Source archives:

http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1.dsc
  Size/MD5 checksum:  646 a5040b1b689670af75bc8135ebec50da

http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1.diff.gz
  Size/MD5 checksum: 8645 2edda9778b575cf59a32888a65bc3789
http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4.orig.tar.gz
  Size/MD5 checksum:99410 9bab6bb01949ba36ce0e5520699ebdf2

  Architecture independent components:

http://security.debian.org/pool/updates/main/s/sysstat/isag_4.0.4-1woody1_all.deb
  Size/MD5 checksum:15920 84586d337482345b6333ed3cca81ff76

  Alpha architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_alpha.deb
  Size/MD5 checksum:   101682 4cee5c4be51673e9c1a92c97ac6ee269

  ARM architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_arm.deb
  Size/MD5 checksum:86300 1f1df8a9de4107fab4380c740bbf6229

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_i386.deb
  Size/MD5 checksum:78078 e167208600a95a414438d9b2ec97070a

  Intel IA-64 architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_ia64.deb
  Size/MD5 checksum:   115154 323b9724eb6b58c471806662f807d3a8

  HP Precision architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_hppa.deb
  Size/MD5 checksum:95428 23ea1584bcb00d78a83193b43e0135b5

  Motorola 680x0 architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_m68k.deb
  Size/MD5 checksum:74858 973dbfb3593919902b8364ffdc780be9

  Big endian MIPS architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_mips.deb
  Size/MD5 checksum:87796 496f1c560fd3bb907e9e84d90cc5a28f

  Little endian MIPS architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_mipsel.deb
  Size/MD5 checksum:87592 490cdbe90de212f602d161feafa03cde

  PowerPC architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_powerpc.deb
  Size/MD5 checksum:86926 1d031e26e5a8a91ee887967995692864

  IBM S/390 architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_s390.deb
  Size/MD5 checksum:83068 571f11004a9865497cdb454084cdce40

  Sun Sparc architecture:


http://security.debian.org/pool/updates/main/s/sysstat/sysstat_4.0.4-1woody1_sparc.deb
  Size/MD5 checksum:99288 a390e93d83008691833956ad7c41dc87

  These files will probably be moved into the stable distribution on
  its next revision.

- -
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main
Mailing list: [EMAIL PROTECTED]
Package info: `apt-cache show ' and http://packages.debian.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAT4LaArxCt0PiXR4RAv6mAJ4iXfAnhQBXmNBHRX9cgIpI4ZTeAACgnICL
iJVg0Oq00wWhAoip4sNj4MI=
=K7BT
-END PGP SIGNATURE-

___
Full-Di

Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Steve Menard]

Frank Knobbe wrote:

Spam filtering and virus checking should occur on the carriers email
gateways/hosts, and not on the wire itself. I should have the right to
receive all the viruses I want in my email (perhaps for legitimate
research). As far as filtering inline, if it occurs on fixed critera
(i.e. port 25), I'm okay with it (even though I may not like it. As I
said, as long as I can tunnel around it, I'm fine :)  

But if filtering occurs inline on undefined critera, then it may be of
concern. That is the reason that I posted the question if anyone else
had noticed that "some" filtering on "some" content is occurring.
Cheers,
Frank
 

Sure enough that's what happens in Aliant Bell-Sympatico land here in 
Eastern Canada
Of course they won't tell the end-user it would squash their demand for 
Phone/Net Bill upcharges with monthly anti-virus add-on charges $4.99/month

And of course there's no indication that' it's turned on except when 
some knowledgeable user expects to receive such malware through 
'regular'  channels and it fails to materialize.

So Any body want to preove me wrong and send me malware ;-)

cc it to my account [non [baby-canadian-Bell] supervised]
realmalware at www dot dranem dot org 
So I know what was supposed to be sent   ;-)

smenard

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] [SECURITY] [DSA 459-1] New kdelibs, kdelibs-crypto packages fix cookie traversal bug

[debian-security-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 459-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Matt Zimmerman
March 10th, 2004http://www.debian.org/security/faq
- --

Package: kdelibs, kdelibs-crypto
Vulnerability  : cookie path traversal
Problem-Type   : remote
Debian-specific: no
CVE Ids: CAN-2003-0592

A vulnerability was discovered in KDE where the path restrictions on
cookies could be bypassed using encoded relative path components
(e.g., "/../").  This means that a cookie which should only be sent by
the browser to an application running at /app1, the browser could
inadvertently include it with a request sent to /app2 on the same
server.

For the current stable distribution (woody) this problem has been
fixed in kdelibs version 4:2.2.2-6woody3 and kdelibs-crypto version
4:2.2.2-13.woody.9.

For the unstable distribution (sid) this problem was fixed in kdelibs
version 4:3.1.3-1.

We recommend that you update your kdelibs and kdelibs-crypto packages.

Upgrade Instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.

Debian GNU/Linux 3.0 alias woody
- 

  Source archives:

http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs_2.2.2-13.woody.9.dsc
  Size/MD5 checksum: 1353 259d1c3337e6421f5ecedfe15a5209f0

http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs_2.2.2-13.woody.9.diff.gz
  Size/MD5 checksum:57742 fbdb18745fadbd7d8a90afa9aa3767c5
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs_2.2.2.orig.tar.gz
  Size/MD5 checksum:  6396699 7a9277a2e727821338f751855c2ce5d3

http://security.debian.org/pool/updates/main/k/kdelibs-crypto/kdelibs-crypto_2.2.2-6woody3.dsc
  Size/MD5 checksum:  717 ed37d69135a183a7fff7771cbed7334c

http://security.debian.org/pool/updates/main/k/kdelibs-crypto/kdelibs-crypto_2.2.2-6woody3.diff.gz
  Size/MD5 checksum:27998 31b6014b42c63879a1d20277ae255d67

http://security.debian.org/pool/updates/main/k/kdelibs-crypto/kdelibs-crypto_2.2.2.orig.tar.gz
  Size/MD5 checksum:   643622 5ef84fed86c7984f99f8e44e9d5a216a

  Architecture independent components:


http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs3-doc_2.2.2-13.woody.9_all.deb
  Size/MD5 checksum:  2564192 513f8bdfe75d951190f9dacbee767bd8

  Alpha architecture:


http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs-dev_2.2.2-13.woody.9_alpha.deb
  Size/MD5 checksum:   757356 f0217378d9ce13a22652de6e10dfc803

http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs3_2.2.2-13.woody.9_alpha.deb
  Size/MD5 checksum:  7553310 5ed5612401a9e8221f74a2c728d84b10

http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs3-bin_2.2.2-13.woody.9_alpha.deb
  Size/MD5 checksum:   137334 a5681e4f36f3ce5afac8a7cc83051d3b

http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs3-cups_2.2.2-13.woody.9_alpha.deb
  Size/MD5 checksum:   201912 52fd860524415d33ac3a7fcb55372075

http://security.debian.org/pool/updates/main/k/kdelibs/libarts_2.2.2-13.woody.9_alpha.deb
  Size/MD5 checksum:  1022278 c5af6f967923ba2b42101f51ba761789

http://security.debian.org/pool/updates/main/k/kdelibs/libarts-alsa_2.2.2-13.woody.9_alpha.deb
  Size/MD5 checksum:  1029252 487937ab90a6f4901d5ccb3ce797a791

http://security.debian.org/pool/updates/main/k/kdelibs/libarts-dev_2.2.2-13.woody.9_alpha.deb
  Size/MD5 checksum:   198146 fb0b344662b1f3670f368d176932eee9

http://security.debian.org/pool/updates/main/k/kdelibs/libkmid_2.2.2-13.woody.9_alpha.deb
  Size/MD5 checksum:   174606 1fb8e8f2b97cf368e3212f06cccbcf5c

http://security.debian.org/pool/updates/main/k/kdelibs/libkmid-alsa_2.2.2-13.woody.9_alpha.deb
  Size/MD5 checksum:   178042 ca6839e78ada20e5ec5aedeea2941ed2

http://security.debian.org/pool/updates/main/k/kdelibs/libkmid-dev_2.2.2-13.woody.9_alpha.deb
  Size/MD5 checksum:37178 954880c404f917b0c4d52fab495a2d2a

http://security.debian.org/pool/updates/main/k/kdelibs-crypto/kdelibs3-crypto_2.2.2-6woody3_alpha.deb
  Size/MD5 checksum:   132308 c45ff6ad0e59ffbde75f60e881bb7f33

  ARM architecture:


http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs-dev_2.2.2-13.woody.9_arm.deb
  Size/MD5 checksum:   743636 582822a51e0791c14bb61a88

[Full-Disclosure] Caching a sniffer

[Patricio Bruna V.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

How can i know if there a sniffer running in my network?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAT4UNT29IM+6ptNcRAoKlAJ9Kbk2yH4MKrQRNaz6OVM2Jai8/+QCgoUnx
IXCJDuMJxTU9r/E5AhjW1fc=
=LiUx
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Has anyone seen this in their e-mail

[Nick FitzGerald]

"Aditya, ALD [Aditya Lalit Deshmukh]" wrote:

> how difficult would it be to use random and differnet passwords for each
> infection, ...

Or even "random and different" passwords for each message it sends?

Have you read _anything_ about the recent Bagle variants flooding the 
net at the moment?  If not, please go and do so _before_ speculating 
further about stuff that is already well-known...

> ... pretty easy for a smart programmer or the clever virus
> writer,

Pretty easy even for a dumb virus writer too...

> maybe they are using the passwords to keep track of the version of the
> viruses 

Or maybe they aren't...


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Comcast using IPS to protect the Internetfrom their home user clients?

[Matthew C. Beckman]

> But, if those terms aren't acceptable, then why sign up for the
> service in the first place?

I think the objection is simply that Comcast won't define the terms.
As someone else mentioned, there are a lot of reports of Comcast
cutting off service to someone with the reason being, that they
over-used the service.  If they are advertising unlimited internet
service first off, and then won't define what 'too much' bandwidth
usage is, that is where the problem comes in.  Even those people that
have been cut off have been unable to find out where that line is
drawn.

If they would be more clear in their policies, I don't think anyone
would have room to complain.

- Matthew C. Beckman

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Luke Scharf]

On Wed, 2004-03-10 at 16:58, Randal L. Schwartz wrote:
> "Freedom of the press" doesn't mean you get to use everyone's press
> for free, or that everyone gets a free press.  Comcast is entirely
> within their right to cut people off as clients or from the net or
> both.  It's their wires.

And the customer has the right to not give the ISP their hard earned
money!

Although the waters are somewhat if ComCast is like the average cell
phone company and asks that you agree to give them a certain amount of
money in order to get the service...  But, if those terms aren't
acceptable, then why sign up for the service in the first place?

Anyway, back to work for me.

-Luke

-- 
Luke Scharf, Systems Administrator
Virginia Tech Aerospace and Ocean Engineering

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: Browser security was Re: [Full-Disclosure] MDKSA-2004:021 - Updated mozilla packages fix multiple vulnerabilities

[Florian Weimer]

Gary Flynn wrote:

> >Wow.  A GNU/Linux distributor who finally releases a security update for
> >Mozilla.  Isn't this a first?
> >
> >There is a list of published issues at:
> 
> I'm glad you said "published" instead of "known". :)

That was quite deliberate. 8-)

There are quite a few security bugs which have been classified in
accordance with the Mozilla Security Policy:



Note that the list you've seen doesn't include bugs which were fixed in
1.6 (Sandblad #13, but the 1.6 release notes suggest that there are more).

> What I'd like to see personally is a right-click "temporarily
> disable/enable risky functionality for this site" option

There's a Mozilla plugin for a toolbar which offers exactly this
functionality (switch on/off Java, JavaScript, Proxy, Images by a single
mouse click).

However, I stopped using it when the nastiest aspect of JavaScript
(pop-up ads) suddenly became a non-issue. 8->

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, freenet.de, hotmail.com,
libero.it, netscape.net, postino.it, tiscali.co.uk, tiscali.cz,
tiscali.it, voila.fr, wanadoo.fr, yahoo.com.

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Meth and hacking?

[sd-kan]

Come on now think back a few years, dont you remember Erik when he got arrested and 
his tag that was everywhere.

"Zyklon was here / Zyklon luvs crystal"

Crystal was just some girl in his math class, the media ripped into that one so hard
accusing him of being a meth head thinking he was refering to crystal meth.


 Original Message 
To: <[EMAIL PROTECTED]>
From: "Steven Alexander" <[EMAIL PROTECTED]>
Date: Wed, 10 Mar 2004 09:44:28 -0800
Subject: [Full-Disclosure] Meth and hacking?

http://www.msnbc.msn.com/id/4460349/

"The drugs and the crime fit neatly together; addicts strung out on meth
can stay awake and focused for days at a time, making them expert
hackers and mailbox thieves. And ID theft is easy money, the perfect
income for drug addicts who have no other way to fund their habit."

Expert hackers?  WTF? 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Exibar]

As long as ComCast specifically states what they are filtering beforehand,
when and why they cut the user off after the fact, then I wouldn't have a
problem, that way the user could make an informed judgment call as to
whether or not to keep them as a provider.

   ComCast isn't known to communicate very well.  I've heard of cases where
they cut people off for downloading too much, without telling them how much
is too much, etc etc.

  Perhaps censorship was too strong of a word.  If they advertise "unlimited
internet access for $49.95" then then better damn well provide "unlimited
internet access" and any restrictions plainly and distinctly posted so the
consumer can make an educated choice.

  Ex

- Original Message - 
From: "Randal L. Schwartz" <[EMAIL PROTECTED]>
To: "Exibar" <[EMAIL PROTECTED]>
Cc: "Frank Knobbe" <[EMAIL PROTECTED]>; "Chmielarski TOM-ATC090"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 10, 2004 4:58 PM
Subject: Re: [Full-Disclosure] Comcast using IPS to protect the Internet
from their home user clients?


> > "Exibar" == Exibar  <[EMAIL PROTECTED]> writes:
>
> Exibar> I know the "feeling" behind what you typed, but you really
> Exibar> don't mean what you typed.  Filtering should not be done by
> Exibar> the ISPs, they should provide a pipe, and that's it.
>
> But they also have the right/responsibility to enforce an AUP, and to
> play "good net neighbor".
>
> In this case, they are disconnecting users who are violating AUPs
> or causing them to collectively no longer play "good net neighbor".
>
> It's not censorship.  It's especially not "censorship" when it's a
> private company (you can always take your business elsewhere).
>
> "Freedom of the press" doesn't mean you get to use everyone's press
> for free, or that everyone gets a free press.  Comcast is entirely
> within their right to cut people off as clients or from the net or
> both.  It's their wires.
>
> -- 
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
> <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
training!
>
>

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Randal L. Schwartz]

> "Exibar" == Exibar  <[EMAIL PROTECTED]> writes:

Exibar> I know the "feeling" behind what you typed, but you really
Exibar> don't mean what you typed.  Filtering should not be done by
Exibar> the ISPs, they should provide a pipe, and that's it.

But they also have the right/responsibility to enforce an AUP, and to
play "good net neighbor".

In this case, they are disconnecting users who are violating AUPs
or causing them to collectively no longer play "good net neighbor".

It's not censorship.  It's especially not "censorship" when it's a
private company (you can always take your business elsewhere).

"Freedom of the press" doesn't mean you get to use everyone's press
for free, or that everyone gets a free press.  Comcast is entirely
within their right to cut people off as clients or from the net or
both.  It's their wires.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Meth and hacking?

[r C]

Huh? The only drugs i've ever used when i need to stay
awake for a project are in abundance in my fridge...
Jolt and Mountain Dew. Jolt bieng the best for late
nights. The media sickens me.


__
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Meth and hacking?

[madsaxon]

At 03:12 PM 3/10/2004 -0500, Scott Phelps wrote:

I coded an OS in assembly in 24 hours one time on Crystal Meth.

When I sobered up the next day I looked back at the code and realized it was
just the words "push" and "pop" over and over again in a 36 Meg text file.
The p button quit working on my keyboard the next day.
Oh, so *that's* where MSDOS came from...

;-)

m5x

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Meth and hacking?

[Ron DuFresne]

This whole thread is about as funny as the pentesters thread:

Papers on Sex as an audit tool?

Of course, in that thread the first paper cited would have to be titled;

tit for tat

Thanks,

Ron DuFresne
~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Frank Knobbe]

On Wed, 2004-03-10 at 14:44, Exibar wrote:
> I know the "feeling" behind what you typed, but you really don't mean
> what
> you typed.  Filtering should not be done by the ISPs, they should
> provide a
> pipe, and that's it. [...]  If the ISP's start filtering traffic,
> scanning E-mail for viruses, etc,
> they are getting close to censorship in my eyes.  They're also
> removing
> themselves from "common carrier" status in the eyes of the law too I
> would
> think.

Heya Exibar,

I tend to think of a "common carrier" as a T-1 provider, and perhaps
most DSL providers. By end-user ISP like MSN, AOL, or cable services
seem to be better described as consumer carriers. The main
differentiators being the ease of use (just plug it in and get an IP via
DHCP) and of course the level of "clue" of the technical "staff".

That said, I would support certain filtering (like blocking inbound or
outbound SMTP connections) as long as it is done indiscriminately. By
that I mean it is okay to filter port 25 across the board, but it should
not be okay to filter on some content that the carrier deems is
inappropriate (as that definition most likely varies between carrier and
consumer). If certain criteria is applied, I would agree, I would be
similar to censorship. After all, I should have the right to receive my
Viagra ads and Nigerian investment opportunities. :)

Spam filtering and virus checking should occur on the carriers email
gateways/hosts, and not on the wire itself. I should have the right to
receive all the viruses I want in my email (perhaps for legitimate
research). As far as filtering inline, if it occurs on fixed critera
(i.e. port 25), I'm okay with it (even though I may not like it. As I
said, as long as I can tunnel around it, I'm fine :)  

But if filtering occurs inline on undefined critera, then it may be of
concern. That is the reason that I posted the question if anyone else
had noticed that "some" filtering on "some" content is occurring.

Cheers,
Frank


PS: The Infoworld article Tom mentioned seems to deal more with detect
and manual punishment. I'm okay with that as well. As long as they don't
use automated tools to turn peoples modems off when the IDS triggers on
a possible false alert.




signature.asc
Description: This is a digitally signed message part

Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Exibar]

I know the "feeling" behind what you typed, but you really don't mean what
you typed.  Filtering should not be done by the ISPs, they should provide a
pipe, and that's it.  Ok, there are some circumstances, like a DoS against
your equipment, where the ISP is the only means of blocking the traffic,
that's a different story.
   If the ISP's start filtering traffic, scanning E-mail for viruses, etc,
they are getting close to censorship in my eyes.  They're also removing
themselves from "common carrier" status in the eyes of the law too I would
think.  Make those services OPTIONAL for those that want it, great, I'm all
for it.  But if I want a link out to the internet, that isn't filtered or
anything I should be able to get it.

Ex

- Original Message - 
From: "Frank Knobbe" <[EMAIL PROTECTED]>
To: "Chmielarski TOM-ATC090" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, March 10, 2004 1:52 PM
Subject: RE: [Full-Disclosure] Comcast using IPS to protect the Internet
from their home user clients?

PS: I'm completely okay with them filtering as long as they allow me to
tunnel my traffic to corporate servers. Whatever it takes to get rid of
spam is fine with me...

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Browser security was Re: [Full-Disclosure] MDKSA-2004:021 - Updated mozilla packages fix multiple vulnerabilities

[Gary Flynn]

Florian Weimer wrote:

Mandrake Linux Security Team wrote:


A number of vulnerabilities were discovered in Mozilla 1.4:


Wow.  A GNU/Linux distributor who finally releases a security update for
Mozilla.  Isn't this a first?
There is a list of published issues at:
I'm glad you said "published" instead of "known". :)



Now compare this to what some distributions are shipping (most of them
are at 1.4, AFAIK).
Apparently, browser (and mail client) security isn't something at which
you can beat the market leader easily, despite its sorry performance in
this regard.  8-/
Amen.

Looking at the workarounds on the "known vulnerability" page, it
appears the old saw about "disable javascript, java, etc." should
apply to all browsers visiting untrusted sites.
What I'd like to see personally is a right-click "temporarily
disable/enable risky functionality for this site" option so this
functionality can be turned on and off easily for those users
willing to put up with the discomfort of day to day web "browsing"
without scripts but not willing to put up with having to go
through three or more configuration screens for a temporary site
visit. Yeah, I know, make it too easy and you get the email attachment
syndrome but I think the feature would overall encourage more people
to try browing in a safer default configuration than today's
mechanism. You fight human nature and you lose. It could always be
disabled by a master switch in an organizational policy. Shoot,
even security vendors make use of script on their web pages
and I think most of us would have to admit having to go to a site
requiring script and forgetting to turn it back off at least
once. :)
--
Gary Flynn
Security Engineer - Technical Services
James Madison University
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Meth and hacking?

[cdowns]

I wouldnt just rely on this, because if we could hurry up and colonize 
mars you could:

A: do meth
b: Hack 687 days a year now just think of that..
Downside is that you still only get 2 weeks off a year, sorry guys...

;)

~!>D

MacDougall, Shane wrote:

Hmmm...I'm gonna run this by my boss and see if I can get a purchase
request for some meth...to increase productivity...
 

"The drugs and the crime fit neatly together; addicts strung out on
   

meth
 

can stay awake and focused for days at a time, making them expert
hackers 
   

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Meth and hacking?

[madsaxon]

At 11:51 AM 3/10/2004 -0800, Geoff Shively wrote:

Did they get meth confused with caffine?
To each his stimulant, I suppose.

m5x

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Meth and hacking?

[Scott Phelps]

I coded an OS in assembly in 24 hours one time on Crystal Meth.

When I sobered up the next day I looked back at the code and realized it was
just the words "push" and "pop" over and over again in a 36 Meg text file.
The p button quit working on my keyboard the next day.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris DeVoney
Sent: Wednesday, March 10, 2004 1:50 PM
To: [EMAIL PROTECTED]
Subject: RE: [Full-Disclosure] Meth and hacking?

On Wednesday, March 10, 2004 9:44 AM, Steven Alexander wrote:

> http://www.msnbc.msn.com/id/4460349/
> 
> "The drugs and the crime fit neatly together; addicts strung 
> out on meth can stay awake and focused for days at a time, 
> making them expert hackers and mailbox thieves. And ID theft 
> is easy money, the perfect income for drug addicts who have 
> no other way to fund their habit."
> 
> Expert hackers?  WTF? 

Depends on how you define "expert" but I could accept Bob Sullivan's
defintion (although his idiot editor at MSNBC could have changed the
wording). 

According to the article, the theft doesn't start with an online activity;
it starts by stealing US Mail. The information is then successfully
exploited online. No, the person isn't an expert hacker, per sa; they become
expert at exploiting identify theft, just a fancy name for a thief.

But concentration and long, continuous effort working at a craft can improve
anyone's skills.
 
cdv

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Regarding Adobe Acrobat Reader advisory (#NISR03022004)

[NGSSoftware Insight Security Research]

Hello all,

I've been inundated with e-mails asking whether operating systems other than
Windows are affected by XFDF overflow. Whilst I did not state that Windows
is the only OS affected, and I should have done, I thought it was clear,
incorrectly, that Adobe Acrobat Reader for Windows was indeed the only one
and not Mac, *nix, etc.

>From the original advisory:

When the xfdf file is parsed an unsafe call to sprintf is made in
preparation for outputting a debug message using OutputDebugString.

OutputDebugString is a Win32 API function, exported by kernel32.dll.
Conseqently, the vulnerable code path will exist only in the Windows
version of Adobe Acrobat Reader.

I hope this clears up any confusion.

Cheers,
David Litchfield
NGSSoftware/NGSConsulting
http://www.nextgenss.com/
+44(0)208 401 0070







___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Meth and hacking?

[Geoff Shively]

Did they get meth confused with caffine?


Cheers,


Geoff Shively
CTO
PivX Solutions
24 Corporate Plaza #180
Newport Beach, CA 92660
http://www.pivx.com
[EMAIL PROTECTED]
desk   -  949.720.4628
mobile - 949.903.8856

PivX defines "Proactive Threat Mitigation". Get a FREE Beta Version of
Qwik-Fix (tm)





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 10, 2004 10:43 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [Full-Disclosure] Meth and hacking?

Makes allot of sense, since most Tweakers are 1. smart individuals in
the first place.. 2. Are known to have quite the collection of high tech
hardware..yeah right most hard core meth users I have seen can't afford
a computer much less try some huge scheme to steal identities

-Original Message-
From: Steven Alexander [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 10, 2004 9:44 AM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] Meth and hacking?


http://www.msnbc.msn.com/id/4460349/

"The drugs and the crime fit neatly together; addicts strung out on meth
can stay awake and focused for days at a time, making them expert
hackers and mailbox thieves. And ID theft is easy money, the perfect
income for drug addicts who have no other way to fund their habit."

Expert hackers?  WTF? 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Meth and hacking?

[MacDougall, Shane]

Hmmm...I'm gonna run this by my boss and see if I can get a purchase
request for some meth...to increase productivity...


>"The drugs and the crime fit neatly together; addicts strung out on
meth
>can stay awake and focused for days at a time, making them expert
>hackers 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Meth and hacking?

[Scott Manley]

Steven Alexander wrote:
http://www.msnbc.msn.com/id/4460349/

"The drugs and the crime fit neatly together; addicts strung out on meth
can stay awake and focused for days at a time, making them expert
hackers and mailbox thieves. And ID theft is easy money, the perfect
income for drug addicts who have no other way to fund their habit."
Expert hackers?  WTF? 
Expert is hardly the right word, I've had issues in the past with 
someone  forging checks from my account (absurdley bad forgeries that 
didn't even spell my name right - but the bank still approved 
them.). Turns out it was a supposed friend of mine who became a 
habitual crystal meth user. One of the hazards of living in dotcom San 
Francisco was sharing houses with all sorts of characters. (of course - 
I met lots of cool people by sharing places with them too!)

Then again - looking at the quality of some of the malware out there 
(like the MSBlast code) makes me believe that there are maybe some 
people out there smokin and coding.

It's things like that that keep me away from anything more powerful than 
alcohol.

SM

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] MDKSA-2004:021 - Updated mozilla packages fix multiple vulnerabilities

[Florian Weimer]

Mandrake Linux Security Team wrote:

>  A number of vulnerabilities were discovered in Mozilla 1.4:

Wow.  A GNU/Linux distributor who finally releases a security update for
Mozilla.  Isn't this a first?

There is a list of published issues at:



Now compare this to what some distributions are shipping (most of them
are at 1.4, AFAIK).

Apparently, browser (and mail client) security isn't something at which
you can beat the market leader easily, despite its sorry performance in
this regard.  8-/

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, freenet.de, hotmail.com,
libero.it, netscape.net, postino.it, tiscali.co.uk, tiscali.cz,
tiscali.it, voila.fr, wanadoo.fr, yahoo.com.

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Meth and hacking?

[Chris DeVoney]

On Wednesday, March 10, 2004 9:44 AM, Steven Alexander wrote:

> http://www.msnbc.msn.com/id/4460349/
> 
> "The drugs and the crime fit neatly together; addicts strung 
> out on meth can stay awake and focused for days at a time, 
> making them expert hackers and mailbox thieves. And ID theft 
> is easy money, the perfect income for drug addicts who have 
> no other way to fund their habit."
> 
> Expert hackers?  WTF? 

Depends on how you define "expert" but I could accept Bob Sullivan's
defintion (although his idiot editor at MSNBC could have changed the
wording). 

According to the article, the theft doesn't start with an online activity;
it starts by stealing US Mail. The information is then successfully
exploited online. No, the person isn't an expert hacker, per sa; they become
expert at exploiting identify theft, just a fancy name for a thief.

But concentration and long, continuous effort working at a craft can improve
anyone's skills.
 
cdv

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Frank Knobbe]

On Tue, 2004-03-09 at 23:17, Aditya, ALD [Aditya Lalit Deshmukh] wrote:
> if you are routing all your scans from a vpn and the vpn connections
> are encrypted as they always are then is impossible that the scan are
> triggering some kind of signatures. i think while they *might* have a
> ids installed and working, they also might be filtering based on the
> traffic thresholds ... 

Dear Aditya,

I am NOW routing the scans through a VPN so that they are not blocked by
Comcast. When I noticed that something was going on, I was scanning from
my Cable IP. Once I realized that something seems fishy, I started to
tunnel all attack traffic, with the reported results.

Regards,
Frank



signature.asc
Description: This is a digitally signed message part

RE: [Full-Disclosure] Comcast using IPS to protect the Internet f rom their home user clients?

[Frank Knobbe]

On Wed, 2004-03-10 at 07:46, Chmielarski TOM-ATC090 wrote:
> Yes, they say they are now doing this.
> http://www.infoworld.com/article/04/03/09/HNcomcastspam_1.html

But this article says they are shutting systems down once identified as
a spam/hack/dos zombie. This can be done easily by reconfiguring the
Cable modem or removing MAC addresses from filter/pass tables (don't
know what types of access controls are in place over there).

It doesn't say they are using an inline IDS/IPS. Where would those IPS's
be? At the major NAPs or peering points? Or distributed in regional
hubs? I'm curious how they are dealing with the performance impact.
Perhaps they are using ASIC based IPS's, or very limited signature sets
(which would explain why a whisker scan completes unimpeded, but a nikto
scans hangs at the same "spot").

So far, a couple others reported that they noticed the same behavior. I
haven't heard anyone say "my scans are not affected". To reproduce the
test, fire off a nikto scan against a remote web server (remember, get
permission first). See if nikto completes without getting stuck. (I used
a recent nikto from the FBSD ports tree).

Anyhow, finding spam sources and bandwidth hogs and turning them off
manually is one thing. Having an network-based intrusion prevention
system sitting in their wires is another. Perhaps they are beta testing
that as an additional method to weed out bad traffic?

Regards,
Frank


PS: I'm completely okay with them filtering as long as they allow me to
tunnel my traffic to corporate servers. Whatever it takes to get rid of
spam is fine with me... 


signature.asc
Description: This is a digitally signed message part

[Full-Disclosure] The Meth Connection to Identity Theft

[Evil Wrangler]

Excuse me, but I take exception to the phrase "...making them expert
hackers and mailbox thieves" in the above cited story. Either you or your
editor has insulted the security community, whether you realize it or
not. Probably not the smartest thing to do for a journalist.

Either you have never been around hackers or you have never been
around meth addicts. As a long time hacker, I can seriously tell
you that drugs and hacking do not go together. Also people who are
dumb enough to do meth are not smart enough to figure out how to
write code to obtain unauthorized access to computers. Knock over
mailboxes, yes. Hack, not without serious rehab and a lot more clue
than your average doper can muster.

You might consider publishing a retraction before someone posts one on
your site for you

=;^)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Wrangler - dumping out cleartext passwords, near you!,
  "One day closer to a Microsoft-free world!"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Meth and hacking?

[madsaxon]

At 09:44 AM 3/10/2004 -0800, Steven Alexander wrote:

http://www.msnbc.msn.com/id/4460349/

"The drugs and the crime fit neatly together; addicts strung out on meth
can stay awake and focused for days at a time, making them expert
hackers and mailbox thieves. And ID theft is easy money, the perfect
income for drug addicts who have no other way to fund their habit."
Expert hackers?  WTF?
Just more uninformed media raving.  Seems to be all the rage lately.

m5x 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Meth and hacking?

[RMcElroy]

Makes allot of sense, since most Tweakers are 1. smart individuals in
the first place.. 2. Are known to have quite the collection of high tech
hardware..yeah right most hard core meth users I have seen can't afford
a computer much less try some huge scheme to steal identities

-Original Message-
From: Steven Alexander [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 10, 2004 9:44 AM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] Meth and hacking?


http://www.msnbc.msn.com/id/4460349/

"The drugs and the crime fit neatly together; addicts strung out on meth
can stay awake and focused for days at a time, making them expert
hackers and mailbox thieves. And ID theft is easy money, the perfect
income for drug addicts who have no other way to fund their habit."

Expert hackers?  WTF? 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Meth and hacking?

[Epic]

This has to be the dumbest statement I have ever heard.

I come from a long history of both hacking, and a meth addiction.

Being clean now from the meth for over 5 years, I can tell you honestly
that During the first month of the addiction you may possibly be able to
maintain, however beyond that, life turns upside down.

It is hard to maintain "hacking" when you cant afford electricity, you
are extremely paranoid, and you cant even remember what day it is.  

Meth does not allow one to focus for months on end like you would like
to imagine.  It keeps one awake,  but it pretty much decimates the mind.
Of course the tinfoil hats and the police scanner might keep the bad
guys away, but it wont make you a better hacker.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steven
Alexander
Sent: Wednesday, March 10, 2004 10:44 AM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] Meth and hacking?

http://www.msnbc.msn.com/id/4460349/

"The drugs and the crime fit neatly together; addicts strung out on meth
can stay awake and focused for days at a time, making them expert
hackers and mailbox thieves. And ID theft is easy money, the perfect
income for drug addicts who have no other way to fund their habit."

Expert hackers?  WTF? 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Meth and hacking?

[Steven Alexander]

http://www.msnbc.msn.com/id/4460349/

"The drugs and the crime fit neatly together; addicts strung out on meth
can stay awake and focused for days at a time, making them expert
hackers and mailbox thieves. And ID theft is easy money, the perfect
income for drug addicts who have no other way to fund their habit."

Expert hackers?  WTF? 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] MDKSA-2004:021 - Updated mozilla packages fix multiple vulnerabilities

[Mandrake Linux Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandrakelinux Security Update Advisory
 ___

 Package name:   mozilla
 Advisory ID:MDKSA-2004:021
 Date:   March 10th, 2004

 Affected versions:  9.2
 __

 Problem Description:

 A number of vulnerabilities were discovered in Mozilla 1.4:
 
 A malicious website could gain access to a user's authentication
 credentials to a proxy server.
 
 Script.prototype.freeze/thaw could allow an attacker to run
 arbitrary code on your computer.
 
 A vulnerability was also discovered in the NSS security suite which
 ships with Mozilla.  The S/MIME implementation would allow remote
 attackers to cause a Denial of Service and possibly execute arbitrary
 code via an S/MIME email message containing certain unexpected ASN.1
 constructs, which was demonstrated using the NISCC test suite.  NSS
 version 3.9 corrects these problems and has been included in this
 package (which shipped with NSS 3.8).
 
 Finally, Corsaire discovered that a number of HTTP user agents
 contained a flaw in how they handle cookies.  This flaw could
 allow an attacker to avoid the path restrictions specified by a
 cookie's originator.  According to their advisory:
 
 "The cookie specifications detail a path argument that can be used to
 restrict the areas of a host that will be exposed to a cookie.  By
 using standard traversal techniques this functionality can be
 subverted, potentially exposing the cookie to scrutiny and use in
 further attacks."
 
 As well, a bug with Mozilla and Finnish keyboards has been corrected.
 
 The updated packages are patched to correct these vulnerabilities.
 ___

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0594
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0564
  http://www.kb.cert.org/vuls/id/428230
  http://bugzilla.mozilla.org/show_bug.cgi?id=220122
  http://bugzilla.mozilla.org/show_bug.cgi?id=221526
  http://bugzilla.mozilla.org/show_bug.cgi?id=213012
  http://www.uniras.gov.uk/vuls/2003/006489/smime.htm
 __

 Updated Packages:
  
 Mandrakelinux 9.2:
 c38912bc7ec63477a99d54ca9d0da6a2  9.2/RPMS/libnspr4-1.4-13.2.92mdk.i586.rpm
 0389815c9e7dbe3e10fc0c26375bb3b1  9.2/RPMS/libnspr4-devel-1.4-13.2.92mdk.i586.rpm
 7646ec4e16c2c9358dcc98ebabf0a3b9  9.2/RPMS/libnss3-1.4-13.2.92mdk.i586.rpm
 63a527da7c61047ba425606e94ecd3be  9.2/RPMS/libnss3-devel-1.4-13.2.92mdk.i586.rpm
 e8bbe96aeb65cfab46ffe2aa354d902f  9.2/RPMS/mozilla-1.4-13.2.92mdk.i586.rpm
 dfa83fa168d574770a8799c581e18335  9.2/RPMS/mozilla-devel-1.4-13.2.92mdk.i586.rpm
 bb2b9c485b566b219749366c62500721  
9.2/RPMS/mozilla-dom-inspector-1.4-13.2.92mdk.i586.rpm
 ad11d0c4800bd95452d00a8ebaf5d98b  9.2/RPMS/mozilla-enigmail-1.4-13.2.92mdk.i586.rpm
 5fc51520069a0eba9f5a53dc93ba4eab  9.2/RPMS/mozilla-enigmime-1.4-13.2.92mdk.i586.rpm
 54bc668f3881fc320ee5d7c5a47cf691  9.2/RPMS/mozilla-irc-1.4-13.2.92mdk.i586.rpm
 adee5ba7d06873222b272fd5cb4002a6  9.2/RPMS/mozilla-js-debugger-1.4-13.2.92mdk.i586.rpm
 8ae4e6c230046102f6fb3718ea89a44c  9.2/RPMS/mozilla-mail-1.4-13.2.92mdk.i586.rpm
 1e1d178eb6e1b712ed4172fbcb9645a8  
9.2/RPMS/mozilla-spellchecker-1.4-13.2.92mdk.i586.rpm
 18dcce51283517af9f1d280e4cc671b2  9.2/SRPMS/mozilla-1.4-13.2.92mdk.src.rpm

 Mandrakelinux 9.2/AMD64:
 5452e154db36916d4e0710001a8c1bf4  amd64/9.2/RPMS/lib64nspr4-1.4-13.2.92mdk.amd64.rpm
 0dd5edee872e319e43b055348b439eb3  
amd64/9.2/RPMS/lib64nspr4-devel-1.4-13.2.92mdk.amd64.rpm
 18d23cac7a7eb9a45c40e484a42665fb  amd64/9.2/RPMS/lib64nss3-1.4-13.2.92mdk.amd64.rpm
 96e5b7a0bffa68a8a26f0fc0c33179bb  
amd64/9.2/RPMS/lib64nss3-devel-1.4-13.2.92mdk.amd64.rpm
 8f86da0aafcf57ce795935354bfe1284  amd64/9.2/RPMS/mozilla-1.4-13.2.92mdk.amd64.rpm
 4294cda22a8639804d64961b5232217b  
amd64/9.2/RPMS/mozilla-devel-1.4-13.2.92mdk.amd64.rpm
 fe1d7bbfcff75ed48276b125e5e07150  
amd64/9.2/RPMS/mozilla-dom-inspector-1.4-13.2.92mdk.amd64.rpm
 0389b9624511d9bfa8f9873c64e78819  
amd64/9.2/RPMS/mozilla-enigmail-1.4-13.2.92mdk.amd64.rpm
 f65b2fdf67002011cf138a7fc2a15048  
amd64/9.2/RPMS/mozilla-enigmime-1.4-13.2.92mdk.amd64.rpm
 3908bf0f64951a31d0b0d13fbed460f1  amd64/9.2/RPMS/mozilla-irc-1.4-13.2.92mdk.amd64.rpm
 e75e31efbc498cc11851c75c44233e93  
amd64/9.2/RPMS/mozilla-js-debugger-1.4-13.2.92mdk.amd64.rpm
 dee877e87556e579d54668a1e3a0bbf2  amd64/9.2/RPMS/mozilla-mail-1.4-13.2.92mdk.amd64.rpm
 09155dea70b8b6cf7afdd13a27dede18  
amd64/9.2/RPMS/mozilla-spellchecker-1.4-13.2.92mdk.amd64.rpm
 18dcce51283517af9f1d280e4cc671b2  amd64/9.2/SRPMS/mozilla-1.4-13.2.92mdk.src.rpm
 ___

 Bug IDs fixed (see 

[Full-Disclosure] MDKSA-2004:020 - Updated gdk-pixbuf packages fix BMP-handling vulnerability

[Mandrake Linux Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandrakelinux Security Update Advisory
 ___

 Package name:   gdk-pixbuf
 Advisory ID:MDKSA-2004:020
 Date:   March 10th, 2004

 Affected versions:  Corporate Server 2.1
 __

 Problem Description:

 A vulnerability in gdk-pixbuf versions before 0.20 exists that could
 allow a malicious BMP file to crash the Evolution mail client.  The
 updated packages have been patched to use gdk-pixbuf 0.22.0's BMP-
 handling code.
 ___

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0111
 __

 Updated Packages:
  
 Corporate Server 2.1:
 307125f2e64e3281a27091e8047cebd2  
corporate/2.1/RPMS/gdk-pixbuf-loaders-0.18.0-3.1.C21mdk.i586.rpm
 b6f48329e1651f870e455ee76bba549a  
corporate/2.1/RPMS/libgdk-pixbuf-gnomecanvas1-0.18.0-3.1.C21mdk.i586.rpm
 a5b60fb26fba984776edf66148fa4359  
corporate/2.1/RPMS/libgdk-pixbuf-xlib2-0.18.0-3.1.C21mdk.i586.rpm
 e0881362b84964b4c4f2d1229cdf99bb  
corporate/2.1/RPMS/libgdk-pixbuf2-0.18.0-3.1.C21mdk.i586.rpm
 1b748c4cde03a59eae05a5033384e098  
corporate/2.1/RPMS/libgdk-pixbuf2-devel-0.18.0-3.1.C21mdk.i586.rpm
 f9b4e50c5628d83f8ecac8d4a86514f4  
corporate/2.1/SRPMS/gdk-pixbuf-0.18.0-3.1.C21mdk.src.rpm

 Corporate Server 2.1/x86_64:
 94f75c462f340cd41fd750277867  
x86_64/corporate/2.1/RPMS/gdk-pixbuf-loaders-0.18.0-3.1.C21mdk.x86_64.rpm
 522747580e73376bc9cdda026d4fb768  
x86_64/corporate/2.1/RPMS/libgdk-pixbuf-gnomecanvas1-0.18.0-3.1.C21mdk.x86_64.rpm
 040fd303c41c248270f93b7f832e94f2  
x86_64/corporate/2.1/RPMS/libgdk-pixbuf-xlib2-0.18.0-3.1.C21mdk.x86_64.rpm
 0aa13efa52eb4146b1f1ecf33f62107c  
x86_64/corporate/2.1/RPMS/libgdk-pixbuf2-0.18.0-3.1.C21mdk.x86_64.rpm
 f7d53a73b37631855e6630070a20f6d9  
x86_64/corporate/2.1/RPMS/libgdk-pixbuf2-devel-0.18.0-3.1.C21mdk.x86_64.rpm
 f9b4e50c5628d83f8ecac8d4a86514f4  
x86_64/corporate/2.1/SRPMS/gdk-pixbuf-0.18.0-3.1.C21mdk.src.rpm
 ___

 To upgrade automatically use MandrakeUpdate or urpmi.  The verification
 of md5 checksums and GPG signatures is performed automatically for you.

 A list of FTP mirrors can be obtained from:

  http://www.mandrakesecure.net/en/ftp.php

 All packages are signed by Mandrakesoft for security.  You can obtain
 the GPG public key of the Mandrakelinux Security Team by executing:

  gpg --recv-keys --keyserver www.mandrakesecure.net 0x22458A98

 Please be aware that sometimes it takes the mirrors a few hours to
 update.

 You can view other update advisories for Mandrakelinux at:

  http://www.mandrakesecure.net/en/advisories/

 Mandrakesoft has several security-related mailing list services that
 anyone can subscribe to.  Information on these lists can be obtained by
 visiting:

  http://www.mandrakesecure.net/en/mlist.php

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID Date   User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFAT0FzmqjQ0CJFipgRAs5GAJ9xpQ3g7nJwy91h8/bOmecZSKzl8ACeIRMg
+ILA2zEr2x6iqNaio1GhM00=
=nfCU
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] MDKSA-2004:022 - Updated kdelibs packages fix cookie theft vulnerability

[Mandrake Linux Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandrakelinux Security Update Advisory
 ___

 Package name:   kdelibs
 Advisory ID:MDKSA-2004:022
 Date:   March 10th, 2004

 Affected versions:  9.1
 __

 Problem Description:

 Corsaire discovered that a number of HTTP user agents contained a flaw
 in how they handle cookies.  This flaw could allow an attacker to 
 avoid the path restrictions specified by a cookie's originator.
 According to their advisory:
 
 "The cookie specifications detail a path argument that can be used to
 restrict the areas of a host that will be exposed to a cookie.  By
 using standard traversal techniques this functionality can be
 subverted, potentially exposing the cookie to scrutiny and use in
 further attacks."
 
 This issue was fixed in KDE 3.1.3; the updated packages are patched to
 protect against this vulnerability.
 ___

 References:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0592
 __

 Updated Packages:
  
 Mandrakelinux 9.1:
 14bd813799d4891d520d1f8e7a525476  9.1/RPMS/kdelibs-3.1-58.3.91mdk.i586.rpm
 924fc0bec108f94236c97d640774f8c5  9.1/RPMS/kdelibs-common-3.1-58.3.91mdk.i586.rpm
 28bfd2897fb91fadcba14864c5ab85fa  9.1/RPMS/kdelibs-devel-3.1-58.3.91mdk.i586.rpm
 a02c4dc06c2122241fe2e4abc77e1c67  
9.1/RPMS/kdelibs-static-devel-3.1-58.3.91mdk.i586.rpm
 00230239edea7418aa01897d23f5dd07  9.1/SRPMS/kdelibs-3.1-58.3.91mdk.src.rpm

 Mandrakelinux 9.1/PPC:
 7f42212e4e4198af1460865f585a15cf  ppc/9.1/RPMS/kdelibs-3.1-58.3.91mdk.ppc.rpm
 d3db934d1ad9b0e9e04e9fab43b7f0c9  ppc/9.1/RPMS/kdelibs-common-3.1-58.3.91mdk.ppc.rpm
 71b0d44138e874d8089298594a7e30a8  ppc/9.1/RPMS/kdelibs-devel-3.1-58.3.91mdk.ppc.rpm
 318a821a280404541a929b8d3d55339e  
ppc/9.1/RPMS/kdelibs-static-devel-3.1-58.3.91mdk.ppc.rpm
 00230239edea7418aa01897d23f5dd07  ppc/9.1/SRPMS/kdelibs-3.1-58.3.91mdk.src.rpm
 ___

 To upgrade automatically use MandrakeUpdate or urpmi.  The verification
 of md5 checksums and GPG signatures is performed automatically for you.

 A list of FTP mirrors can be obtained from:

  http://www.mandrakesecure.net/en/ftp.php

 All packages are signed by Mandrakesoft for security.  You can obtain
 the GPG public key of the Mandrakelinux Security Team by executing:

  gpg --recv-keys --keyserver www.mandrakesecure.net 0x22458A98

 Please be aware that sometimes it takes the mirrors a few hours to
 update.

 You can view other update advisories for Mandrakelinux at:

  http://www.mandrakesecure.net/en/advisories/

 Mandrakesoft has several security-related mailing list services that
 anyone can subscribe to.  Information on these lists can be obtained by
 visiting:

  http://www.mandrakesecure.net/en/mlist.php

 If you want to report vulnerabilities, please contact

  security_linux-mandrake.com

 Type Bits/KeyID Date   User ID
 pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFAT0RcmqjQ0CJFipgRAobUAJ9w86MNjUwRhI/Cg8acwebhvR9OEQCfVJ8y
rLX1L+CyBNpYfxbgzpU+ztM=
=/L0q
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[sysadmin]

Just so everyone knows this wasn't merely a humorous quip.

I used to work for Bresnan then Charter after the buyout.  There was a high
correlation between solar flare activity and modem activity (cycling, snr,
rx/tx values etc) in the Michigan, Wisconsin, Minnesota systems we
monitored.  It is however a strong indicator that the system has
leaks/ingress problems.  Charter followed through on the system cleanup we
started (as Bresnan).  As of Feb last year there were daily reports system
stability was increasing by leaps and bounds.  Of course that also was about
the time they started laying off all the people building these awsome tools
 Yours truly included ...

--Ray

- Original Message - 
From: "Cael Abal" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 10, 2004 10:50 AM
Subject: Re: [Full-Disclosure] Comcast using IPS to protect the Internet
from their home user clients?


> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> TooManyMirrors wrote:
> > My Terayon (cable modem) went out for nearly two days and then
> > magicly came back on after a tech appoitment was made. No change in
> > the setup or anything.
>
> Solar flares.
>
> C
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.4 (MingW32)
>
> iD8DBQFATzlUR2vQ2HfQHfsRApCSAJ9KFptxxOCKf5edGwkh0GI3sH75wACfUXdH
> OJ5aPb8AEKCkzPRufY+L4QM=
> =jRBT
> -END PGP SIGNATURE-
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Re: Re: Confixx 2.0.xx SQL_Injections and reading MySQL Root-PW

[checker]

In the year 2003 I've successfully tested the following exploit on the 
sw-soft confixx demoversion

http://confixx-demo.sw-soft.com/user/tools_cgicheck2.php?dir=3D&file=3D%20./x%20|/bin/cat%20/etc/passwd

i am sure - it still works on many servers.

The php safemode is not really a protection against this bug because 
there a several possibilities to skip safemode (e.g. "date -f /etc/passwd").

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Cael Abal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

TooManyMirrors wrote:
> My Terayon (cable modem) went out for nearly two days and then
> magicly came back on after a tech appoitment was made. No change in
> the setup or anything.

Solar flares.

C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFATzlUR2vQ2HfQHfsRApCSAJ9KFptxxOCKf5edGwkh0GI3sH75wACfUXdH
OJ5aPb8AEKCkzPRufY+L4QM=
=jRBT
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] [RHSA-2004:102-01] Updated gdk-pixbuf packages fix denial of service vulnerability

[bugzilla]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -
   Red Hat Security Advisory

Synopsis:  Updated gdk-pixbuf packages fix denial of service vulnerability
Advisory ID:   RHSA-2004:102-01
Issue date:2004-03-10
Updated on:2004-03-10
Product:   Red Hat Linux
Keywords:  DoS
Cross references:  
Obsoletes: 
CVE Names: CAN-2004-0111
- -

1. Topic:

Updated gdk-pixbuf packages that fix a denial of service vulnerability that
could affect applications such as Evolution are now available.

2. Relevant releases/architectures:

Red Hat Linux 9 - i386

3. Problem description:

The gdk-pixbuf package contains an image loading library used with the 
GNOME GUI desktop environment.  In Red Hat Linux 9 this library is used by
applications, such as Evolution, to load images.

Thomas Kristensen discovered a bitmap file that would cause the Evolution
mail reader to crash.  This issue was caused by a flaw that affects
versions of the gdk-pixbuf package prior to 0.20.  To exploit this flaw, a
remote attacker could send (via email) a carefully-crafted BMP file, which
would cause Evolution to crash.  The Common Vulnerabilities
and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0111
to this issue.

Users are advised to upgrade to these updated packages containing
gdk-pixbuf version 0.22, which is not vulnerable to this issue.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which are
not installed but included in the list will not be updated.  Note that you
can also use wildcards (*.rpm) if your current directory *only* contains the
desired RPMs.

Please note that this update is also available via Red Hat Network.  Many
people find this an easier way to apply updates.  To use Red Hat Network,
launch the Red Hat Update Agent with the following command:

up2date

This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.

If up2date fails to connect to Red Hat Network due to SSL Certificate 
Errors, you need to install a version of the up2date client with an updated 
certificate.  The latest version of up2date is available from the Red Hat 
FTP site and may also be downloaded directly from the RHN website:

https://rhn.redhat.com/help/latest-up2date.pxt

5. RPMs required:

Red Hat Linux 9:

SRPMS:
ftp://updates.redhat.com/9/en/os/SRPMS/gdk-pixbuf-0.22.0-6.1.0.src.rpm

i386:
ftp://updates.redhat.com/9/en/os/i386/gdk-pixbuf-0.22.0-6.1.0.i386.rpm
ftp://updates.redhat.com/9/en/os/i386/gdk-pixbuf-devel-0.22.0-6.1.0.i386.rpm
ftp://updates.redhat.com/9/en/os/i386/gdk-pixbuf-gnome-0.22.0-6.1.0.i386.rpm



6. Verification:

MD5 sum  Package Name
- --

df19bd665aba2b00d36ced57aa4d6ffe 9/en/os/SRPMS/gdk-pixbuf-0.22.0-6.1.0.src.rpm
4b0dd19751fc5fdd00222e556af8bc02 9/en/os/i386/gdk-pixbuf-0.22.0-6.1.0.i386.rpm
73781fffcb9cb8109d0391454d821ecf 9/en/os/i386/gdk-pixbuf-devel-0.22.0-6.1.0.i386.rpm
38fe3fce4d19ea79df588f62182d3e26 9/en/os/i386/gdk-pixbuf-gnome-0.22.0-6.1.0.i386.rpm

These packages are GPG signed by Red Hat for security.  Our key is
available from https://www.redhat.com/security/keys.html

You can verify each package with the following command:

rpm --checksig -v 

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the md5sum with the following command:

md5sum 


7. References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0111

8. Contact:

The Red Hat security contact is <[EMAIL PROTECTED]>.  More contact
details at https://www.redhat.com/solutions/security/news/contact.html

Copyright 2003 Red Hat, Inc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFATynBXlSAg2UNWIIRAn0gAKCZN7OJQSaklbwKOoscNioYzvrwRgCeK43I
Vdxlg8Sq2MyXn2+WJgLIwws=
=KJmk
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] [RHSA-2004:075-01] Updated kdelibs packages resolve cookie security issue

[bugzilla]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -
   Red Hat Security Advisory

Synopsis:  Updated kdelibs packages resolve cookie security issue
Advisory ID:   RHSA-2004:075-01
Issue date:2004-03-10
Updated on:2004-03-10
Product:   Red Hat Linux
Keywords:  
Cross references:  
Obsoletes: 
CVE Names: CAN-2003-0592
- -

1. Topic:

Updated kdelibs packages that fix a flaw in cookie path handling are now
available.

2. Relevant releases/architectures:

Red Hat Linux 9 - i386

3. Problem description:

Konqueror is a file manager and Web browser for the K Desktop Environment
(KDE).

Flaws have been found in the cookie path handling between a number of Web
browsers and servers.  The HTTP cookie standard allows a Web server
supplying a cookie to a client to specify a subset of URLs on the origin
server to which the cookie applies.  Web servers such as Apache do not
filter returned cookies and assume that the client will only send back
cookies for requests that fall within the server-supplied subset of URLs.
However, by supplying URLs that use path traversal (/../) and character
encoding, it is possible to fool many browsers into sending a cookie to a
path outside of the originally-specified subset.

KDE version 3.1.3 and later include a patch to Konquerer that disables the
sending of cookies to the server if the URL contains such encoded
traversals.  Red Hat Linux 9 shipped with KDE 3.1 and is therefore
vulnerable to this issue.

Users of Konquerer are advised to upgrade to these erratum packages, which
contain a backported patch for this issue.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which are
not installed but included in the list will not be updated.  Note that you
can also use wildcards (*.rpm) if your current directory *only* contains the
desired RPMs.

Please note that this update is also available via Red Hat Network.  Many
people find this an easier way to apply updates.  To use Red Hat Network,
launch the Red Hat Update Agent with the following command:

up2date

This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.

If up2date fails to connect to Red Hat Network due to SSL Certificate 
Errors, you need to install a version of the up2date client with an updated 
certificate.  The latest version of up2date is available from the Red Hat 
FTP site and may also be downloaded directly from the RHN website:

https://rhn.redhat.com/help/latest-up2date.pxt

5. RPMs required:

Red Hat Linux 9:

SRPMS:
ftp://updates.redhat.com/9/en/os/SRPMS/kdelibs-3.1-13.src.rpm

i386:
ftp://updates.redhat.com/9/en/os/i386/kdelibs-3.1-13.i386.rpm
ftp://updates.redhat.com/9/en/os/i386/kdelibs-devel-3.1-13.i386.rpm



6. Verification:

MD5 sum  Package Name
- --

c6160cfd6b412cd60c8a55abfdeac022 9/en/os/SRPMS/kdelibs-3.1-13.src.rpm
b54a0acde508064c10e87eb735b95543 9/en/os/i386/kdelibs-3.1-13.i386.rpm
dfee8cfc2b14117fb3d00908198849f3 9/en/os/i386/kdelibs-devel-3.1-13.i386.rpm

These packages are GPG signed by Red Hat for security.  Our key is
available from https://www.redhat.com/security/keys.html

You can verify each package with the following command:

rpm --checksig -v 

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the md5sum with the following command:

md5sum 


7. References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0592

8. Contact:

The Red Hat security contact is <[EMAIL PROTECTED]>.  More contact
details at https://www.redhat.com/solutions/security/news/contact.html

Copyright 2003 Red Hat, Inc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFATymkXlSAg2UNWIIRAoLoAKDBwW3jV2HhOKuX4KR44MLg7FwMdwCgsKWf
9UvBd+q0S1LgZtXlK9yMZZc=
=o428
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] [RHSA-2004:093-01] Updated sysstat packages fix security vulnerabilities

[bugzilla]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -
   Red Hat Security Advisory

Synopsis:  Updated sysstat packages fix security vulnerabilities
Advisory ID:   RHSA-2004:093-01
Issue date:2004-03-10
Updated on:2004-03-10
Product:   Red Hat Linux
Keywords:  
Cross references:  
Obsoletes: 
CVE Names: CAN-2004-0107
- -

1. Topic:

Updated sysstat packages that fix various bugs and a minor security issue
are now available.

2. Relevant releases/architectures:

Red Hat Linux 9 - i386

3. Problem description:

Sysstat is a tool for gathering system statistics. 

A bug was found in the Red Hat sysstat package post and trigger scripts,
which used insecure temporary file names. A local attacker could overwrite
system files using carefully-crafted symbolic links in the /tmp directory.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0107 to this issue.

Other issues addressed in this advisory include:

* iostat -x should return all partitions on the system (up to a maximum of
1024)

* sar should handle network device names with more than 8 characters properly

Users of sysstat should upgrade to these updated packages, which
contain patches to correct these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which are
not installed but included in the list will not be updated.  Note that you
can also use wildcards (*.rpm) if your current directory *only* contains the
desired RPMs.

Please note that this update is also available via Red Hat Network.  Many
people find this an easier way to apply updates.  To use Red Hat Network,
launch the Red Hat Update Agent with the following command:

up2date

This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.

If up2date fails to connect to Red Hat Network due to SSL
Certificate Errors, you need to install a version of the
up2date client with an updated certificate.  The latest version of
up2date is available from the Red Hat FTP site and may also be
downloaded directly from the RHN website:

https://rhn.redhat.com/help/latest-up2date.pxt

5. RPMs required:

Red Hat Linux 9:

SRPMS:
ftp://updates.redhat.com/9/en/os/SRPMS/sysstat-4.0.7-4.rhl9.1.src.rpm

i386:
ftp://updates.redhat.com/9/en/os/i386/sysstat-4.0.7-4.rhl9.1.i386.rpm



6. Verification:

MD5 sum  Package Name
- --

53b2bdd79619a4407478ef9cae8fdd22 9/en/os/SRPMS/sysstat-4.0.7-4.rhl9.1.src.rpm
3cc21e61f4aec6c820dc496cb476f834 9/en/os/i386/sysstat-4.0.7-4.rhl9.1.i386.rpm

These packages are GPG signed by Red Hat for security.  Our key is
available from https://www.redhat.com/security/keys.html

You can verify each package with the following command:

rpm --checksig -v 

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the md5sum with the following command:

md5sum 


7. References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0107

8. Contact:

The Red Hat security contact is <[EMAIL PROTECTED]>.  More contact
details at https://www.redhat.com/solutions/security/news/contact.html

Copyright 2003 Red Hat, Inc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFATymzXlSAg2UNWIIRAgWDAJwK4AKpVPgfjQvOsn9MMtV7ceaPbgCcClS1
KYiRbeCdFuP56DDb322smYg=
=VUYQ
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Good Places to Start

[Andrew Aris]

Hi all,

I have been asked to collate all the starting out tips I was given by
various list members into one place so here you go:

Security Focus (lots of useful mailing lists):

http://www.securityfocus.com/foundations

Top 20 lists:

http://www.sans.org/top20/

Cert's good practices:

http://www.cert.org/security-improvement/#practices

"Get a good book"

egs: 
"Hacking Exposed" - http://www.hackingexposed.com/
"Secrets and Lies" - http://www.schneier.com/book-sandl.html
"Beyond Fear" - http://www.schneier.com/book-beyondfear.html


CISSP Study Guides:

https://www.isc2.org/cgi/request_studyguide.cgi

Anti-online:

http://www.antionline.com

Think that was more or less everything, oh plus everyone told me to read,
read, read! 
Thanks again to everyone who mailed with ideas, if I've missed anything off
then I'm sorry and do let me know!

regards,

Andrew Aris

--
big fish internet ltd, 8 beetham road, milnthorpe, cumbria LA7 7QR
tel: +44 (0)15395 64580   http://www.bfinternet.co.uk
big fish internet limited t/a bf internet registered in england no. 3558791
-- 



___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Comcast using IPS to protect the Internet f rom their home user clients?

[Chmielarski TOM-ATC090]

Yes, they say they are now doing this.
http://www.infoworld.com/article/04/03/09/HNcomcastspam_1.html
-Tom
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Knobbe
Sent: Monday, March 08, 2004 8:29 PM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] Comcast using IPS to protect the Internet from their home 
user clients?


This post should probably have gone to SF-PenTests, but since it is more of a 
discussion item, I thought about Full Disclosure, the list for vuln info and 
everything else :)


Anyhow, I noticed that certain vulnerability scans, for example scans using Nikto and 
similar tools, when run from a Comcast address show a different behavior than when 
they are run from a clear, uncontrolled Internet connection (i.e. corporate T-3). In 
fact, it appears like Comcast has an Inline-IDS (some call it an IPS ;) sitting on its 
wires, filtering out certain signatures and blocking subsequent access for a short 
period of time. For example, scan progresses, then hangs inexplicably, then resumes, 
trips a sig, and hangs again. At the same time, the same scan from a non-Comcast 
address continues without any hick-ups. Targets have been ruled out (up and running, 
verified at the same time from different addresses), and connectivity to the rest of 
the net remains. It's looks like just the src-dst address pair is used so that all 
connections from a Comcast src to that particular dst are blocked for a short moment 
(1-5 minutes).

Has anyone else noticed that? Is Comcast actually attempting to keep all those 
worms'n'viruses of their clients away from the Internet?

How many other ISP's are known to use IPS's inline to protect themselves from the 
'Net, or protect the 'Net from themselves?

Regards,
Frank (routing all scans via VPN through corporate hosts ;)





___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Corsaire Security Advisory: Multiple vendor HTTP user agent cookie path traversal issue

[advisories]

-- Corsaire 
Security Advisory --Title: Multiple vendor HTTP user agent cookie path 
traversal issueDate: 12.07.03Application: VariousEnvironment: 
VariousAuthor: Martin O'Neal [EMAIL PROTECTED]Audience: Vendor 
notificationReference: c030712-001-- Scope --The aim of 
this document is to clearly define a vulnerability in the cookie handling 
functionality of multiple vendors HTTP user agents that would allow an 
attacker to avoid the path restrictions specified by a cookie's 
originator.-- History --Discovered: 08.07.03Vendors 
notified: 12.07.03 - 18.07.03RFC2965 authors notified: 29.07.03CERT/CC 
notified: 20.08.03Uncoordinated Opera release: 05.09.03NISCC notified: 
24.10.03Document released: 10.03.04-- Overview --The 
cookie specifications detail a path argument that can be used to restrict 
the areas of a host that will be exposed to a cookie. By using standard 
traversal techniques this functionality can be subverted, potentially 
exposing the cookie to scrutiny and use in further attacks.-- 
Analysis --The cookie standard is formally defined in RFC2965 [1]. This 
makes reference to the optional path argument that allows a cookie 
originator to specify "the subset of URLs on the origin server to which this 
cookie applies".Many of the user agents appear to function by simply 
string matching the initial part of the requested URL, so by using a 
combination of traversal and standard encoding techniques the path 
restriction functionality can be subverted. Where this oversight 
becomes useful is in conducting attacks against the session cookies of an 
application that does not suffer from any exploitable validation flaws, but 
that shares the same server environment with one that does.It is 
worth acknowledging that whilst many client applications still suffer from 
"same origin" issues then this is something of a moot point 
anyway.-- Proof of concept --This proof of concept is 
known to work with the current releases of the major browsers.For 
this example we shall imagine that our secure application shares a host with 
some sample files that were installed at the same time as the web server. 
Obviously, this would never happen in a live production environment (pauses 
to insert tongue firmly in cheek).The secure application is located 
within the "/secure" folder and sets the cookie path argument to "/secure" 
which is intended to restrict the cookie information from being exposed 
elsewhere on the same host.The attacker knows that the secure 
application has no useable vulnerabilities in itself and can also see that 
the cookie that it sets has the path restricted. They also know that the 
sample files have an exploitable XSS flaw that would give them access to the 
all-important session cookies (if they can get a valid user to access it; a 
completely different problem to solve).A lot of browsers will make a 
URI canonical before passing it to the target server, resolving any 
redundant directory traversal prior to dispatch. By using an encoded URL the 
attacker can defeat this functionality, bypass the path restriction intended 
by the originator and get the valid users browser to expose the session 
cookie to the sample application:  http://host/secure/%2e%2e/sample/insecure.cgi?xss=>-- Recommendations --The 
cookie path functionality of the affected user agents should be revised to 
ensure that they work as intended and cannot be bypassed by traversal and 
encoding techniques.Many of the vendors involved have silently patched 
this issue in product releases made after July 2003. Check with the 
individual vendor for additional information.-- CVE 
--The Common Vulnerabilities and Exposures (CVE) project has assigned 
multiple names to this issue:CAN-2003-0513 Microsoft Internet 
Explorer cookie path traversal issueCAN-2003-0514 Apple Safari cookie path 
traversal issueCAN-2003-0592 KDE Konqueror cookie path traversal 
issueCAN-2003-0593 Opera cookie path traversal issueCAN-2003-0594 
Mozilla cookie path traversal issueThese are candidates for inclusion in 
the CVE list, which standardises names for security problems (http://cve.mitre.org),-- References --[1] http://www.faqs.org/rfcs/rfc2965.html-- Revision --a. Initial release.b. 
Minor revision.c. Amended history section.d. Amended history 
section.e. Amended recommendations section.f. Released.-- 
Distribution --This security advisory may be freely distributed, 
provided that it remains unaltered and in its original form. -- 
Disclaimer --The information contained within this advisory is supplied 
"as-is" with no warranties or guarantees of fitness of use or otherwise. 
Corsaire accepts no responsibility for any damage caused by the use or 
misuse of this information.Copyright 2003 Corsaire Limited. All 
rights reserved.

[Full-Disclosure] Outlook mailto: URL argument injection vulnerability

[Jouko Pynnonen]

OVERVIEW


Microsoft Outlook contains a vulnerability which allows execution of 
arbitrary code when a victim user views a web page or an e-mail message 
created by an attacker.



DETAILS
===

During Outlook installation, a mailto: URL handler is registered to the 
system. When a mailto: URL is opened, the system starts OUTLOOK.EXE 
with the following arguments:

  OUTLOOK.EXE -c IPM.Note /m "mailto:[EMAIL PROTECTED]"

If the URL contains a quote symbol, additional command line arguments
can be injected to OUTLOOK.EXE. The program recognizes several command
line switches. Also a startup URL to be opened by Outlook can be 
supplied on command line. This URL can be a javascript: URL, and if the 
"Outlook today" page is the current view in Outlook, the JavaScript 
code will be executed in the "Local machine" zone. This allows an 
attacker to e.g. download and start a desired EXE program.

A web page or e-mail message exploiting this flaw may contain for 
instance an IMG tag to refer to a mailto: URL. The victim user need not 
click on a link.

If the "Outlook today" view isn't the default view in Outlook, the 
attacker can still carry out the attack by using two mailto: URLs; The 
information in the mitigating factors section of Microsoft's bulletin 
regarding this is inaccurate. The first mailto: URL would start 
OUTLOOK.EXE and cause it to show the "Outlook today" view, and the 
second one would supply the offending JavaScript code. This scenario 
was verified by an exploit.

The issue is not a standard "cross site scripting" vulnerability, but a 
different kind of injection attack. The exploit can inject command line 
switches and arguments to OUTLOOK.EXE because quote symbols in the URL 
aren't escaped or otherwise processed. This can be considered a new 
vulnerability category, and further investigation has shown that 
similar attacks can be carried out against other software which register 
a URL handler.



AFFECTED VERSIONS
=

According to Microsoft the affected supported versions are Microsoft 
Office XP SP2 and Microsoft Outlook 2002 SP 2. Some earlier versions 
are vulnerable too, but not supported by the vendor.



SOLUTION


Microsoft was informed on July 21st, 2003 and has released an update 
to correct the problem. A bulletin describing the update can be seen
at

  http://www.microsoft.com/technet/security/Bulletin/MS04-009.mspx



CREDITS
===

The vulnerability was discovered and researched by Jouko Pynnönen, 
Finland.




-- 
Jouko Pynnönen  Web: http://iki.fi/jouko/
[EMAIL PROTECTED]GSM: +358 41 5504555

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Has anyone seen this in their e-mail

[Aditya, ALD [Aditya Lalit Deshmukh]]

> 
> Yeah, this looks like one I've got yesterday too. The message was
> different and even the password was different (clever virus-writer huh).

how difficult would it be to use random and differnet passwords for each infection, 
pretty easy for a smart programmer or the clever virus writer,

maybe they are using the passwords to keep track of the version of the viruses 

-aditya



Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Comcast using IPS to protect the Internet from their home user clients?

[Aditya, ALD [Aditya Lalit Deshmukh]]

dear frank, 

if you are routing all your scans from a vpn and the vpn connections are encrypted as 
they always are then is impossible that the scan are triggering some kind of 
signatures. i think while they *might* have a ids installed and working, they also 
might be filtering based on the traffic thresholds ... 

the scan might been ovee the limit and the scannning stops!

out isp used to do this a long ago something like in 2000, but has since stopped 

-aditya

> Anyhow, I noticed that certain vulnerability scans, for example scans
> using Nikto and similar tools, when run from a Comcast address show a
> different behavior than when they are run from a clear, uncontrolled
> Internet connection (i.e. corporate T-3). In fact, it appears like
> Comcast has an Inline-IDS (some call it an IPS ;) sitting on its wires,
> filtering out certain signatures and blocking subsequent access for a
> short period of time. For example, scan progresses, then hangs
> inexplicably, then resumes, trips a sig, and hangs again. At the same
> time, the same scan from a non-Comcast address continues without any
> hick-ups. Targets have been ruled out (up and running, verified at the
> same time from different addresses), and connectivity to the rest of the
> net remains. It's looks like just the src-dst address pair is used so
> that all connections from a Comcast src to that particular dst are
> blocked for a short moment (1-5 minutes).
> 
> Has anyone else noticed that? Is Comcast actually attempting to keep all
> those worms'n'viruses of their clients away from the Internet?
> 
> How many other ISP's are known to use IPS's inline to protect themselves
> from the 'Net, or protect the 'Net from themselves?
> 
> Regards,
> Frank (routing all scans via VPN through corporate hosts ;)
> 
> 
> 
> 
> 
> 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [11:29:07 security.rc] RE: [Full-Disclosure] Where to start

[Aschwin Wesselius]

On Wed, 2004-03-10 at 06:17, Aditya, ALD [Aditya Lalit Deshmukh] wrote:
> > 
> > Does a good security-officer have to know everything about every hole? I
> > myself don't think so, but where do people start?
> 
> security officer is more of a complience officer, he makes sure that all the users, 
> admin and  other it staff stick to the policies created.
> 

I think this title is different in every company, just as system
adminstrator can also mean you have to do network adminstration. In The
Netherlands, where I live, job descriptions are growing pretty wild with
even more exotic titles while demanding hilarious combinations of skills
or certifications. But still they want young people with experience. Go
figure.

> > I want to learn more about security stuff, but I can't find the real
> > basics to build upon anywhere. When there are posts on lists they
> > presume that everybody has a certain knowledge level and are aware of
> > best practices. But is this true?
> 
> to start the basics some of the more experienced members of this list will point you 
> out just the right sources but take all the advice with a grain of salt.
> 

I like to cross reference when I am in doubt of a subject or statement
from anybody. As soon as another source says something similar the doubt
decreases. Another one on this list stated to always test any findings
in your own environment and if different post the results back where
needed. This is off course the scientific approach.

> > Just because there are discussions, it seems that there is not one
> > overall and central way of keeping track of evolving issues. How do
> > people keep track easily with up to date best practices and not get
> > distracted by "old" advisory?
> 
> discussion is a good way to keep currunt and adapt your existing infrastructure for 
> the latest threats
> 

Jep, I do understand that one. But how is it realistic, to fight against
current or most recent threats and letting gaps exists wich where
discovered last year? Some people just step in today, but are not
completely aware of good old school tricks wich might still be appliable
or even exploitable in his/her very own network? Then, yes you keep
track of "popular" exploits, but are vulnerable for things real veteran
crackers come up with.

There should be some checklist to go trough with some chronology so you
can check your network or just your system against it. Or do those tools
available nowadays it for you? I think you can't depend on just simple
thinking that the most recent version of your software is patched
against old threats

Anybody with a good insightful thought?

(I was told this list is not appropiate for discussions like this...
where to go? besides SecurityFocus where I've submitted myself to)

Aschwin Wesselius

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] [SECURITY] [DSA 458-1] New python2.2 packages fix buffer overflow

[debian-security-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 458-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Matt Zimmerman
March 9th, 2004 http://www.debian.org/security/faq
- --

Package: python2.2
Vulnerability  : buffer overflow
Problem-Type   : remote
Debian-specific: no
CVE Ids: CAN-2004-0150

Sebastian Schmidt discovered a buffer overflow bug in Python's
getaddrinfo function, which could allow an IPv6 address, supplied by a
remote attacker via DNS, to overwrite memory on the stack.

This bug only exists in python 2.2 and 2.2.1, and only when IPv6
support is disabled.  The python2.2 package in Debian woody meets
these conditions (the 'python' package does not).

For the stable distribution (woody), this bug has been fixed in
version 2.2.1-4.3.

The unstable distribution (sid) is not affected by this bug.

We recommend that you update your python2.2 package.

Upgrade Instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.

Debian GNU/Linux 3.0 alias woody
- 

  Source archives:

http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.3.dsc
  Size/MD5 checksum: 1150 026cac287c887609b61eb9fa776d08e7

http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.3.diff.gz
  Size/MD5 checksum:92168 5490c5305412b26e913ef0c9d3942f92

http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1.orig.tar.gz
  Size/MD5 checksum:  6536167 88aa07574673ccfaf35904253c78fc7d

  Architecture independent components:


http://security.debian.org/pool/updates/main/p/python2.2/idle-python2.2_2.2.1-4.3_all.deb
  Size/MD5 checksum:   112800 2f7bbe87cd65fc46d692549fdc2ae27a

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-doc_2.2.1-4.3_all.deb
  Size/MD5 checksum:  1307068 dda8d059664d4b8ee062ac3e10b844a9

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-elisp_2.2.1-4.3_all.deb
  Size/MD5 checksum:49874 31d0c5a9eae3e2d3871bd6aabb36cbc0

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-examples_2.2.1-4.3_all.deb
  Size/MD5 checksum:   477558 50bad66b5dbceb48eea56527266290ec

  Alpha architecture:


http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.3_alpha.deb
  Size/MD5 checksum:  2139014 4513103ad2a30bb36a5b6084770a33ad

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.3_alpha.deb
  Size/MD5 checksum:   863556 f7a9616d790f93a4d91de3d2274d55b7

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.3_alpha.deb
  Size/MD5 checksum:17888 5a97553b3f1d739676284ce7589011d6

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.3_alpha.deb
  Size/MD5 checksum:21522 4824c04e78ff693517f079aeb31facf8

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.3_alpha.deb
  Size/MD5 checksum:86040 36c357ee7a8d70f39185d896ec52d573

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.3_alpha.deb
  Size/MD5 checksum:52100 484c5a2ccd5ec619efa21ee4e679b548

  ARM architecture:


http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.3_arm.deb
  Size/MD5 checksum:  1951662 f74c8b28ecda2c514e590ef1caa85ac3

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-dev_2.2.1-4.3_arm.deb
  Size/MD5 checksum:   774368 500a8ad4163ce2fa9f1add1262f55b52

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-gdbm_2.2.1-4.3_arm.deb
  Size/MD5 checksum:16714 147ef5558199d5549106fe7c14f9cc8d

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-mpz_2.2.1-4.3_arm.deb
  Size/MD5 checksum:19960 fcb3839792b43f2cb1a62eadee44a077

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-tk_2.2.1-4.3_arm.deb
  Size/MD5 checksum:84344 b1e4c75a260568cf6e5f9335b94fee49

http://security.debian.org/pool/updates/main/p/python2.2/python2.2-xmlbase_2.2.1-4.3_arm.deb
  Size/MD5 checksum:49558 e28e462a68fd73fc9851e43fcd1185a2

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/p/python2.2/python2.2_2.2.1-4.3_i386.deb
  Size/MD5 checksum:  1888568 6ebcdd2814

RE: [Full-Disclosure] Where to start

[Aditya, ALD [Aditya Lalit Deshmukh]]

> 
> Does a good security-officer have to know everything about every hole? I
> myself don't think so, but where do people start?

security officer is more of a complience officer, he makes sure that all the users, 
admin and  other it staff stick to the policies created.

 
> If I see lists and forums about network-security it seems that everybody
> knows a lot and has a huge reference base. Is this true?

this is a mirage, people can make statements based on they find something they find in 
google and can appear all knowing ( this is a good method for finding info but it can 
be abused ), like they say little knowledge is a dangerous thing google is a 
dangerous thing. usless used properly  
 
> I want to learn more about security stuff, but I can't find the real
> basics to build upon anywhere. When there are posts on lists they
> presume that everybody has a certain knowledge level and are aware of
> best practices. But is this true?

to start the basics some of the more experienced members of this list will point you 
out just the right sources but take all the advice with a grain of salt.

> Just because there are discussions, it seems that there is not one
> overall and central way of keeping track of evolving issues. How do
> people keep track easily with up to date best practices and not get
> distracted by "old" advisory?

discussion is a good way to keep currunt and adapt your existing infrastructure for 
the latest threats


___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Has anyone seen this in their e-mail

[Nick FitzGerald]

Aschwin Wesselius <[EMAIL PROTECTED]> wrote:

<>
> ...  I bet it is a Bagle.Gen-zippwd (who gives them names
> actually?) sort of worm, but am not sure. 

That is a heuristic detection -- I could easily make hundreds of .ZIPs 
containing copies of notepad.exe or similar that would be (mis-) 
detected as that.


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [11:30:44 security.rc] RE: [Full-Disclosure] Has anyone seen this in their e-mail

[Aschwin Wesselius]

On Wed, 2004-03-10 at 06:17, Aditya, ALD [Aditya Lalit Deshmukh] wrote:
> > 
> > Yeah, this looks like one I've got yesterday too. The message was
> > different and even the password was different (clever virus-writer huh).
> 
> how difficult would it be to use random and differnet passwords for each infection, 
> pretty easy for a smart programmer or the clever virus writer,
> 
> maybe they are using the passwords to keep track of the version of the viruses 
> 

Uhmit was more like a sarcastic statement than actually a shout of
admiration. IOW, the writer was at least that smart, but not smart
enough to not write a virus at all.

Aschwin Wesselius

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Re: New Virus?

[Nick FitzGerald]

Brian Eckman <[EMAIL PROTECTED]> to me:

> First off, Nick, thanks a bunch for sharing that info with the list.

You're welcome...

> FYI, I sent in a sample to NAI using the above address. I got an 
> autoreply that it was received, then another autoreply that it was not a 
> known threat and that it was being forwarded to an AVERT researcher. So, 
> I deleted the backdoor trojan, as I had already submitted it to the 
> company we have a site license with. (I sent it into NAI as the computer 
> that was infected with it had McAfee on it.)
> 
> Later, I got an E-mail that they had a virus gateway strip the sample 
> out of my message as "potentially unsafe", and gave me further 
> instructions. They suggested using http://www.webimmune.net and/or 
> zipping it and password protecting it, using the password "infected".

Yes -- that is a tad more clue than seems reasonable to assume on the 
part of a "typical infected uswer"...

> I imagine I'm not the only one amused by the fact that they want you to 
> send malware to them in a password protected Zip file, (in light of 
> recent Bagle variants :).  ...

Actually, that has historically been a defensive measure to get samples 
_out_ from the sender's machine.  AV researchers started to receive too 
many messages that should have had suspicious attachments sent by 
helpful customers and the like but that had obviously had the 
attachments removed (or otherwise munged) by intermediary virus-
scanning gateways...

> ...  I also find it oddly amusing (being that I am 
> not a paying customer of theirs, and that only a few hundred or so 
> people on my campus likely are) that they would filter potentially 
> harmful attachments that were sent to a virus submission E-mail address.

Yes -- that is prize gormlessness...

> I'll have to tell the user to use our site licensed AV software instead 
> if they want to detect this threat in the future. (Actually, it is 
> probably still in my sent items, so I probably can comply with their 
> request. I'm just a bit perturbed that they acknowledged receipt of it, 
> then they deleted it. (Paying customers might want to take note that 
> they had their hands on something that a competitor identified as a 
> backdoor trojan, but NAI still cannot detect it because they filtered 
> E-mail sent via a virus submission address.)
> 
> Just thought I'd share my experience. Perhaps it will save someone else 
> the frustration that I had.

Indeed -- this is one of those near-comical things that you hope only 
happens to "the other guy".

I can imagine several "normal" administrative decision-making processes 
inside NAI (paralleling those of many other companies!) that make 
complete sense in light of recent developments regarding straight and 
password-protected .ZIP files, but which are quite ludicrous if you 
step back and realize that part of the business model underlying this 
company's moment-to-moment operation _requires_ that it be able to 
easily and efficiently receive (possibly) "undesirable" files from 
anyone, anywhere on the planet...


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Where to start

[Andrew Aris]

Hi,

Just want to say a big thanks to all who replied to me, both on and off
list. You've given me plenty to get me started!

cheers,

Andrew Aris

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Andrew Aris
> Sent: 09 March 2004 14:41
> To: [EMAIL PROTECTED]
> Subject: [Full-Disclosure] Where to start
> 
> Well I can speak up for one as someone who doens't have a 
> huge knowledge base. So I would also be most interested in 
> any sort of pointers on starting out as a security admin. I'm 
> not completely ignorant but it is only recently that I have 
> become responsible for security of more than a small home 
> network. (In this case a W2K3 web server and also the office 
> network). Much of background in security is theoretical 
> learnt during my postgrad year so real world info is what I'm after.
> 
> Apologies if the list wasnt the correct place for this post.
> 
> Regards,
> 
> Andrew
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf 
> Of Aschwin 
> > Wesselius
> > Sent: 09 March 2004 11:23
> > To: [EMAIL PROTECTED]
> > Subject: [Full-Disclosure] Where to start
> > 
> > Hello,
> > 
> > First appologies for having trouble doing something simple 
> as sending 
> > e-mail. Evolution is new for me...
> > 
> > Now I'm on this list, I think I could ask you people a question (or 
> > two)
> > 
> > Does a good security-officer have to know everything about 
> every hole? 
> > I myself don't think so, but where do people start?
> > 
> > If I see lists and forums about network-security it seems that 
> > everybody knows a lot and has a huge reference base. Is this true?
> > 
> > I want to learn more about security stuff, but I can't find 
> the real 
> > basics to build upon anywhere. When there are posts on lists they 
> > presume that everybody has a certain knowledge level and 
> are aware of 
> > best practices. But is this true?
> > 
> > Just because there are discussions, it seems that there is not one 
> > overall and central way of keeping track of evolving issues. How do 
> > people keep track easily with up to date best practices and not get 
> > distracted by "old" advisory?
> > 
> > Any comments are welcome.
> > 
> > Aschwin Wesselius
> > 
> > ___
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> > 
> > 
> 
> 
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 



___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html