[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <A15E727D-B513-4DFE-A0BD-387B7C7949B0@gmail.com>
Date: Sat, 14 Feb 2015 07:09:54 +0100
From: Steffen Rösemann <steffen.roesemann1986@...il.com>
To: cve-assign@...re.org
Cc: 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
> 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?
I mean that anyone can execute files, regardless of who uploaded it.
> 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?
No, I follow your interpretation. Thank you very much.
Greetings.
> Am 14.02.2015 um 01:21 schrieb cve-assign@...re.org:
>
> -----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.
