[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Feb 2015 19:21:25 -0500 (EST)
From: cve-assign@...re.org
To: steffen.roesemann1986@...il.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE-Request -- Landsknecht Adminsystems v.4.0.1 (DEV, beta version) -- Reflecting XSS, unrestricted file-upload and underlaying CSRF
-----BEGIN PGP SIGNED MESSAGE-----
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
UPLOADED_FILE itself.
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
relevant.
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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJU3pRRAAoJEKllVAevmvmszRgIAKTqAfCFqlHNnWIZtADfF6Gk
jMwCV5kugJjpzO0yzOkZ/luN0tKJBEKwAZbRfFr9KRnHldfJAE2DSf1TmSBEtKL8
m6RyGtRSleNiwH1Ed/w9oGGMjdO2ascnLYr+extIMhuy8H4l/VEhghi3et+Ud1X8
dUeHFB84zRdVqcmLi8xJIXtXLNQDpGI+FQY8jjBvQ2UqPp55Kk+cJdgQQUV8p4vg
5/vDZVfdpKCoJvfK5lMOTopZDzjix+z+ldKWHvuhg+IWX0H57UHzDIUlsnagzS7e
a1/eRUjZtjjtKmTBF7SHjVDDBaNVQwtZLPyyc/g5VxA+NelfCqORCeBJIqLUVss=
=Iqmo
-----END PGP SIGNATURE-----
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.
