Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Feb 2015 19:21:25 -0500 (EST)
Subject: Re: CVE-Request -- Landsknecht Adminsystems v.4.0.1 (DEV, beta version) -- Reflecting XSS, unrestricted file-upload and underlaying CSRF

Hash: SHA1

> As there seems not be an existing permission-model, users can read/execute
> files  an administrator/user uploaded and vice versa.

We think this means anyone can execute a file regardless of who
uploaded it. Do you mean that a file uploaded by a user can ONLY be
executed by an administrator or different user, whereas a file
uploaded by an administrator can ONLY be executed by a user?

> This issue includes an underlaying CSRF-vulnerability, as a user is able to
> upload a malicious file and trick another user or the administrator into
> visiting the link to the file.

We're not sure whether you mean the CSRF concept is relevant in a way
that is unusual for an "upload arbitrary files" issue.

If the attacker can upload a file, with the upload location and/or
file extension allowing execute access, then the typical outcome is
that exactly that file is executed. It is not typically the case that
a product modifies uploaded files to insert a CSRF protection
mechanism. Also, it is not typically the case that a pathname such as
/upload/files/{UPLOADED_FILE} would actually execute a wrapper program
(containing a CSRF protection mechanism) before executing

For these reasons, the ability to upload executable files to
/upload/files/{UPLOADED_FILE} would normally be considered a single
vulnerability, and would not lead to a conclusion that the product has
an independent CSRF problem.

Also, the primary threat model for "upload arbitrary files" issues is
that the file uploading and the file execution are done by the same
person. Certainly, it could be interesting to upload JavaScript code
and trick an administrator into executing it. However, if the attacker
can upload and execute PHP code without any tricking, ability to
upload JavaScript is usually not considered an independently relevant
problem. In common (but not all) cases, given an attacker's "upload
arbitrary files" ability, the entire class of scenarios in which the
file is later executed by a different person isn't independently

So, we think one CVE for the two XSS issues, and one CVE for file
upload, is the correct number. Do you have another interpretation?

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


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.