From delphij at frontfree.net Sat May 1 10:57:22 2004
From: delphij at frontfree.net (Xin LI)
Date: Sat May 1 10:57:45 2004
Subject: ports/66150: [PATCH] SECURITY UPDATE ports/www/phpbb for IP
spoofing vulnerablity
In-Reply-To: <20040501171456.0225511602@beastie.frontfree.net>
References: <20040501171456.0225511602@beastie.frontfree.net>
Message-ID: <20040501175716.GA697@frontfree.net>
Also, I hope the attached patch, which mitigates session table exhaustion
which could be used in a DDoS attack after the above patch to get its
way into phpbb/files so it will be automatically patched.
I suggest to add the following item to be added into vuxml:
phpBB ession table exhaustionphpbb2.0.8_2
The includes/sessions.php unnecessarily adds session item into
session table and therefore vulnerable to a DDoS attacK.
http://www.securityfocus.com/archive/1/3609312004-03-052004-05-01
--
Xin LI http://www.delphij.net/
See complete headers for GPG key and other information.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-vuxml/attachments/20040502/e6d82802/attachment.bin
From delphij at frontfree.net Sat May 1 11:10:57 2004
From: delphij at frontfree.net (Xin LI)
Date: Sat May 1 11:11:09 2004
Subject: ports/66150: [PATCH] SECURITY UPDATE ports/www/phpbb for IP
spoofing vulnerablity
In-Reply-To: <20040501175716.GA697@frontfree.net>
References: <20040501171456.0225511602@beastie.frontfree.net>
<20040501175716.GA697@frontfree.net>
Message-ID: <20040501181052.GA707@frontfree.net>
Oops, forgot the attachment, it should be:
Index: includes/sessions.php
===================================================================
RCS file: /cvsroot/phpbb/phpBB2/includes/Attic/sessions.php,v
retrieving revision 1.58.2.10
diff -u -r1.58.2.10 sessions.php
--- includes/sessions.php 5 Apr 2003 12:04:33 -0000 1.58.2.10
+++ includes/sessions.php 17 Apr 2004 07:48:20 -0000
@@ -147,7 +147,7 @@
$sql = "INSERT INTO " . SESSIONS_TABLE . "
(session_id, session_user_id, session_start, session_time, session_ip, session_page, session_logged_in)
VALUES ('$session_id', $user_id, $current_time, $current_time, '$user_ip', $page_id, $login)";
- if ( !$db->sql_query($sql) )
+ if ( $user_id != ANONYMOUS && !$db->sql_query($sql) )
{
message_die(CRITICAL_ERROR, 'Error creating new session', '', __LINE__, __FILE__, $sql);
}
@@ -380,4 +380,4 @@
return $url;
}
-?>
\ No newline at end of file
+?>
--
Xin LI http://www.delphij.net/
See complete headers for GPG key and other information.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-vuxml/attachments/20040502/ca8a697a/attachment.bin
From nectar at FreeBSD.org Thu May 6 09:29:56 2004
From: nectar at FreeBSD.org (Jacques A. Vidrine)
Date: Thu May 6 09:30:08 2004
Subject: Adding `branches' to VuXML
Message-ID: <20040506161853.GA649@lum.celabo.org>
Hi All,
Robert Nagy of OpenBSD requested the addition of `branches' to
VuXML. I expected that he would be posting a proposal here, but since I
haven't seen it I'll give it a shot on my own.
In FreeBSD, we do not branch the Ports Collection like we do the base
system. However, it seems that OpenBSD's Ports & Packages Collection
*does* use branches. Thus, it is possible for a security issue to
affect foo-1.1 in branch BRANCH_X, but not foo-1.1 in BRANCH_Y.
Currently, it is not possible to express this in VuXML, short of
maintaining separate VuXML files for each branch (e.g. branching the
VuXML file, also).
So, here is a suggested extension by example.
The element in VuXML 1.1 has two child elements, and
. These behave as a kind of cross-product: it expresses that
the affected packages are all of those combinations of name and range.
e.g.
foobar2.02.21.5
expresses that these ranges are affected:
foo < 1.5
2.0 <= foo < 2.2
bar < 1.5
2.0 <= bar < 2.2
(Note also that there can be multiple elements for an issue.)
So one possibility would be to add a child element:
BRANCH_XBRANCH_Yfoofoo-1.1
The content model for and are the same. I wonder if
the optional presence of the child element for will
cause any confusion? Right now, for issues that affect the FreeBSD base
system, we just use version numbers without reference to the branch.
e.g.
FreeBSD5.05.2_64.94.9_64.04.8_19
Anyway ... comments?
--
Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org
From robert at openbsd.org Thu May 6 09:34:17 2004
From: robert at openbsd.org (Robert Nagy)
Date: Thu May 6 09:34:29 2004
Subject: Adding `branches' to VuXML
In-Reply-To: <20040506161853.GA649@lum.celabo.org>
References: <20040506161853.GA649@lum.celabo.org>
Message-ID: <1083861289.3310.58.camel@enterprise.hu>
On Thu, 2004-05-06 at 18:18, Jacques A. Vidrine wrote:
> Hi All,
>
> Robert Nagy of OpenBSD requested the addition of `branches' to
> VuXML. I expected that he would be posting a proposal here, but since I
> haven't seen it I'll give it a shot on my own.
>
> In FreeBSD, we do not branch the Ports Collection like we do the base
> system. However, it seems that OpenBSD's Ports & Packages Collection
> *does* use branches. Thus, it is possible for a security issue to
> affect foo-1.1 in branch BRANCH_X, but not foo-1.1 in BRANCH_Y.
> Currently, it is not possible to express this in VuXML, short of
> maintaining separate VuXML files for each branch (e.g. branching the
> VuXML file, also).
>
> So, here is a suggested extension by example.
>
> The element in VuXML 1.1 has two child elements, and
> . These behave as a kind of cross-product: it expresses that
> the affected packages are all of those combinations of name and range.
> e.g.
>
>
> foo
> bar
> 2.02.2
> 1.5
>
>
> expresses that these ranges are affected:
>
> foo < 1.5
> 2.0 <= foo < 2.2
> bar < 1.5
> 2.0 <= bar < 2.2
>
> (Note also that there can be multiple elements for an issue.)
>
> So one possibility would be to add a child element:
>
>
>
> BRANCH_X
> BRANCH_Y
> foo
> foo-1.1
>
>
> The content model for and are the same. I wonder if
> the optional presence of the child element for will
> cause any confusion? Right now, for issues that affect the FreeBSD base
> system, we just use version numbers without reference to the branch.
> e.g.
>
> FreeBSD
> 5.05.2_6
> 4.94.9_6
> 4.04.8_19
>
>
> Anyway ... comments?
Thanks. Sorry i totally forgot about this. I've shitloads to do. Yeah I
like it.
--
Robert Nagy
From listsucker at ipv5.net Thu May 6 10:38:25 2004
From: listsucker at ipv5.net (Frankye - ML)
Date: Thu May 6 10:38:37 2004
Subject: Adding `branches' to VuXML
In-Reply-To: <20040506161853.GA649@lum.celabo.org>
References: <20040506161853.GA649@lum.celabo.org>
Message-ID: <20040506193818.3bd177a4@godzilla>
On Thu, 6 May 2004 11:18:53 -0500
"Jacques A. Vidrine" wrote:
| Robert Nagy of OpenBSD requested the addition of `branches' to
| VuXML.
[cut]
| So one possibility would be to add a child element:
|
|
|
| BRANCH_X
| BRANCH_Y
| foo
| foo-1.1
|
|
| The content model for and are the same. I wonder if
| the optional presence of the child element for will
| cause any confusion? Right now, for issues that affect the FreeBSD base
| system, we just use version numbers without reference to the branch.
| e.g.
|
| FreeBSD
| 5.05.2_6
| 4.94.9_6
| 4.04.8_19
|
|
| Anyway ... comments?
Just a little idea.
Wouldn't be better to put into the item? I understand
"branches" might not always be increasing numbers, so this might limit the
general usefulness of such an idea, but at least in openbsd are (iirc).
in the example above this would mean:
foo3.3foo-1.1
It would not add much complexity (I hope it at least :) and we can use the
added flexibility provided by the various lt, ge, et al.
And now, since we're speaking of branches, here comes another silly idea
of mine: can we use the cvs tags instead of the versions (i.e.: RELENG_4
or RELENG_4_9) in items for the freebsd vuln.xml file?
This has no real practical reason whatsoever, but imvho for the historical
record is better-looking to say "-STABLE and 4.9-RELEASE were affected"
rather than "this version, which if you go looking for turns out to be the
-STABLE one, and this other ..."
(If this has a beneficial effect on the eventual confusion generated by
the item, remains to be seen, imho it has not)
Just my 2 cents
Frankye
From nectar at FreeBSD.org Thu May 6 11:56:50 2004
From: nectar at FreeBSD.org (Jacques A. Vidrine)
Date: Thu May 6 11:57:02 2004
Subject: Adding `branches' to VuXML
In-Reply-To: <20040506193818.3bd177a4@godzilla>
References: <20040506161853.GA649@lum.celabo.org>
<20040506193818.3bd177a4@godzilla>
Message-ID: <20040506185648.GA1777@madman.celabo.org>
On Thu, May 06, 2004 at 07:38:18PM +0200, Frankye - ML wrote:
> Just a little idea.
>
> Wouldn't be better to put into the item? I understand
> "branches" might not always be increasing numbers, so this might limit the
> general usefulness of such an idea, but at least in openbsd are (iirc).
>
> in the example above this would mean:
>
>
> foo
>
> 3.3
> foo-1.1
>
>
>
> It would not add much complexity (I hope it at least :) and we can use the
> added flexibility provided by the various lt, ge, et al.
In general, branches are arbitrary strings, at we cannot count on
them to have any particular ordering. Happily, they are not usually
numerous, so the utility of and so forth doesn't buy much.
In fact, I thought that it might be wise to name the new element
rather than , to reflect that this is really just
one additional way to distinguish different packages.
As for making it a child element of ... I don't think that
is a good idea. Changing the content model of will have
more impact on existing tools than just adding a new element to
/. It could also multiply the number of
elements required.
> And now, since we're speaking of branches, here comes another silly idea
> of mine: can we use the cvs tags instead of the versions (i.e.: RELENG_4
> or RELENG_4_9) in items for the freebsd vuln.xml file?
>
> This has no real practical reason whatsoever, but imvho for the historical
> record is better-looking to say "-STABLE and 4.9-RELEASE were affected"
> rather than "this version, which if you go looking for turns out to be the
> -STABLE one, and this other ..."
> (If this has a beneficial effect on the eventual confusion generated by
> the item, remains to be seen, imho it has not)
I'm not sure what you mean. The FreeBSD Ports Collection does
not have branches. Are you referring to the elements
specifically? I think the information would be redundant, due
to the way release engineering is done today. i.e. RELENG_N_M
always corresponds to FreeBSD N.M-something. Branch names cannot
replace version numbers, because there is a difference between, say
4.9-RELEASE-p1 (4.9_1) and 4.9-RELEASE-p7 (4.9_7) that cannot be
reflected in the CVS branch name (RELENG_4_9) by its very nature.
But, it's possible I misunderstood what you are suggesting.
It is probably a topic for another thread that there currently isn't
a way to express that a -STABLE or -CURRENT branch is or isn't
affected. This has to do with the fact that -STABLE and -CURRENT
aren't versioned until there is a release.
> Just my 2 cents
Thanks much!
Cheers,
--
Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org