Re: CVE Request -- LDAP Account Manager Pro / PhpLDAPadmin -- Multiple XSS flaws

[Jan Lieskovsky <jlieskov () redhat com>]

Thank you for your reply and the ids, Kurt.

Since you didn't explicitly mention CVE identifiers
for phpLDAPAdmin, checking with you yet.

Can we consider the CVE-2012-1114, CVE-2012-1115
identifiers below to be valid also for phpLDAPAdmin code?

According to Roland's reply:
http://www.openwall.com/lists/oss-security/2012/03/06/1

contains a reduced copy of phpLDAPAdmin's code.

Though we issue only one CVE identifier for the original
source code and can use that one also for projects, embedding
that source, not sure the current situation wrt to these
two is the correct one.

Roland, could you clarify, if phpLDAPAdmin code would be vulnerable
to all issues listed for LDAP Account Manager too or if phpLDAPAdmin
would be vulnerable only for XSS issues when processing:
i)   'export', 
ii)  'add_value_form'
iii)  and 'dn' variables?

And LDAP Account Manager would be vulnerable yet to additional
XSS flaws, due improper sanitization of 'filteruid', 'type',
and 'cmd' variables? (and these would be LDAP Account Manager
specific)

Because, if the latter is the case, I would propose the
CVE-2012-1114, CVE-2012-1115 identifiers to be used for phpLDAPAdmin
issues, and that we would assign new one for LDAP Account Manager
ones.

Any clarification here, which source code base is affected by
which issue exactly is appreciated.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

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)