RE: [Full-Disclosure] FD should block attachments

[Poof]

Yeah... I've got Dialup and don't see a problem with the attachments.

Heck. Emailing it to everybody rather than hosting the file(s) is better for
me as I dislike hosting files on my own webspace.

~

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:full-disclosure-
> [EMAIL PROTECTED] On Behalf Of Zach Forsyth
> Sent: Friday, April 02, 2004 12:33 AM
> To: Michael Gale; [EMAIL PROTECTED]
> Subject: RE: [Full-Disclosure] FD should block attachments
> 
> How much precious bandwidth is wasted by FD attachements exactly?
> Per month?
> Per year?
> 
> I am sure it is a staggering amount of data wasted :)
> 
> Who cares about the attachements even if they are a virus.
> Surely 99.9% of all FD readers are secured adequately and are smart
> enough not to open things they shouldn't.
> 
> z
> 
> > -Original Message-
> > From: Michael Gale [mailto:[EMAIL PROTECTED]
> > Sent: Friday, 2 April 2004 7:23 AM
> > To: [EMAIL PROTECTED]
> > Subject: [Full-Disclosure] FD should block attachments
> >
> > Hello,
> >
> > Being a member of this I do not mind the carrying on of
> > list members. I usually enjoy reading the banter and I do not
> > care about the "noise" ratio.
> >
> > What is annoying is the amount of viruses or waste of my
> > bandwidth attachments that come from this list.
> >
> > I think FD should change their policy and block all
> > attachments, except maybe plain text file's.
> >
> > Most people on this list are smart enough that exe's, zip and
> > pif attachments do not need to be send, I am tired of the excuses:
> >
> > I had a virus
> > I did not know what the file was
> > ...
> > ...
> >
> > FD should block attachments except for plain text. People can
> > post links to web pages or what ever that way only people who
> > want to see the attachment would get it, plus it would save
> > on your bandwidth.
> >
> > Michael.
> >
> > --
> > Hand over the Slackware CD's and back AWAY from the computer,
> > your geek rights have been revoked !!!
> >
> > Michael Gale
> > Slackware user :)
> > Bluesuperman.com
> >
> >
> > --
> > Hand over the Slackware CD's and back AWAY from the computer,
> > your geek rights have been revoked !!!
> >
> > Michael Gale
> > Slackware user :)
> > Bluesuperman.com
> >
> > ___
> > 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] Block notification / bounce mails (as in DDOS)

[Michael Gale]

Hello,

Well if the mail server was a postfix box properly configured on decent
hardware you should not be able to get DDOS. I have seem postfix servers
handle 10,000 messages an hour (166.6 messages a minute, 2.7 per
second), so the TCP connections from the remote servers will most happen
for 3days on average because the remote server(s) will most likely keep
trying to send the message. 

So "REJECTING" or "BOUNCING" them will not solve the problem, to solve
the problem and the messages can in no way be handled by the Exchange
server I would add a filter to DISCARD all messages from
"MAILER-DEAMON".

Since this is a bounced back message it will most likely be small in
size, so rejecting the mail or having your ISP block port 25 at the ISP
level is not going to solve the bandwidth problem.

Michael.


On Thu, 01 Apr 2004 16:05:51 +0200
Security <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> Recently, this question popped up during my job interview
> 
> 
> What would you do when a spammer uses your mail-address as the "From:"
> and the mails that are sent by the spammer get all bounced back by
> legitimated mail-servers to your mailhandlers? All the bounces would
> return to you - as you are the 'from' (assume a rate of 1.000 a
> minute) and this traffic would kill your network-connection. You
> wouldn't be able to receive any mail because your mailserver can no
> longer handle the load
> 
> I had a 'Dilbert' reaction in the sense that I couldn't come up with a
> decent answer (needless to say their impression indicated that I
> should not expect them to hire me). I could only offer these solutions
> :
> 
> * contact my ISP and search for a decent solution
> * put a notice on our corporate website and indicate that we are no
> longer available through mail on the old address but have a 'new'
> temporarily one* try to investigate, through the e-mail headers
> (allthough they could be fake), from where the original posts are
> coming and try to contact the isp of that netblock
> 
> What do you all suggest to this 'seemingly' DDOS-attack (allthough not
> 
> intended as a DOS)?
> 
> Greetings,
> 
> Koen
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


-- 
Hand over the Slackware CD's and back AWAY from the computer, your geek
rights have been revoked !!!

Michael Gale
Slackware user :)
Bluesuperman.com 

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

[Full-Disclosure] FD should block attachments

[Michael Gale]

Hello,

Being a member of this I do not mind the carrying on of list
members. I usually enjoy reading the banter and I do not care about the
"noise" ratio.

What is annoying is the amount of viruses or waste of my bandwidth
attachments that come from this list.

I think FD should change their policy and block all attachments, except
maybe plain text file's. 

Most people on this list are smart enough that exe's, zip and pif
attachments do not need to be send, I am tired of the excuses:

I had a virus
I did not know what the file was 
...
...

FD should block attachments except for plain text. People can post links
to web pages or what ever that way only people who want to see the
attachment would get it, plus it would save on your bandwidth.

Michael.

-- 
Hand over the Slackware CD's and back AWAY from the computer, your geek
rights have been revoked !!!

Michael Gale
Slackware user :)
Bluesuperman.com 

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

RE: [Full-Disclosure] Block notification / bounce mails (as in DDOS)

[Aditya, ALD [Aditya Lalit Deshmukh]]

   first off, the From: header would not normally be the one emails get 
> bounced to.  rather, it would be the "MAIL FROM" envelope header.  in 
> any case, my 'solution' would be to temporarily drop all mail destined 
> to this deluged account to /dev/null and set up a new account for the 

/dev/null will still consume all the network traffic

> busted user.  you could alternatively set up a "user relocated" reply on 
> the server or just kill the account altogether and send responses of "no 
> such local user".  you get the general idea.  not a great solution, but 

what you can do is when the connecting server issues a mail from: to your server just 
drop the mail, so your connection will start to open up and the all the bandwidth will 
still be free because the most bw consuming data part will never be passed to your 
server 

-aditya



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

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

[Full-Disclosure] Re: [Full-Disclosure] Thomas Scheller/DE/TNT/TPG ist außer Haus.

[riki]

is your house empty too?

Ich werde ab  02.04.2004 nicht im Büro sein. Ich kehre zurück am
13.04.2004.
Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Block notification / bounce mails (as in DDOS)

[Rainer Gerhards]

We have also worked around similar situations by setting up new postfix
boxes on a COLO facility. Thus, you direct the excess traffic to the
COLO (you should make sure your plan covers enough traffic allowance,
but this can nowadays purchased *very* inexpensively). Then, on the COLO
server, you configure a quite agressive postfix/spamassasin eventually
virus scanner. For the large bunch in question, configure postfix rules
that work on the envelope ... this is extremely efficient. When done,
change your MX to the colo box. Also make sure that your real mail
server only accepts traffic from the front end box. If you select a good
colo facility, it is hard to envision you will run out of bandwidth just
because of smtp bounce traffic, even when the number is very high.

A collague had a very similar situations where the scenario actually
happened to their low-powered home boxes at low-bandwitdh DSL
(768Donw/128Up) accounts. They received several 10.000 NDRs but the only
annoyance was to delete these, which obviously was done quickly by some
filtering.

Just my 2cts...

Rainer

