From: Gianni Tedesco <gianni@ecsc.co.uk>
To: Peter Surda <shurdeek@panorama.sth.ac.at>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: Idea: string replace
Date: 02 Oct 2002 14:44:50 +0100 [thread overview]
Message-ID: <1033566290.27036.116.camel@lemsip> (raw)
In-Reply-To: <20021001233327.GF22145@noir.cb.ac.at>
[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]
On Wed, 2002-10-02 at 00:33, Peter Surda wrote:
> On Tue, Oct 01, 2002 at 11:06:50PM +0200, Peter Surda wrote:
> > > Regarding the "is it difficult" question, that depends on whether you
> > > want to replace with a string of identical length (piece of cake),
> > Actually, I didn't think so far as to use different lengths, somehow I
> > subconsiously assumed it is far from easy. Again, I only need this for a very
> > specific purpose (disabling one virus), for which IMHO same-length-replace is
> > sufficient.
> Ok, so I tried, I tried really hard <g>, and it compiled, and it didn't crash,
> and it seems to behave as expected (the virus attachment arrives or is
> downloaded, but is artifically corrupt and doesn't work). Attached patches
> (one userspace and one kernel) against cvs from end of July.
>
> The string match has a new option, --replace-with, that takes one string as a
> value. I think the code is straightforward, the checksumming stuff is pasted
> from nat_helper.c (but it doesn't do conntrack of course).
Cool, I'm pretty sure you could pre-compute the checksum differences in
userspace and pass them in the info struct that would save dirtying lots
of CPU caches *too* much. :]
> Please test and report :-). I am sure there are more cool ways to use it than
> fighting virii.
Everyone here knows the problem of this approach for virus killing. To
do it right you need to wory about if the virus straddles two packets,
is radix 64 encoded, is using HTTP gzip ecoding, is using SMTP TLS,
never mind the various ptacek/newsham style attacks for TCP etc etc...
That said, I'm sure this will catch 99% of all viruses because they
probably wont straddle two packets, they certainly aren't deliberatly
evasive and they are usually sent via mail APIs which allow little
control that would let you do most of the interesting evasion
techniques.
--
// Gianni Tedesco (gianni at ecsc dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
prev parent reply other threads:[~2002-10-02 13:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-01 1:13 Idea: string replace Peter Surda
2002-10-01 7:27 ` Patrick Schaaf
2002-10-01 21:06 ` Peter Surda
2002-10-01 23:33 ` Peter Surda
2002-10-02 13:44 ` Gianni Tedesco [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1033566290.27036.116.camel@lemsip \
--to=gianni@ecsc.co.uk \
--cc=netfilter-devel@lists.netfilter.org \
--cc=shurdeek@panorama.sth.ac.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.