[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <039d01c3662d$a93db1a0$452618ac@BECQW480>
From: simon.thornton at swift.com (Simon Thornton)
Subject: Administrivia: Binary Executables w/o Source
Hi Len,
LR> don't send binary executables on the list
LR> unless you include the source code. We should add
LR> this to the charter shortly.
I can understand your reasoning but I think this is a little extreme,
the value of this list is the (relatively) unrestricted flow of info.
Sometimes the binaries maybe of interest, as long as they are not very
large. A classic example would be output from tcpdump for a new trojan,
very useful when writing SNORT sigs.
What would be useful is if people put binaries in password protected
ZIP/RAR etc and put the password in the message, this would stop AV s/w
(or similar) removing the attachments as "infected". It also means that
the reader has to consciously open the attachment.
As with any binary you take a risk; caveat emptor, it is how you
assess/mitigate/deal with the risk which determines whether you will
open unidentified executables. Sometimes the risk is worth it.
If you really must put a limit, prevent attachments greater in size than
say 200K, anything else should use a link to a website/ftp server for
distribution.
Just my two euro cents worth ..... :-)
Rgds,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3043 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030819/92417ef5/smime.bin
Powered by blists - more mailing lists