> -Original Message-
> From: Security Administrator [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 01, 2004 8:44 PM
> To: Koen
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Full-Disclosure] Block notification / bounce 
> mails (as in DDOS)
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I'm not sure that saying the server is "dead" is a fair 
> question.  I mean
> if it's dead because of a hardware problem then why ask a security
> professional the question in the first place.  If on the 
> other hand it is
> dead due to the apparent "ddos" attack of incoming mail,  it should be
> possible to disconnect the box from the network,  restore it 
> and add in
> filtering capabilities which alleviate the issue, and then 
> put it back on
> the network.
> 
> One option, which has been used to great success under during 
> the serious
> outbreak of Sobig.F last year,  was to use Milter on sendmail.  Using
> Milter it is possible for a sendmail server to match via 
> regex on incoming
> headers on a new incoming message.  This matching can happen 
> as early as
> during the transmission of the envelope and as such can be 
> done in a way
> that the mail server drops the TCP connection before it ever 
> even commits
> the message to disk (the typical problem that actually "kills" a mail
> server in these circumstances is I/O overload).
> 
> I have seen a configuration like this,  along with sane sendmail
> configurations, recover a seemingly "dead" mail farm under 
> heavy attack
> from floods of virus mail in conjunction with bounce 
> notifications.  This
> attack was of such a magnitude that multiple sendmail 
> servers, each with
> the capability of handling upwards of a few hundred 
> simultaneous messages,
>  were brought to their knees.  While moving to the above configuration
> obviously didn't restore them to their previous operating 
> capacity,  it
> allowed mail to flow at a decent pace rather then standing still.
> 
> If however you have a problem with your network bandwidth 
> being absorbed
> by the incoming connections you would need additional 
> measures,  such as
> upstream filtering by inline devices capable of removing the 
> connection
> attempts before they traverse your WAN link.  There are 
> numerous devices
> that could be employed to alleviate the traffic, with the help of your
> ISP.
> 
> Joe
> 
> > Luke Norman wrote:
> >>>
> >>> What do you all suggest to this 'seemingly' DDOS-attack 
> (allthough not
> >>> intended as a DOS)?
> >>>
> >> Set up a server-side bayesian filter to block all e-mails 
> containing
> >> certain words (such as 'address not found' or similar). I'd be very
> >> suprised if there isn't a filter like this already available if you
> >> google it. Have a look at the 'fighting useless notification mails'
> >> thread from a few days ago, which is a related topic
> >
> > This would be an option if the mailserver is still capable 
> of handling all
> > or
> > some of the mail. As the question was raised, this is not 
> the case. The
> > 'theoratical' situation is that my mailserver is as dead as 
> a doornail
> > (not
> > really crashed but out of oxygen..network-bandwidth).
> >
> > Thanks anyway for the response (and yes, the thread on 
> fighting is
> > indeed
> > very helpful for the case where I have some 'spare' bandwidth)
> >
> > Koen
> >
> >
> >
> > ___
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> >
> 
> 
> - --
> - 
> --
> 
> Joe Saland, CISSP
> joe<|at|>saland<|dot|>us
> 
> Encrypted mail preferred
> - 
> GPG Key: gpg --keyserver pgp.mit.edu --recv-key 0x89A8BC38
> GPG Fingerprint: 5C45 4824 E2F1 AA58 FBDA E388 D9D9 A330 89A8 BC38
> - 
> 

[Full-Disclosure] Thomas Scheller/DE/TNT/TPG ist außer Haus.

[Thomas . Scheller]

Ich werde ab  02.04.2004 nicht im Büro sein. Ich kehre zurück am
13.04.2004.

Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

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

[Full-Disclosure] MondoSoft - Proxy through MsmHigh.exe

