Your message dated Sat, 30 May 2009 17:33:20 +0200
with message-id <[email protected]>
and subject line no-dsa
has caused the Debian Bug report #425026,
regarding Fwd: awffull: 3.7.1 bug with search string keywords
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
425026: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425026
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: security.debian.org
Severity: important
Hi,
Im fowarding this security bug reported by awffull upstream.
Im mantain awffull package and it havent this bug as I updated to
3.7.4 version.
This package must be updated in etch.
Solution is below.
---------- Forwarded message ----------
From: Steve McInerney <[email protected]>
Date: 07/05/2007 07:38
Subject: [Fwd: Re: [AWFFULL] awffull 3.7.1 bug with search string keywords]
To: Alexander Lazic <[email protected]>, Patrick Ben Koetter
<[email protected]>, "Ashley M. Kirchner" <[email protected]>, John
Heaton <[email protected]>
Cc: Oden Eriksson <[email protected]>, Jose Carlos Medeiros
<[email protected]>
All
private email to ya'll as my more "keen" users :-)
Yup this *IS* a security hole as described below. Possibly only XSS. But
maybe other possibilities my fertile imagination can't dream up
quickly... :-(
Simple fix: disable "All Search Terms" report for now. I'm not convinced
that that is a perfect fix tho.
The problem is line 496 in awffull.c: (3.7.4-b3)
/* fix referrer field */
cp1 = log_rec.refer;
cp3 = cp2 = cp1++;
496: if ((*cp2 != '\0') && (*cp2 == '"')) {
while (*cp1 != '\0') {
cp3 = cp2;
Is:
if ((*cp2 != '\0') && (*cp2 == '"')) {
Should be:
if (*cp2 != '\0') {
Some other ancillary issues around that, so that's not the be all and
end all either.
I do *hope* to have a fix in the next few hours.
In the meantime, can I ask you all to keep this to yourselves until I do
get a proper fix together? I thought a quick heads up to those deemed
more likely to be at risk to be a Good Idea. :-)
Oden, Jose; more of an FYI for you two, at this stage, as packagers.
Anyway, apologies for the inconvenience et al...
Talk more shortly!
Cheers!
- Steve
-------- Original Message --------
Subject: Re: [AWFFULL] awffull 3.7.1 bug with search string keywords
Date: Mon, 07 May 2007 20:24:53 +1000
From: Steve McInerney <[email protected]>
To: "Héctor Delcourt (Armonth)" <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
Hey Héctor,
Ok. Bad news: That is a security bug - nasty one too as you originally
pointed out.
The *basic* fault is that with the change to using PCRE's to split the
various fields up the referral string passed in for inspection no longer
starts with a double quote: "
Hence it never actually gets checked and hence the '<' never gets stripped.
I've done a quick and dirty fix, but it breaks the counts for the
various results. Trying to figure out if the break makes things correct,
or wrong. :-/
I *hope* to have a fix later this evening (currently 8.30pm).
So if you could keep this one to yourself till I do have a formal patch
ready to roll I'd be appreciative.
A simple fix is to simply disable display of the "All Search Strings"
report. For some reason - not checked why yet, the main page summary
doesn't show the fault.
Cheers, and sincerely, thanks for bringing this to my attention!
- Steve
on 07/05/07 04:56 Héctor Delcourt (Armonth) said the following:
Hi Steve,
El Domingo, 6 de Mayo de 2007 13:26, escribió:
Unsure...
My concern, having been sufficiently distracted and intruiged by the
problem. :-) Is that it should never have gotten past the cleanup
functions.
ie. a "<" is not a valid character and should get zotted.
It should get de-escaped, and hence converted back into a "<" and then
found as a bad character and cause the rest of the line to get tossed.
Do you have the original log line where this occurs? I'd be very keen to
add it to my (growing..) collection of tests.
zgrep marquee *.gz
access.log.2007-05-03.gz:200.92.64.207 - -
[03/May/2007:15:44:37 -0700] "GET
/archivo/deshabilitar-blink-y-marquee-en-firefox.xhtml
HTTP/1.1" 200
4940 "http://www.google.com/search?hl=en&q=funcion+de+la+etiqueta+%3CMARQUEE%3E";
"Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1)"
access.log.2007-05-03.gz:200.124.164.47 - -
[03/May/2007:16:02:45 -0700] "GET
/archivo/deshabilitar-blink-y-marquee-en-firefox.xhtml
HTTP/1.1" 200
5008
"http://www.google.com.co/search?hl=es&q=funcion+de+la+etiquetas+%3Cblink%3E&meta=";
"Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1; FunWebProducts; .NET CLR
2.0.50727; .NET CLR 1.1.4322)"
access.log.2007-05-03.gz:189.174.4.8 - -
[03/May/2007:16:06:54 -0700] "GET
/archivo/deshabilitar-blink-y-marquee-en-firefox.xhtml
HTTP/1.1" 200
This is one of the <marquee>, all others are the same way of
escaped-chars...
5008
"http://www.google.com.mx/search?client=firefox-a&rls=org.mozilla%3Aes-AR%3Aofficial&channel=s&hl=es&q=que+funcion+tiene+la+etiqueta+%22%3CMARQUEE%3E%22&meta=&btnG=Buscar+con+Google";
"Mozilla/5.0
(Windows; U; Windows NT 5.1; es-AR; rv:1.8.1.3) Gecko/20070309
Firefox/2.0.0.3"
Another on with blink: access.log.2007-04-19.gz:200.116.120.152 - -
[19/Apr/2007:15:38:42 -0700] "GET
/archivo/deshabilitar-blink-y-marquee-en-firefox.xhtml
HTTP/1.1" 200
4916
"http://www.google.es/search?hl=es&client=firefox-a&rls=org.mozilla%3Aes-ES%3Aofficial&q=etiqueta%3CBLINK%3E&btnG=B%C3%BAsqueda&meta=";
"Mozilla/5.0
(Windows; U; Windows NT 5.1; es-ES; rv:1.8.0.11) Gecko/20070312
Firefox/1.5.0.11"
In two minutes im left from house, but later I send you logs from last
month with "zgrep marquee *.gz | grep google" and the same with blink...
PD: About bookmarks... okay, one possible suggest for this is "feed
suscriptores counter" ... use the last referer from one site for count...
all bot from feeds-readers show one referer like "name-of-boot (xxx
subscriptors) but is "normal" see referers duplicated for the same feed,
for ej, RSS Feed and RSS Atom for Google Fetcher (Google Reader):
Feedfetcher-Google; (+http://www.google.com/feedfetcher.html; 380
subscribers; feed-id=3958862787979257262)
Feedfetcher-Google; (+http://www.google.com/feedfetcher.html; 2
subscribers; feed-id=5860511144573734128)
380 RSS and 2 Atom...
One duplicated for RSS (few days ago):
Feedfetcher-Google; (+http://www.google.com/feedfetcher.html; 376
subscribers; feed-id=3958862787979257262)
If is possible discard duplicated ua-reports and group in one (Google
reader use the feed-id but others like news gator no) is possible add
a "Feed suscriptores readers" ...
Greetings...
--
[]'s
José Carlos
--
[]'s
José Carlos
--- End Message ---
--- Begin Message ---
Hi,
We've decided long ago that this issue would not get a DSA update for etch
because it was considered too minor, given the possible attack vectors. Lenny
and up are fixed for it. I'm closing this bug now.
Thijs
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
