[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F553E93.1010908@redhat.com>
Date: Mon, 05 Mar 2012 15:30:43 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Jan Lieskovsky <jlieskov@...hat.com>,
"Steven M. Christey" <coley@...us.mitre.org>,
Roland Gruber <post@...andgruber.de>,
Fabio Tranchitella <kobold@...ian.org>,
Dmitry Butskoy <Dmitry@...skoy.name>
Subject: Re: CVE Request -- LDAP Account Manager Pro / PhpLDAPadmin
-- Multiple XSS flaws
On 03/05/2012 03:36 AM, Jan Lieskovsky wrote:
> Hello Kurt, Steve, vendors,
>
> originally (2012-03-01), the following cross-site (XSS) flaws were
> reported
> against LDAP Account Manager Pro (from Secunia advisory [1]):
>
> * 1) Input passed to e.g. the "filteruid" POST parameter when filtering
> result
> sets in lam/templates/lists/list.php (when "type" is set to a valid
> value) is
> not properly sanitised before being returned to the user. This can be
> exploited
> to execute arbitrary HTML and script code in a user's browser session in
> context of an affected site.
>
> * 2) Input passed to the "filter" POST parameter in
> lam/templates/3rdParty/pla/htdocs/cmd.php (when "cmd" is set to "export"
> and
> "exporter_id" is set to "LDIF") is not properly sanitised before being
> returned
> to the user. This can be exploited to execute arbitrary HTML and script
> code in
> a user's browser session in context of an affected site.
Please use CVE-2012-1114 for these two issues (XSS, same reporter)
> * 3) Input passed to the "attr" parameter in
> lam/templates/3rdParty/pla/htdocs/cmd.php (when "cmd" is set to
> "add_value_form" and "dn" is set to a valid value) is not properly
> sanitised
> before being returned to the user. This can be exploited to execute
> arbitrary
> HTML and script code in a user's browser session in context of an affected
> site.
Please use CVE-2012-1115 for this vu;n (XSS, but different reporter)
> References:
> [1] http://secunia.com/advisories/48221/
> [2] http://www.vulnerability-lab.com/get_content.php?id=458
>
> Later (2012-03-03), it was reported:
> [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662050#15
>
> that subset (for 'export', 'add_value_form', and 'dn' variables) of these
> security flaws is applicable also against the code of PhpLDAPadmin, a
> web-based
> LDAP client.
>
> Patches from LDAP Account Manager, which are applicable to PphLDAPAdmin:
> [4]
> http://lam.cvs.sourceforge.net/viewvc/lam/lam/templates/3rdParty/pla/lib/export_functions.php?r1=1.4&r2=1.5
>
>
> [5]
> http://lam.cvs.sourceforge.net/viewvc/lam/lam/templates/3rdParty/pla/htdocs/export.php?r1=1.1&r2=1.2
>
>
> [6]
> http://lam.cvs.sourceforge.net/viewvc/lam/lam/templates/3rdParty/pla/htdocs/add_value_form.php?r1=1.6&r2=1.7
>
>
> I would swear, I have seen LDAP Account Manager CVE request on OSS
> security mailing list
> recently, but can't find it now quickly right now. Kurt, please prior
> assigning CVE ids
> to "LDAP Account Manager Pro" please double check the main CVE mitre
> database, if these
> didn't get a CVE identifier yet.
>
> Wrt to PhpLDAPAdmin side -- I am not sure, what's the relation of the
> code between LAM and
> PLA (if PLA is using / embedding some code of LAM directly or if there
> were also some
> customizations on the side of PLA upon LAM code embedding / inclusion).
> Hopefully Roland,
> Fabio, Dmitry can clarify here, how much the PhpLDAPAdmin code is
> different from LDAP
> Account Manager code (if it's just overtaken LAM code or PhpLDAPAdmin
> have also made
> their own customizations to the code)?
>
> Roland, Fabio, Dmitry, basically what we are searching an answer for is,
> if the PhpLDAPAdmin
> code is different enough it safe to be considered as a different code
> base and separate
> CVE identifier to be allocated for it? (IOW one for LDAP Account Manager
> Pro issues,
> the other for PhpLDAPAdmin issues)
>
> Kurt, once the above doubt solved and you checked and confirmed, that
> LDAP Account Manager
> issue did not get CVE identifier in the recent past yet, could you
> allocate those?
>
> Thank you && Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Response Team
--
Kurt Seifried Red Hat Security Response Team (SRT)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