[Uffe Nielsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Topic: MondoSoft - Proxy through MsmHigh.exe
Application : MondoSearch versions prior to 5.1b
Author: Uffe Nielsen (uni at protego.dk)
Advisory URL: http://www.protego.dk/advisories/200401.html
Vendor Name: MondoSoft 
Vendor URL: http://www.mondosoft.com
Vendor contacted: 26. Mar. 2004
Public release: 2. Apr. 2004

Problem:
MondoSearch is web site search engine made by MondoSoft.

One of the files installed with the MondoSoft search engine can be used as a
proxy for web requests.

This means that an attacker can use the webserver, on which MondoSoft is
installed, as a proxy and thereby hide his identity, as requests will seem
to come from the vulnerable webserver.

Details:
The vulnerability occurs when the MsmHigh.exe is called with a specially
crafted querystring.

Impact:
This may allow an attacker hide his identity and relay requests through the
vulnerable webserver, thus making it look like the requests came from the
vulnerable server.

Depending on the firewall rules for the zone the vulnerable webserver is in,
an attacker may also be able to browse other webservers in the same zone or
on the internal LAN segment. 

Corrective actions:
MondoSoft has released a patch for this issue.
http://www.mondosoft.com/security 

Disclaimer:
The information within this document may change without notice. Use of this
information constitutes acceptance for use in an "AS IS" condition. There
are NO warranties with regard to this information. In no event shall PROTEGO
be liable for any consequences or damages, including direct, indirect,
incidental, consequential, loss of business profits or special damages,
arising out of or in connection with the use or spread of this information.
Any use of this information lies within the user's responsibility. All
registered and unregistered trademarks represented in this document are the
sole property of their respective owners. 
-BEGIN PGP SIGNATURE-
Version: PGP 8.0

iQA/AwUBQG1NTosM7mGVnEICEQKFaACfSuR+Gv57zNe5K+sbWIl7zDx1LuYAn1TT
Kbbsbhxh5mTZQWxSCAkn5FCI
=wFXS
-END PGP SIGNATURE-

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

[Full-Disclosure] MondoSoft - MsmHigh.exe - Denial of Service

[Uffe Nielsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Topic: MondoSoft - MsmHigh.exe - Denial of Service
Application : MondoSearch versions prior to 5.1b
Author: Dennis Rand (dra at protego.dk)
Advisory URL: http://www.protego.dk/advisories/200402.html
Vendor Name: MondoSoft 
Vendor URL: http://www.mondosoft.com
Vendor contacted: 26. Mar. 2004
Public release: 2. Apr. 2004

Problem:
MondoSearch is web site search engine made by MondoSoft.

One of the files installed with the MondoSoft search engine can be used
perform a Denial of Service attack on the vulnerable system, making the
webserver unable to serve other requests.

Details:
The vulnerability occurs when the MsmHigh.exe is called multiple times. The
MondoSoft software will load a new instance of the file each time it is
requested which will eventually consume all memory on the vulnerable system.

Impact:
The may allow an attacker to perform a Denial of Service attack. 

Corrective actions:
MondoSoft has released a patch for this issue.
http://www.mondosoft.com/security 

Disclaimer:
The information within this document may change without notice. Use of this
information constitutes acceptance for use in an "AS IS" condition. There
are NO warranties with regard to this information. In no event shall PROTEGO
be liable for any consequences or damages, including direct, indirect,
incidental, consequential, loss of business profits or special damages,
arising out of or in connection with the use or spread of this information.
Any use of this information lies within the user's responsibility. All
registered and unregistered trademarks represented in this document are the
sole property of their respective owners. 
-BEGIN PGP SIGNATURE-
Version: PGP 8.0

iQA/AwUBQG1NoIsM7mGVnEICEQJmowCgtvzMjWOh06wJDv1gPp8FHgya7J0Ani/A
oO8lrY2JJXFa6HoX2Tl1bBFF
=nBb9
-END PGP SIGNATURE-

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

Re: [Full-Disclosure] Re: [Full-Disclosure] Thomas Scheller/DE/TNT/TPG ist außer Haus.

[Seuli]

On Fri, 02 Apr 2004 11:40:44 +0200
riki <[EMAIL PROTECTED]> wrote:

> is your house empty too?

it might be, quite soon

> 
> > Ich werde ab  02.04.2004 nicht im Büro sein. Ich kehre zurück am
> > 13.04.2004.
> > 
> > Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.



-- 
fortune -o(ffensive)s(short):\n
I'm having a RELIGIOUS EXPERIENCE ... and I don't take any DRUGS

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

[Full-Disclosure] MondoSoft - MsmLink.exe - Denial of Service

[Uffe Nielsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Topic: MondoSoft - MsmLink.exe - Denial of Service
Application : MondoSearch versions prior to 5.1b
Author: Dennis Rand (dra at protego.dk)
Advisory URL: http://www.protego.dk/advisories/200403.html
Vendor Name: MondoSoft 
Vendor URL: http://www.mondosoft.com
Vendor contacted: 26. Mar. 2004
Public release: 2. Apr. 2004

Problem:
MondoSearch is web site search engine made by MondoSoft.

One of the files installed with the MondoSoft search engine can be used
perform a Denial of Service attack on the vulnerable system, making the
webserver unable to serve other requests.

Details:
The vulnerability occurs when the MsmLink.exe is called multiple times. The
MondoSoft software will load a new instance of the file each time it is
requested which will eventually consume all memory on the vulnerable system.

Impact:
The may allow an attacker to perform a Denial of Service attack. 

Corrective actions:
MondoSoft has released a patch for this issue.
http://www.mondosoft.com/security 

Disclaimer:
The information within this document may change without notice. Use of this
information constitutes acceptance for use in an "AS IS" condition. There
are NO warranties with regard to this information. In no event shall PROTEGO
be liable for any consequences or damages, including direct, indirect,
incidental, consequential, loss of business profits or special damages,
arising out of or in connection with the use or spread of this information.
Any use of this information lies within the user's responsibility. All
registered and unregistered trademarks represented in this document are the
sole property of their respective owners. 
-BEGIN PGP SIGNATURE-
Version: PGP 8.0

iQA/AwUBQG1cKosM7mGVnEICEQKR+gCbBDvV2k7IquFZOxptvdbhvrRrJa0An26m
y5iDvwnGIw7/4+RwZkt+rvoi
=o1KK
-END PGP SIGNATURE-

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

[Full-Disclosure] Buffer Overflow in HAHTsite Scenario Server 5.1

[Dennis Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

PROTEGO Security Advisory #PSA200405
Topic: Buffer Overflow in HAHTsite Scenario Server 5.1 
Platform: Windows, Solaris and Linux
Application: HAHTsite Scenario Server 5.1, Patch 1 to 6
Author: Dennis Rand (dra at protego.dk)
Advisory URL: http://www.protego.dk/advisories/20045.html
Vendor Name: HAHT Commerce
Vendor URL: http://www.haht.com
Vendor contacted: 12. Nov. 2003
Public release: 2. Apr. 2004

Explanation:
The HAHTsiteR Scenario Server is a highly flexible, standards-based
e-business server that offers essential platform features such as
scalability, high availability, security and extensibility. The Scenario
Server also offers essential integration features that provide a
powerful framework for your demand chain management environment. 

Problem:
The HAHTsite Scenario Server does not perform proper bounds check on
requests passed to the application. This results in a buffer overflow
condition, when a large specially crafted request is sent to the server.

Details:
The issue can be triggered by requesting:
http://[hostname]/[cgialias]/hsrun.exe/[ServerGroupName]/[ServerGroupNam
e]/[VeryLongProjectName].htx;start=[PageName]

This bug affects both background processes (regular server groups), and
control processes (the administrative server group). 

The following error will appear in the event viewer when this
vulnerablity is exploited:

- --
Event Type: Error 
Event Source: HAHTsite 5.1 Controller 
Event Category: None 
Event ID: 1032 
Description: 
Unexpected termination of server hsadmsrv with PID=: Exit Reason:
Unknown Reason 
- -- 

Impact:
A request like the above will overrun the allocated buffer and overwrite
EIP (Instruction Pointer), which leads to a service restart and the
possibility of remote code execution, giving an attacker the opportunity
to run commands on the server with permission of NT AUTHORITY\SYSTEM. 

PROTEGO has developed af Proof of Concept exploit that will make the
server return a command prompt with SYSTEM privileges, to an attacker.

Corrective actions:
This security vulnerability can be corrected by applying the server fix
[20030010] from www.haht.com/kb

For Windows:
ftp://ftp.haht.com/private/support/fixes/5.1/build91/ox79989_buffer_over
run_fix.zip

For Solaris:
Contact HAHT Technical Support at [EMAIL PROTECTED] 

For Linux:
Contact HAHT Technical Support at [EMAIL PROTECTED]

Disclaimer:
The information within this document may change without notice. Use of
this information constitutes acceptance for use in an "AS IS" condition.
There are NO warranties with regard to this information. In no event
shall PROTEGO be liable for any consequences or damages, including
direct, indirect, incidental, consequential, loss of business profits or
special damages, arising out of or in connection with the use or spread
of this information. Any use of this information lies within the user's
responsibility. All registered and unregistered trademarks represented
in this document are the sole property of their respective owners. 


-BEGIN PGP SIGNATURE-
Version: PGP 8.0

iQA/AwUBQG1mILlyfqEDqHg2EQJGqQCdFpUQ55mXXmKM2AHq7nH5OHA/QLQAn3jD
SusrDhhssjTdsgJOr7fZFTd6
=iTDN
-END PGP SIGNATURE-

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

[Full-Disclosure] MondoSoft - User enumeration possible

[Uffe Nielsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Topic: MondoSoft - User enumeration possible
Application : MondoSearch versions prior to 5.1b
Author: Uffe Nielsen (uni at protego.dk)
Advisory URL: http://www.protego.dk/advisories/200404.html
Vendor Name: MondoSoft 
Vendor URL: http://www.mondosoft.com
Vendor contacted: 26. Mar. 2004
Public release: 2. Apr. 2004

Problem:
MondoSearch is web site search engine made by MondoSoft.

It is possible to enumerate the usernames of users used to access the
MondoSoft administration site.

Details:
When the MsmChgPw.msk file is accessed with certain parameters, the
usernames that can access the MondoSoft administration site will be exposed.


Impact:
This may allow an attacker to focus a bruteforce attack on usernames that
are known to exist. 

Corrective actions:
MondoSoft has released a patch for this issue.
http://www.mondosoft.com/security 

Disclaimer:
The information within this document may change without notice. Use of this
information constitutes acceptance for use in an "AS IS" condition. There
are NO warranties with regard to this information. In no event shall PROTEGO
be liable for any consequences or damages, including direct, indirect,
incidental, consequential, loss of business profits or special damages,
arising out of or in connection with the use or spread of this information.
Any use of this information lies within the user's responsibility. All
registered and unregistered trademarks represented in this document are the
sole property of their respective owners. 
-BEGIN PGP SIGNATURE-
Version: PGP 8.0

iQA/AwUBQG1cj4sM7mGVnEICEQLGQgCg3Y44/GX/rVzQcDEpElG50xCj03kAn1cR
jEPrSzZ+3ZOsaB9ja8xJwdRC
=43gx
-END PGP SIGNATURE-

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

RE: [Full-Disclosure] Block notification / bounce mails (as in DDOS)

[Richard Gadsden]

Security  wrote on Thursday, 1 April 2004 3:06 p.m.:

> 
> What would you do when a spammer uses your mail-address as the
> "From:" and the mails that are sent by the spammer get all bounced
> back by legitimated mail-servers to your mailhandlers? All the
> bounces would return to you - as you are the 'from' (assume a rate of
> 1.000 a minute) and this traffic would kill your network-connection.
> You wouldn't be able to receive any mail because your mailserver can
> no longer handle the load 

If you can manage this, start breaking an RFC and throw out anything with
a MAIL FROM:<>

That should get rid of the bounces but not the annoyed replies from hostile users.
==
Cobbetts makes its debut in the Sunday Times "100 Best Companies to Work For 2004"
With an overall ranking of 12th place, this is the first time the firm has entered the 
100 Best Listings, 
which gauges employees' satisfaction.
For further details click here
http://www.cobbetts.co.uk/news63.html
==
Confidentiality Notice: The information contained in this e-mail 
is for the intended recipient(s) alone. It may contain privileged 
and confidential information that is exempt from disclosure under 
English law and if you are not an intended recipient, you must not
copy, distribute or take any action in reliance on it. If you have
received this e-mail in error, please notify us immediately either
by using the reply facility on your e-mail system or by contacting
us at the address below. If this message is being transmitted 
over the Internet, be aware that it may be intercepted by third 
parties. 

Cobbetts offices are at:
Ship Canal House, King Street, Manchester, M2 4WB,
England. 
Telephone: +44 161 833 ; Fax: +44 161 833 3030.

Trafalgar House, 29 Park Place, Leeds, LS1 2SP,
England.
Telephone: +44 113 246 8123; Fax +44 113 244 2863
www.cobbetts.co.uk

This firm is authorised by the FSA to conduct investment 
business.
=

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

RE: [Full-Disclosure] Block notification / bounce mails (as in DDOS)

[Jos Osborne]

Going back to the former discussion about signal<=>noise, the message I just got was a 
4 line post inside 51 lines total - 

11 lines of original post
4 lines of actual reply text
33 lines of corporate signatures
3 lines of FD signature.

And that was a "signal" post. 

Just a thought.

Jos

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

RE: [Full-Disclosure] FD should block attachments

[Paul Schmehl]

--On Friday, April 02, 2004 01:16:24 AM -0500 Poof <[EMAIL PROTECTED]> 
wrote:

Yeah... I've got Dialup and don't see a problem with the attachments.

Heck. Emailing it to everybody rather than hosting the file(s) is better
for me as I dislike hosting files on my own webspace.
How considerate of you.

Did you ever consider that people in some parts of the world pay by the 
byte or by the time they're online, and attachments, especially large ones 
*and* html email cost them money personally?

Not everyone in the world has the choices that some people assume are 
universally available.

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

[Full-Disclosure] Re: [FD] FD should block attachments

[Andrew J Caines]

Michael,

> I think FD should change their policy and block all attachments, except
> maybe plain text file's.

Since some folks presumably want to be able to send and receive the latest
MS innovations and other attachments, why don't you just block whatever
you don't want to receive? I certainly do.

The increasing trend of solving security problems by throwing out the
baby, bathtub and any bathroom fittings which can be torn off is
disturbing. It's much the same as the prevalence of the "There should be a
law against that!" culture.

This is certainly not to say SMTP is a good choice of file transfer
protocol, or that it's an efficient use of resources.


Perhaps a more friendly solution would be to have a per-user option to
have attachments (some or all types) stripped. I'm not sure it this is
something Mailman can easily do, but since it already has MIME-specific
handling for digest, I can't imagine it being too hard.


-Andrew-
-- 
 ___
| -Andrew J. Caines-   Unix Systems Engineer   [EMAIL PROTECTED]  |
| "They that can give up essential liberty to obtain a little temporary |
|  safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 |

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

Re: [Full-Disclosure] Block notification / bounce mails (as in DDOS)

[Valdis . Kletnieks]

On Fri, 02 Apr 2004 14:55:44 +0100, Richard Gadsden <[EMAIL PROTECTED]>  said:

> If you can manage this, start breaking an RFC and throw out anything with
> a MAIL FROM:<>

And remember to do the world a favor and un-do that change when the immediate
problem is past. :)

> That should get rid of the bounces but not the annoyed replies from hostile users.

> ==
> Cobbetts makes its debut in the Sunday Times "100 Best Companies to Work For 
2004"

> This firm is authorised by the FSA to conduct investment 
> business.
> =

Another good way to avoid annoyed replies is to not have disclaimers longer than
the actual posting.  My favorite:

"... if you are not an intended recipient, you must not copy, distribute or
take any action in reliance on it."

Do you have any legal citations to justify a "must" as opposed to a "pretty please
with sugar on it"?

"If this message is being transmitted over the Internet, be aware that it may
be intercepted by third parties."

http://www.openpgp.org/resources/downloads.shtml and pick something.  It's more
effective than a disclaimer.



pgp0.pgp
Description: PGP signature

RE: [Full-Disclosure] FD should block attachments

[Mike Smith]

>> Yeah... I've got Dialup and don't see a problem with the attachments.
>>
>> Heck. Emailing it to everybody rather than hosting the file(s) is
better
>> for me as I dislike hosting files on my own webspace.
>>
>How considerate of you.
>
>Did you ever consider that people in some parts of the world pay by the

>byte or by the time they're online, and attachments, especially large
ones 
>*and* html email cost them money personally?
>
>Not everyone in the world has the choices that some people assume are 
>universally available.
>


Ah, but they *DO* have a universally available choice  To not
subscribe to lists which include attachments.

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

Re: [Full-Disclosure] FD should block attachments

[Mike Klinke]

On Friday 02 April 2004 10:27, Tim wrote:
> > Did you ever consider that people in some parts of the world pay
> > by the byte or by the time they're online, and attachments,
> > especially large ones *and* html email cost them money
> > personally?
>
> I have to agree here.  There are some who would say that email was
> never intended as a means to transfer files.  It is a very impolite
> way of getting a group of people a file.  Sending a link, is much
> more considerate to the subscribers and to those hosting the list.
>
> I don't know if blocking all attachments is the answer here, since
> doing that would block many signatures, but perhaps it would be
> worthwhile to block all but a couple of mime types.
>
> tim

It shouldn't have to be an "all or nothing" solution.  If some 
enterprising sole simply re-distributed the raw list with 
attachments, html, silly corporate signatures, and what-not stripped 
I'd guess a fair percentage of the subscribers would move to the 
re-distributed list.  I can't imagine the current list "owners" would 
object but I've been known to be wrong in the past .

Regards,  Mike Klinke

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

Re: [Full-Disclosure] FD should block attachments

[Tim]

> Did you ever consider that people in some parts of the world pay by the 
> byte or by the time they're online, and attachments, especially large ones 
> *and* html email cost them money personally?

I have to agree here.  There are some who would say that email was never
intended as a means to transfer files.  It is a very impolite way of
getting a group of people a file.  Sending a link, is much more
considerate to the subscribers and to those hosting the list.

I don't know if blocking all attachments is the answer here, since doing
that would block many signatures, but perhaps it would be worthwhile to
block all but a couple of mime types.

tim

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

[Full-Disclosure] [SECURITY] [DSA 471-1] New interchange packages fix information leak

[debian-security-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 471-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
April 2nd, 2004 http://www.debian.org/security/faq
- --

Package: interchange
Vulnerability  : missing input sanitising
Problem-Type   : remote
Debian-specific: no
CVE ID : CAN-2004-0374

A vulnerability was discovered recently in Interchange, an e-commerce
and general HTTP database display system.  This vulnerability can be
exploited by an attacker to expose the content of arbitrary variables.
An attacker may learn SQL access information for your Interchange
application and use this information to read and manipulate sensitive
data.

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

For the unstable distribution (sid) this problem has been fixed in
version 5.0.1-1.

We recommend that you upgrade your interchange package.


Upgrade Instructions
- 

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

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

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

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


Debian GNU/Linux 3.0 alias woody
- 

  Source archives:


http://security.debian.org/pool/updates/main/i/interchange/interchange_4.8.3.20020306-1.woody.2.dsc
  Size/MD5 checksum:  841 94b0e9195fba3134ea48470348c4011a

http://security.debian.org/pool/updates/main/i/interchange/interchange_4.8.3.20020306-1.woody.2.diff.gz
  Size/MD5 checksum: 1033 3a26a6f4bf24dce7fc38a5a14e8c5f6d

http://security.debian.org/pool/updates/main/i/interchange/interchange_4.8.3.20020306.orig.tar.gz
  Size/MD5 checksum:  1858749 660c7e65732a052a81d2ae6e4c6ed2b5

  Architecture independent components:


http://security.debian.org/pool/updates/main/i/interchange/interchange-cat-foundation_4.8.3.20020306-1.woody.2_all.deb
  Size/MD5 checksum:   636148 6d026419d3b15190084c5132d1f23831

http://security.debian.org/pool/updates/main/i/interchange/interchange-ui_4.8.3.20020306-1.woody.2_all.deb
  Size/MD5 checksum:   443894 f92de9f0d14e3eec42e5aa026b0aebb0

  Alpha architecture:


http://security.debian.org/pool/updates/main/i/interchange/interchange_4.8.3.20020306-1.woody.2_alpha.deb
  Size/MD5 checksum:   856628 7cbe87e177b5301b8a4dc65a660b4cb7

http://security.debian.org/pool/updates/main/i/interchange/libapache-mod-interchange_4.8.3.20020306-1.woody.2_alpha.deb
  Size/MD5 checksum:13948 957f5459ba925c58bd8051f57a3a73e5

  ARM architecture:


http://security.debian.org/pool/updates/main/i/interchange/interchange_4.8.3.20020306-1.woody.2_arm.deb
  Size/MD5 checksum:   855318 d38304316bbe9ea7d4393cd239da5720

http://security.debian.org/pool/updates/main/i/interchange/libapache-mod-interchange_4.8.3.20020306-1.woody.2_arm.deb
  Size/MD5 checksum:13336 683949f1e2771a3820e7fe022939e0f6

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/i/interchange/interchange_4.8.3.20020306-1.woody.2_i386.deb
  Size/MD5 checksum:   854816 109adbb0c0b312266cbf40f61f069e66

http://security.debian.org/pool/updates/main/i/interchange/libapache-mod-interchange_4.8.3.20020306-1.woody.2_i386.deb
  Size/MD5 checksum:13290 e0beca510155188aee6fd844194df9c6

  Intel IA-64 architecture:


http://security.debian.org/pool/updates/main/i/interchange/interchange_4.8.3.20020306-1.woody.2_ia64.deb
  Size/MD5 checksum:   858690 0ab2a74ee31c14fa5d13b18cecffc511

http://security.debian.org/pool/updates/main/i/interchange/libapache-mod-interchange_4.8.3.20020306-1.woody.2_ia64.deb
  Size/MD5 checksum:15810 221b180c0ee922bb6b52bbfa18a9da45

  HP Precision architecture:


http://security.debian.org/pool/updates/main/i/interchange/interchange_4.8.3.20020306-1.woody.2_hppa.deb
  Size/MD5 checksum:   856400 e3d30cc487ddb668fb12e58a3015e233

http://security.debian.org/pool/updates/main/i/interchange/libapache-mod-interchange_4.8.3.20020306-1.woody.2_hppa.deb
  Size/MD5 checksum:14050 3b75f8a9a1c1cac6696b3d1a6b08f890

  Motorola 680x0 architecture:


http://security.debian.org/pool/updates/main/i/interchange/interchange_4.8.3.20020306-1.woody.2_m68k.deb
  Size/MD5 checksum:   855446 5cd7687a310f7f7d31c4ccc531f71728

http://security.debian.org/pool/updates/main/i/interchange/libapache-mod-interchange_4.8.3.20020306-1.woody.2_m68k.deb
  Size/MD5 checksum:13298 c7bcc8

[Full-Disclosure] MSN\Qwest ships DSL modem with "unconfigurable" firewall

[James Lay]

Hey all!

Real quick...just implemented a Cisco VPN concentrator here and lo and
behold certain users couldn't get in.  The concentrator is setup with the
standard UDP port 500.  All users BESIDES MSN\Qwest DSL users could get
right on.  After a few calls and some frustration, Qwest informed us that
the firewall on the DSL router they ship is "unconfigurable"...odd that it
allowed Windows VPN TCP port 1723 but not UDP 500.  I've also heard rumor
that certain online games wouldn't work either with these DSL modems.  Moral
of the Story:  Research your VPN solutions for server AND clients before
implementing ;-)

James Lay
Network Manager/Security Officer
AmeriBen Solutions/IEC Group
Semper Vigilans!!!

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

[Full-Disclosure] I wish to unsubscribe

[Randy Coggan]

 

 

Thanks,

Randy


 

Re: [Full-Disclosure] FD should block attachments

[Valdis . Kletnieks]

On Fri, 02 Apr 2004 08:27:18 PST, Tim <[EMAIL PROTECTED]>  said:

> I have to agree here.  There are some who would say that email was never
> intended as a means to transfer files.  It is a very impolite way of
> getting a group of people a file.  Sending a link, is much more
> considerate to the subscribers and to those hosting the list.

This will be more useful once there's a way to do all of the following:

1) Upload the file to a webserver (which Joe User often doesn't have)
2) Set permissions on the file so only the recipients can get it.
3) Figure out the resulting URL for inclusion in the mail.
4) Deal with removing the file after a week or so.
5) All the *other* cruft involved in that whole process.

In general, *not* something your Aunt Tillie can deal with.


pgp0.pgp
Description: PGP signature

[Full-Disclosure] Thomas Scheller/DE/TNT/TPG ist außer Haus.

[Thomas . Scheller]

Ich werde ab  02.04.2004 nicht im Büro sein. Ich kehre zurück am
13.04.2004.

Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

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

[Full-Disclosure] Odd SEARCH Requests

[badpack3t]

At least once per day I am receiving these odd SEARCH requests:

http://fux0r.phathookups.com/incoming/dumbshit-thinks-he-can-hax0r-2.txt
http://fux0r.phathookups.com/incoming/dumbshit-thinks-he-can-hax0r.txt

I posted links because the requests are huge.  If anyone else has seen
these requests, or might have any other info on it let me know.  It could
possibly be ASN.1 related, but not sure.  I tried the same request against
a fully patched windows 2003 box with ISS 6.0 running, but nothing
happened.

Thanks,

---
badpack3t
www.security-protocols.com
www.ihack.ms
---

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

RE: [Full-Disclosure] Protected message

[404]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Don't get your panties in a bunch, I know the virus spoofs. I was
mearly stating that I thougth it was funny that it seems to come from
malware...You guys really need to either lighten up or quit being so
full of yourself, fucking christ


- -Original Message-
From: Bill Royds [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 29, 2004 7:41 AM
To: [EMAIL PROTECTED]
Subject: RE: [Full-Disclosure] Protected message


If you know something about vulnerabilities, you would  know that the
from address in an email gives absolutely no indicator of the actual
sender. The mail that you talk about came from host

d57-41-116.home.cgocable.net::
  Another cable user like you from Quebec.
   

- -Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of 404
Sent: March 29, 2004 3:56 AM
To: [EMAIL PROTECTED]
Subject: RE: [Full-Disclosure] Protected message

 
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- - From malware.com at that =]

- - -Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 29, 2004 12:47 AM
To: Subject: [Full-Disclosure] Protected message


Here is the file.


In order to read the attach you have to use the following password: 

- -BEGIN PGP SIGNATURE-
Version: PGP 8.0

iQA/AwUBQGfkmx2Q53cabNakEQL9LwCgtVyRvBELr2MvEwPaijzh+sOvjoIAn03W
qEYGLnjHEDdTzOpAvrgHefVm
=Fsyq
- -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


-BEGIN PGP SIGNATURE-
Version: PGP 8.0

iQA/AwUBQG2vbMUNOVmPdc6jEQJMrwCeNIAefw4tUT/XsTmIFyKE4Kyd7rcAoJ+G
ctlZKTfVrTQ+7USwJIrYfbUt
=JGN2
-END PGP SIGNATURE-

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

[Full-Disclosure] FD should block attachments

[dickcox]

Either way you look at this somebody will bitch.  
1) The people that don't want to take the time to download attachments or filter their 
own mail.
2) The people who have to host the attachments on their own servers and use their own 
bandwidth.

So here's my question to anyone who has done number 2, how many hits did you get after 
you posted your link?

Either way I still think the best solution is filtering at the recepiant level.





quepasa.com :: free email, now with 10mb of space.

[Full-Disclosure] Training & Certifications

[Robert Repp]

I'm getting ready to launch a small business computer consultancy, and I'd 
like to be able to show some certifications in network security.

1. Who has the best network security training programs?

2. Whose network security certification is well-respected (I'm planning to 
hire some people, and this will be a consideration)?

Thanks,
Rob
_
Limited-time offer: Fast, reliable MSN 9 Dial-up Internet access FREE for 2 
months! 
http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361ave/direct/01/

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

RE: [despammed] [Full-Disclosure] Odd SEARCH Requests

[Levinson, Karl]

MS03-007 NTDLL vulnerability over WebDAV.  Probably Agobot / Gaobot /
Phatbot / Polybot Trojan variants scanning for vulnerable systems to infect.
Search google for "SEARCH-/\x90\x02" and you'll see more.  Previously
discussed here, at [EMAIL PROTECTED] and other places.

http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=SEARCH-%2F%5Cx90%5Cx0
2

Other strings seen include:

SEARCH /A...
SEARCH /±±±±±±...
SEARCH /\x90\x02±\x02± ... x90\x90"

http://securityresponse.symantec.com/avcenter/venc/data/w32.hllw.gaobot.jb.h
tml
http://archives.neohapsis.com/archives/sf/pentest/2003-03/0109.html
http://www.microsoft.com/technet/security/bulletin/MS03-007.mspx
http://thum.ath.cx/Apache/code.414


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of badpack3t
Sent: Friday, April 02, 2004 1:53 PM
To: [EMAIL PROTECTED]
Subject: [despammed] [Full-Disclosure] Odd SEARCH Requests


At least once per day I am receiving these odd SEARCH requests:

http://fux0r.phathookups.com/incoming/dumbshit-thinks-he-can-hax0r-2.txt
http://fux0r.phathookups.com/incoming/dumbshit-thinks-he-can-hax0r.txt

I posted links because the requests are huge.  If anyone else has seen these
requests, or might have any other info on it let me know.  It could possibly
be ASN.1 related, but not sure.  I tried the same request against a fully
patched windows 2003 box with ISS 6.0 running, but nothing happened.

Thanks,

---
badpack3t
www.security-protocols.com
www.ihack.ms

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

[Full-Disclosure] IRIX ftpd ftp_syslog issue with anonymous FTP

[SGI Security Coordinator]

-BEGIN PGP SIGNED MESSAGE-



  SGI Security Advisory

Title:  IRIX ftpd ftp_syslog issue with anonymous FTP
Number: 20040401-01-P
Date:   April 2, 2004
Reference:  SGI BUGs 893718 899364 909172
Fixed in:   Patches 5525 & 5547 for IRIX 6.5.20-6.5.23
__

SGI provides this information freely to the SGI user community for its
consideration, interpretation, implementation and use.   SGI recommends
that this information be acted upon as soon as possible.

SGI provides the information in this Security Advisory on an "AS-IS"
basis only, and disclaims all warranties with respect thereto, express,
implied or otherwise, including, without limitation, any warranty of
merchantability or fitness for a particular purpose.  In no event shall
SGI be liable for any loss of profits, loss of business, loss of data or

for any indirect, special, exemplary, incidental or consequential
damages
of any kind arising from your use of, failure to use or improper use of
any of the instructions or information in this Security Advisory.
_

- ---
- --- Issue Specifics ---
- ---

It has been reported thru various channel that there are several
security issues affecting ftpd on IRIX.

 * win2k -> irix ftpd hangs indefinitely on link failure (SGI BUG 893718)
 * ftpd DoS possible involving PORT mode (SGI BUG 899364)
 * ftpd's ftp_syslog() doesn't work with anonymous FTP   (SGI BUG 909172)

SGI has investigated the issue and recommends the following steps for
resolving this issue.  It is HIGHLY RECOMMENDED that these measures
be implemented on ALL vulnerable SGI systems.  This issue has been
corrected in future releases of IRIX.


- --
- --- Impact ---
- --

To determine the version of IRIX you are running, execute the following
command:

  # /bin/uname -R

That will return a result similar to the following:

  # 6.5 6.5.21f

The first number ("6.5") is the release name, the second ("6.5.21f" in
this case) is the extended release name.  The extended release name
is the "version" we refer to throughout this document.


- 
- --- Solution ---
- 

SGI has provided a series of patches for these vulnerabilities. Our
recommendation is to upgrade to IRIX 6.5.23, or install the appropriate
patches.

OS Version Vulnerable? Patch #  Other Actions
- -- --- ---  -
IRIX 3.xunknown Note 1
IRIX 4.xunknown Note 1
IRIX 5.xunknown Note 1
IRIX 6.0.x  unknown Note 1
IRIX 6.1unknown Note 1
IRIX 6.2unknown Note 1
IRIX 6.3unknown Note 1
IRIX 6.4unknown Note 1
IRIX 6.5unknown Note 1
IRIX 6.5.1  unknown Note 1
IRIX 6.5.2  unknown Note 1
IRIX 6.5.3  unknown Note 1
IRIX 6.5.4  unknown Note 1
IRIX 6.5.5  unknown Note 1
IRIX 6.5.6  unknown Note 1
IRIX 6.5.7  unknown Note 1
IRIX 6.5.8  unknown Note 1
IRIX 6.5.9  unknown Note 1
IRIX 6.5.10 unknown Note 1
IRIX 6.5.11 unknown Note 1
IRIX 6.5.12 unknown Note 1
IRIX 6.5.13 unknown Note 1
IRIX 6.5.14 unknown Note 1
IRIX 6.5.15 unknown Note 1
IRIX 6.5.16 unknown Note 1
IRIX 6.5.17 unknown Note 1
IRIX 6.5.18 unknown Note 1
IRIX 6.5.19 unknown Note 1
IRIX 6.5.20   yes   5547Notes 2 & 3
IRIX 6.5.21   yes   5547Notes 2 & 3
IRIX 6.5.22   yes   5525Notes 2 & 3
IRIX 6.5.23   yes   5525Notes 2 & 3

   NOTES

 1) This version of the IRIX operating system is not actively supported.
Upgrade to an actively supported IRIX operating system.
See http://support.sgi.com/ for more information.

 2) If you have not received an IRIX 6.5.X CD for IRIX 6.5, contact
your SGI Support Provider or URL: http://support.sgi.com/

 3) Install the required patch(es) based on your operating release.


# Patch File Checksums 

The actual patch will be a tar file containing the following files:

Filename: README.patch.5525
Algorithm #1 (sum -r):06398 8 README.patch.5525
Algorithm #2 

[Full-Disclosure] MS code leak update?

[rnerrath]

has anyone heard anything else about the win2k and nt code leak? it seemed
to be hot news for a while and now there is nothing. was anyone fingered
in it?



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

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

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

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

Re: [Full-Disclosure] FD should block attachments

[Tim]

> attachments, html, silly corporate signatures, and what-not stripped 
 ^^

I wasn't talking about that kind of signature.  I was talking about
PGP/SMIME detached signatures. (eg, exist in attachments).

tim

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

Re: [Full-Disclosure] FD should block attachments

[Gregory A. Gilliss]

First, Aunt Tillie ought not to be sending files around the Internet, 
IMHO. But we've already lost *that* battle, so ...

Basically, attachments in SMTP sux0r. File Transfer Protocol (which no 
one should use since it's insecure) was designed for ... transferring 
files. SMTP was not - go ask Eric Allman, he'll know. However other 
protocols will do (HTTP works, although blocking sux0rz). SSH comes to 
mind (unless Microsoft has co-opted *that* too).

Why not help Aunt Tillie install WinSCP? No more need for server access or
perms or disk quotas (cuz it goes from her craptacular Winbloz box to 
someone elses' craptacular Winbloz box) *and* it's secure (or as secure 
as anything running on a Winbloz box can be these days).

If we list members are as Godlike as we pretend to be we'd declare a 
national holiday and send out one final SMTP attachment to wall the Aunt 
Tillies (and Uncle Leos) of the world with WinSCP and a link to some nice,
clear, screen-shot-laden instructions on how to install and configure it.

Oh, of course they'll all need static IPs, which will make beaucoup $$$ 
for decent ISPs and will help get rid of crappy dynamic PPPoE DSL and
dial-up providers thank heaven. Another nice side benefit, the RIAA can go
hang trying to catch all the *secure* file transfers of mp3 ph1l3z

Now someone go write a GPL WinSSHD so that they'll be able to *receive* 
the miserable ph1l3z they'll spew back and forth 8-)

G

On or about 2004.04.02 13:27:19 +, [EMAIL PROTECTED] ([EMAIL PROTECTED]) said:

> This will be more useful once there's a way to do all of the following:
> 
> 1) Upload the file to a webserver (which Joe User often doesn't have)
> 2) Set permissions on the file so only the recipients can get it.
> 3) Figure out the resulting URL for inclusion in the mail.
> 4) Deal with removing the file after a week or so.
> 5) All the *other* cruft involved in that whole process.
> 
> In general, *not* something your Aunt Tillie can deal with.

-- 
Gregory A. Gilliss, CISSP  E-mail: [EMAIL PROTECTED]
Computer Security WWW: http://www.gilliss.com/greg/
PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3

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

Re: [Full-Disclosure] FD should block attachments

[Paul Schmehl]

--On Friday, April 02, 2004 01:27:19 PM -0500 [EMAIL PROTECTED] wrote:
1) Upload the file to a webserver (which Joe User often doesn't have)
2) Set permissions on the file so only the recipients can get it.
3) Figure out the resulting URL for inclusion in the mail.
4) Deal with removing the file after a week or so.
5) All the *other* cruft involved in that whole process.
In general, *not* something your Aunt Tillie can deal with.
What do you want to bet that the people who actually have something 
*useful* to send to the list have websites they can put it on or ftp sites 
and can provide the url to those who want to obtain the sample?

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

[Full-Disclosure] Re: Odd SEARCH Requests

[borg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> I posted links because the requests are huge.  If anyone else has seen
> these requests, or might have any other info on it let me know.  It

> could possibly be ASN.1 related, but not sure.  I tried the same
  > request against a fully patched windows 2003 box with ISS 6.0
> running, but nothing happened

I get these requests probably 6-10 times a day to my apache server. One
of the ASN exploits floating around typically looks like this
("192.168.0.119 - - [02/Apr/2004:09:22:57 -0500] "\x16\x03" 501 - "-"
"-"")  in your apache logs, however that exploit generally isnt directed
at a webserver because its netbios related exploit. So im not entirely
sure it has anything to do with ASN. I must admit im a bit behind on
MS exploits and vulns, i honestly dont care for that OS world. If memory
serves me correctly, it might be a variation of the webdav exploit. Hope
this helps.

borg (ChrisR-) www.cr-secure.net
-BEGIN PGP SIGNATURE-
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.3

wkYEARECAAYFAkBt62kACgkQexF3vQr1Fl+bRwCfdQBLz7fRqhxJq79djA/COrSP+WcA
nRhhXFY/CFHvetzFF4u5YZKH+oH5
=RCc9
-END PGP SIGNATURE-




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

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

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

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

Re: [Full-Disclosure] FD should block attachments

[Tim]

> This will be more useful once there's a way to do all of the following:
> 
> 1) Upload the file to a webserver (which Joe User often doesn't have)

Granted, some people don't have good access to web hosting resources.

> 2) Set permissions on the file so only the recipients can get it.

This is a public list, with public archives.  This isn't a consideration.

> 3) Figure out the resulting URL for inclusion in the mail.

If you know how to put content on a webserver, this isn't really a hurdle.

> 4) Deal with removing the file after a week or so.

Why?  

> 5) All the *other* cruft involved in that whole process.

Not sure what you mean by this.


I don't disagree that it can be difficult for some, but I doubt there
are that many Aunt Tillies on this list.  Perhaps some of the Security
Focus lists, but full-disclosure?  Aunt Tillie would last about 24 hrs
on this list before unsubscribing due to the shear volume of crap here.
Including the administrivia we are now discussing. ;-)

tim

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

Re: [Full-Disclosure] Training & Certifications

[Exibar]

Without the experience behind the cert, any and all certs aren't even worth
the paper they're printed on.  With that said, the most notable Security
cert would have to be CISSP.  After that, take your pick of GIAC certs,
CISCO certs help as well even if they are not directly security related.

   Exibar

- Original Message - 
From: "Robert Repp" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 02, 2004 2:22 PM
Subject: [Full-Disclosure] Training & Certifications


> I'm getting ready to launch a small business computer consultancy, and I'd
> like to be able to show some certifications in network security.
>
> 1. Who has the best network security training programs?
>
> 2. Whose network security certification is well-respected (I'm planning to
> hire some people, and this will be a consideration)?
>
> Thanks,
> Rob
>
> _
> Limited-time offer: Fast, reliable MSN 9 Dial-up Internet access FREE for
2
> months!
>
http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361ave/direct/01/
>
> ___
> 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] Training & Certifications

[Harlan Carvey]

> Without the experience behind the cert, any and all
> certs aren't even worth the paper they're printed
on.  

This is true, and I couldn't agree more.  However, the
thing about certs is that they have to be measureable
and repeatable...which, when one becomes popular, very
quickly leads to bootcamps, etc.  There a lot of folks
w/ the necessary experience...but even that doesn't
make a "qualified" security professional.

> With that said, the most notable Security
> cert would have to be CISSP.  

The CISSP may be useful for Robert's upper-level
folks, but it's really more of a management level
cert.  For what Robert seems to want to do, I wouldn't
think that any certs would be necessary...after all,
are small businesses really going to want to pay the
higher price for folks w/ high-level certs?  

Robert, saying you want to set up a security
consultancy for small businesses, what kind of
services do you plan to offer?  Maybe that would help
your decision regarding certifications.  It might be
advisable to look for folks w/ MCSEs, Red Hat
cert...whatever os's you're going to support.  

Hope that helps a bit...

Harlan

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

gpl winsshd, was RE: [Full-Disclosure] FD should block attachments

[Stephen Blass]

>> Now someone go write a GPL WinSSHD so that they'll be able to *receive* 
the miserable ph1l3z they'll spew back and forth 8-)

The sshd in the openssh port for windows from http://lexa.mckenna.edu/sshwindows/  
works.   

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

[Full-Disclosure] Re: Advisory 03/2004: Multiple (13) Ethereal remote overflows

[Bob Niederman]

Does amyone know if the libsafe library
( http://www.research.avayalabs.com/project/libsafe/ ) protects from these
issues?

Thanks.

Note: My mail server bit-buckets mail to this address which is not from
securityfocus.com servers.  To email me, send to bob AT bob-n DOT com



On Tue, 23 Mar 2004, Stefan Esser wrote:

>e-matters GmbH
>   www.e-matters.de
> 
>   -= Security  Advisory =-
> 
> 
> 
>  Advisory: Multiple (13) Ethereal remote overflows
>  Release Date: 2004/03/23
> Last Modified: 2004/03/23
>Author: Stefan Esser [EMAIL PROTECTED]
> 
>   Application: Ethereal 0.8.14 - 0.10.2
>  Severity: 13 remotely triggerable vulnerabilities were 
>discovered in the multiprotocol packet sniffer 
>Ethereal that allow remote compromise
>  Risk: Critical
> Vendor Status: Plans to release a fixed version within this week
> Reference: http://security.e-matters.de/advisories/032004.html
> 


---
My mail server bit-buckets mail to this address which is not from securityfocus.com 
servers.  To email me, send to
bob AT bob-n DOT com


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

Re: [Full-Disclosure] Re: [FD] FD should block attachments

[morning_wood]

> Since some folks presumably want to be able to send and receive the latest
> MS innovations and other attachments, why don't you just block whatever
> you don't want to receive? I certainly do.
> 

yes, exactly why is this concept so hard to get?
im presuming that the majority of complaintants
are either not very security minded to begin with,
or are complete n00bs ( joned the list cuz they
saw it was on CNN ). i like attatchments, whether
they are PoC, viri, worm, pdf, etc etc. i like the choice
to choose.
btw: i use Microsoft products [OE] to post to this list,
and have never got any "virus or worm" or anything
else i didnt want. and i do not run any AV nor filtering
nor firwall to this box. 
am i missing something here?
 because i realy do not see the issue.

morning_wood
http://exploitlabs.com 

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

[Full-Disclosure] IRIX Update Some Network Drivers May Leak Data

[SGI Security Coordinator]

-BEGIN PGP SIGNED MESSAGE-

__
   SGI Security Advisory

  Title: Some Network Drivers May Leak Data
  Number   : 20030601-01-I
  Date : April 2, 2004
  Reference: CERT Vulnerability Note VU#412115
  Reference: CVE CAN-2003-0001
  Reference: SGI BUG 878043
__

SGI provides this information freely to the SGI user community for its
consideration, interpretation, implementation and use.  SGI recommends that
this information be acted upon as soon as possible.

SGI provides the information in this Security Advisory on an "AS-IS" basis
only, and disclaims all warranties with respect thereto, express, implied
or otherwise, including, without limitation, any warranty of merchantability
or fitness for a particular purpose.  In no event shall SGI be liable for
any loss of profits, loss of business, loss of data or for any indirect,
special, exemplary, incidental or consequential damages of any kind arising
from your use of, failure to use or improper use of any of the instructions
or information in this Security Advisory.
__

- --
- --- Update ---
- --

This is an update to SGI Security Advisory 20030601-01-A:
ftp://patches.sgi.com/support/free/security/advisories/20030601-01-A

AtStake and CERT reported a network device driver vulnerability
called EtherLeak:

 http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf
 http://www.kb.cert.org/vuls/id/412115
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0001

The gXX and tgXX gigabit network interfaces, and efXX network interface on
SGI systems are not vulnerable to this issue.

However, older SGI network interfaces are potentially vulnerable, but
they are in legacy support mode with no new fixes/patches provided.

To find out which network interfaces you have installed, run:
 % hinv -c network
 Fast Ethernet: ef1, version 1, module 2, slot io1, pci 2
 Integral Fast Ethernet: ef0, version 1, module 1, slot io1, pci 2

In the above example, both interfaces are efXX NICs and are not
vulnerable to the EtherLeak security issue.

- -
- --- SGI Security Information/Contacts ---
- -

If there are questions about this document, email can be sent to
[EMAIL PROTECTED]

  --oOo--

SGI provides security information and patches for use by the entire SGI
community.  This information is freely available to any person needing the
information and is available via anonymous FTP and the Web.

The primary SGI anonymous FTP site for security advisories and patches is
patches.sgi.com.  Security advisories and patches are located under the URL
ftp://patches.sgi.com/support/free/security/

The SGI Security Headquarters Web page is accessible at the URL
http://www.sgi.com/support/security/

For issues with the patches on the FTP sites, email can be sent to
[EMAIL PROTECTED]

For assistance obtaining or working with security patches, please contact
your SGI support provider.

  --oOo--

SGI provides a free security mailing list service called wiretap and
encourages interested parties to self-subscribe to receive (via email) all
SGI Security Advisories when they are released. Subscribing to the mailing
list can be done via the Web
(http://www.sgi.com/support/security/wiretap.html) or by sending email to
SGI as outlined below.

% mail [EMAIL PROTECTED]
subscribe wiretap 
end
^d

In the example above,  is the email address that you wish
the mailing list information sent to.  The word end must be on a separate
line to indicate the end of the body of the message. The control-d (^d) is
used to indicate to the mail program that you are finished composing the
mail message.


  --oOo--

SGI provides a comprehensive customer World Wide Web site. This site is
located at http://www.sgi.com/support/security/ .

  --oOo--

For reporting *NEW* SGI security issues, email can be sent to
[EMAIL PROTECTED] or contact your SGI support provider.  A support
contract is not required for submitting a security report.
__
  This information is provided freely to all interested parties
  and may be redistributed provided that it is not altered in any
  way, SGI is appropriately credited and the document retains and
  includes its valid PGP signature.

-BEGIN PGP SIGNATURE-
Version: 2.6.2

iQCVAwUBQG3nJ7Q4cFApAP75AQEdAAP/Xy6DTg8QP0j+KKaEyI50JlAcKln4NQ8a
/RSHcG3LBm1wTKVyfexj1t94MQbEI3K27KOhnMisBka3vmue709ZhB+29w+/K+iy
B9OBjTMrtX3S6xJvQm/nc8iHM2V6kUp4jo1+J1BP1MNjQaVl2B0pSfdBdsRM9Puy
a/F96+7fgYg=
=4VLh
-END PGP SIGNATU

Re: [Full-Disclosure] FD should block attachments

[John Sage]

I found the irony of the following too rich to pass up, given the
subject matter of this thread :-/


/* snip */
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110])
by +mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041);
 Fri, 2 Apr 2004 09:53:01 -0800
Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com
(InterScan+E-Mail VirusWall NT); Fri, 02 Apr 2004 09:51:13 -0800
Received: from RED-MSG-30.redmond.corp.microsoft.com ([157.54.47.230])
by +inet-hub-04.redmond.corp.microsoft.com with Microsoft
SMTPSVC(6.0.3790.0);
 Fri, 2 Apr 2004 09:51:31 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0
Content-class: urn:content-classes:message
/* snip */
From: "Randy Coggan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [Full-Disclosure] I wish to unsubscribe
Date: Fri, 2 Apr 2004 09:51:13 -0800

[-- Attachment #1 --]
[-- Type: multipart/alternative, Encoding: 7bit, Size: 2.2K --]
Content-Type: multipart/alternative;
boundary="_=_NextPart_001_01C418DB.1488A3AD"
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks,
Randy



http://www.w3.org/TR/REC-html40";>









 
 
Tha
nks,

Randy


 







- John
-- 
"Mad cow? You'd be mad too, if someone was trying to eat you."

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

Re: [Full-Disclosure] Re: [FD] FD should block attachments

[Luke Norman]

am i missing something here?
because i realy do not see the issue.
Yes, you are
As far as I can see from the numerous postings on the list, the issue 
isn't really recieving virii or anything else, it's the wasted 
time/bandwidth etc etc that comes from attatchments, and the costs that 
places on users who pay by the minute or by the megabyte. I personally 
don't think attatchments should be stopped, but I believe that's the 
argument for their filtering?
Luke

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

Re: [Full-Disclosure] Training & Certifications

[Robert Repp]

Harlan,

What we're doing is porting customers from consultancy by one person to a 
new, larger business owned by that person as a growth move. We're 
"inheriting" three small (~150 seat) corporations and a handful of small 
(~5-25 seat) office businesses. Almost every customer has had some issue 
with either trojans, hacking attempts, or DoS. As we go through the sales 
process, we're being asked often about all of these.

As a salesman, I'd like to be able to point out a credible authority whose 
training informs our work. As a technician, I'm interested in making sure 
our team can get actually useful training. I agree that the right people and 
skillset is much more important than simply having the right certs on the 
lobby wall. Side question: Is there a reliable test you favor when 
interviewing new techs about network administration?

This list seemed like the place to ask about widely respected security 
authorities, since anything obviously fake or useless tends to be quickly 
engulfed in flames.

Thanks,
Rob

From: Harlan Carvey <[EMAIL PROTECTED]>
To: Exibar <[EMAIL PROTECTED]>, Robert Repp <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] Training & Certifications
Date: Fri, 2 Apr 2004 13:31:29 -0800 (PST)
> Without the experience behind the cert, any and all
> certs aren't even worth the paper they're printed
on.
This is true, and I couldn't agree more.  However, the
thing about certs is that they have to be measureable
and repeatable...which, when one becomes popular, very
quickly leads to bootcamps, etc.  There a lot of folks
w/ the necessary experience...but even that doesn't
make a "qualified" security professional.
> With that said, the most notable Security
> cert would have to be CISSP.
The CISSP may be useful for Robert's upper-level
folks, but it's really more of a management level
cert.  For what Robert seems to want to do, I wouldn't
think that any certs would be necessary...after all,
are small businesses really going to want to pay the
higher price for folks w/ high-level certs?
Robert, saying you want to set up a security
consultancy for small businesses, what kind of
services do you plan to offer?  Maybe that would help
your decision regarding certifications.  It might be
advisable to look for folks w/ MCSEs, Red Hat
cert...whatever os's you're going to support.
Hope that helps a bit...

Harlan

_
Persistent heartburn? Check out Digestive Health & Wellness for information 
and advice. http://gerd.msn.com/default.asp

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

RE: [Full-Disclosure] Re: [FD] FD should block attachments

[Schmehl, Paul L]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> morning_wood
> Sent: Friday, April 02, 2004 4:33 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Full-Disclosure] Re: [FD] FD should block attachments
> 
> am i missing something here?
>  because i realy do not see the issue.
>
Yes, you are.  As I pointed out earlier, for some people who subscribe
to FD, it's a cost issue.  They pay by the byte or by the amount of time
they're online, and attachments *cost* them money.  If people provided
URLS and an explanation of the file, then those folks for whom this is a
cost issue could decide *before* they are forced to download the file
(by simply checking their mail), whether or not they actually wanted a
copy.  The suggestion to not subscribe to the list if you're in that
position was a rather ill-considered one, if you ask me.  This shouldn't
be an either or choice for them.

Now *that* doesn't seem too hard to understand, to me, but unfortunately
far too many of US are spoiled, with high bandwidth connections that
don't add any additional cost for downloading large files so we're
blinded to other people's dilemmas.

I personally could care less if the attachments or sent to the list or
not, but I *do* think one ought to at least *consider* the fact that
it's a cost issue for some folks.  And I'm willing to bet that most of
those folks are smart enough that they don't really need our help
figuring out whether a file is safe to download or not (or how to
download it safely if you want to put it that way.)

It would certainly rid the list of the irritation factor for those
people who get "surprised" by the attachments and then flood the list
with complaints.  (Yes, I know all about filtering, yada, yada, yada.
This isn't about *me*.)
 
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] FD should block attachments

[Niek Baakman]

Paul Schmehl wrote:

--On Friday, April 02, 2004 01:16:24 AM -0500 Poof 
<[EMAIL PROTECTED]> wrote:

Yeah... I've got Dialup and don't see a problem with the attachments.

Heck. Emailing it to everybody rather than hosting the file(s) is better
for me as I dislike hosting files on my own webspace.
How considerate of you.

Did you ever consider that people in some parts of the world pay by the 
byte or by the time they're online, and attachments, especially large 
ones *and* html email cost them money personally?

Not everyone in the world has the choices that some people assume are 
universally available.
They have the choice not to sign up, and read the FD archives instead.
If you can't deal with the noise/virii/ect/ect that comes with an
unmoderated list, unsubscribe right now!
--

The greatest trick the devil ever pulled was convincing the world he didn't exist.
PGP KeyID: 0x65C28B9A   |Fingerprint: 7A5301026E58CF3FACE7F2F0D82B854565C28B9A


signature.asc
Description: OpenPGP digital signature

Re: [Full-Disclosure] FD should block attachments

[Michael Cecil]

At 06:30 PM 4/2/2004, Niek Baakman said:

>They have the choice not to sign up, and read the FD archives instead.
>If you can't deal with the noise/virii/ect/ect that comes with an
>unmoderated list, unsubscribe right now!
Perhaps they do not want to wait to read new messages.  This is a mailing 
list, right?  That should mean people exchange text emails, not html, not 
binaries, not pictures, etc.  People who want to exchange these non-mail 
items should unsubscribe and go join an alt.binaries.* group "right now!"
--
Michael Cecil
[EMAIL PROTECTED]
http://home.comcast.net/~macecil/howto/
http://home.comcast.net/~antiviruscd/

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

Re: [Full-Disclosure] FD should block attachments

[Paul Schmehl]

--On Saturday, April 3, 2004 2:30 AM +0200 Niek Baakman 
<[EMAIL PROTECTED]> wrote:
They have the choice not to sign up, and read the FD archives instead.
If you can't deal with the noise/virii/ect/ect that comes with an
unmoderated list, unsubscribe right now!
You're the second person that has suggested this.  I'm amazed by the 
insensitivity.  If the shoe was on the other foot, would you be content to 
peruse the archives?

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

[Full-Disclosure] Thomas Scheller/DE/TNT/TPG ist außer Haus.

[Thomas . Scheller]

Ich werde ab  02.04.2004 nicht im Büro sein. Ich kehre zurück am
13.04.2004.

Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

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

RE: [Full-Disclosure] FD should block attachments

[Aditya, ALD [Aditya Lalit Deshmukh]]

> I think FD should change their policy and block all attachments, except
> maybe plain text file's. 

i second this if someone wants to send binary data / attachment use BHX or UUE or XXE 
encoding 
copied in the main message... like this text

 
> Most people on this list are smart enough that exe's, zip and pif
> attachments do not need to be send, I am tired of the excuses:


so are most people able to decode this kind of stuff and get back the binary data if 
required  





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

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

RE: [Full-Disclosure] FD should block attachments

[Poof]

Personally... I do think that attachments shouldn't be blocked. I'm on dialup 
myself and have no problem with them... I joined this list knowing that 
there'd be attachments and for a list of this volume (Not much usually) it's 
not a big deal.

If you want a list that doesn't give attachments join one of the moderated 
bugtraq lists. I'm sure you'll enjoy it there anyhow...

Further... A virus email is an avg of 25K ish... Meanwhile a non-clipped email 
(Other emails tagged to the bottom/etc) are 15+KB. That's only 10 more KB 
added to an email(Adds maybe 2 seconds to my downloading time. And that's if 
I'm not using a compressed dialup connection. Otherwise... 1 second to 
download that... Same as any other email.).  "Big deal" I think... There 
aren't many virus sends daily/weekly either.

~

> You're the second person that has suggested this.  I'm amazed by the
> insensitivity.  If the shoe was on the other foot, would you be content to
> peruse the archives?


smime.p7s
Description: S/MIME cryptographic signature

Re: [Full-Disclosure] FD should block attachments

[petard]

On Fri, Apr 02, 2004 at 09:41:01AM -0600, Paul Schmehl wrote:
> --On Friday, April 02, 2004 01:16:24 AM -0500 Poof <[EMAIL PROTECTED]> 
> wrote:
> 
> >Yeah... I've got Dialup and don't see a problem with the attachments.
> >
> >Heck. Emailing it to everybody rather than hosting the file(s) is better
> >for me as I dislike hosting files on my own webspace.
> >
> How considerate of you.
> 
> Did you ever consider that people in some parts of the world pay by the 
> byte or by the time they're online, and attachments, especially large ones 
> *and* html email cost them money personally?

and they'd do well to sign up for kurt's edited version... all the
security, none of the crap:
http://lists.seifried.org/mailman/listinfo/security

hth,

petard

--
If your message really might be confidential, download my PGP key here:
http://petard.freeshell.org/petard.asc
and encrypt it. Otherwise, save bandwidth and lose the disclaimer.

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