-
Notifications
You must be signed in to change notification settings - Fork 102
/
CVE-2009-2693.yml
218 lines (203 loc) · 9.25 KB
/
CVE-2009-2693.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
CVE: CVE-2009-2693
nickname_instructions: |
Nickname is optional. Provide a useful, professional, and catchy nickname for
this vulnerability. Ideally fewer than 30 characters. This will be shown
alongside its CVE to make it more easily distinguished from the rest.
nickname: Remote Arbitrary File Creation
CWE_instructions: |
Please go to cwe.mitre.org and find the most specific, appropriate CWE entry
that describes your vulnerability. (Tip: this may not be a good one to start
with - spend time understanding this vulnerability before making your choice!)
CWE: CWE-23 Relative Path Traversal
curated_instructions: |
If you are manually editing this file, then you are "curating" it. Set the
entry below to "true" as soon as you start. This will enable additional
integrity checks on this file to make sure you fill everything out properly.
If you are a student, we cannot accept your work as finished unless curated is
set to true.
curation_level: 1
reported_instructions: |
Was there a date that this vulnerability was reported to the team? You can
find this in changelogs, blogs, bug reports, or perhaps the CVE data.
Please enter your date in YYYY-MM-DD format.
reported: 2009-07-30
announced_instructions: |
Was there a date that this vulnerability was announced to the world? You can
find this in changelogs, blogs, bug reports, or perhaps the CVE data.
Please enter your date in YYYY-MM-DD format.
announced: 2010-03-01
description_instructions: |
You can get an initial description from the CVE entry on cve.mitre.org. These
descriptions are a fine start, but they can be kind of jargony.
Rewrite this description in your own words. Make it interesting and easy to
read to anyone with some programming experience. We can always pull up the NVD
description later to get more technical.
Try to still be specific in your description, but remove Chromium-specific
stuff. Remove references to versions, specific filenames, and other jargon
that outsiders to Chromium would not understand. Technology like "regular
expressions" is fine, and security phrases like "invalid write" are fine to
keep too.
description: The vulnerability allows for an attacker to create, modify, or delete files
using a specially crafted Web Application Resource (WAR) file. Tomcat fails
to check for directory traversal commands in directory paths using ../ and
that is what the attacker uses to craft the WAR file.
When the WAR file is deployed on the Tomcat server, the directory traversal
command can be used to modify files outside of the web root directory. The
files can be created, modified, or deleted.
Secure information from the web server could be moved out of sccope, or a key
file for the server could be deleted which could cause a denial of service.
bounty_instructions: |
If you came across any indications that a bounty was paid out for this
vulnerability, fill it out here. Or correct it if the information already here
was wrong. Otherwise, leave it blank.
bounty:
amt:
announced:
url:
bugs: []
fixes_vcc_instructions: |
Please put the Git commit SHA in "commit" below, and any notes about how this
was discovered in the "note" field.
Refer to our instructions on how to find a Git SHA from an SVN revision.
fixes:
- commit: 3e1010b1a2f648581fac3d68afbf18f2979f6bf6
note: Fixed Dec 21 2009 at 12:25:14
vccs:
- commit: eae54419c6e196933998f63358367040edaa4a8c
note: Pushed Jul 20 2009 at 12:50:34
incomplete_fix_instructions: |
Did the above "fixes" actually fix the vulnerability?
Please list any fix commits for this vulnerability that had to be corrected
at a later date.
incomplete_fixes:
- commit: none
note: The fix worked
upvotes_instructions: |
Students: when initially writing this, ignore this upvotes number.
Once this work is being reviewed, you will be giving a certain amount of
upvotes to each vulnerability you see. Your peers will tell you how
interesting they think this vulnerability is, and you'll add that to the
upvotes score on your branch.
upvotes: 9
unit_tested:
question: |
Were automated unit tests involved in this vulnerability?
Was the original code unit tested, or not unit tested? Did the fix involve
improving the automated tests?
Write the reasoning behind your answer in the "answer" field.
For the "code" answer below, look not only at the fix but the surrounding
code near the fix and determine if and was there were unit tests involved
for this module. Must be just "true" or "false".
For the "fix" answer below, check if the fix for the vulnerability involves
adding or improving an automated test to ensure this doesn't happen again.
Must be just "true" or "false".
answer: false
code: false
fix:
discovered:
question: |
How was this vulnerability discovered?
Go to the bug report and read the conversation to find out how this was
originally found.
* Answer in longform below in "answer"
* Fill in the date in YYYY-MM-DD
* If it's clear that the vulnerability was discovered by a contest,
fill in the name there.
* The "automated" flag can be true, false, or nil.
If there is no evidence as to how this vulnerability was found, then you
may leave the entries blank except for "answer", BUT please write down
where you looked in "answer".
answer: The SVN page for the commit does not indicate how the vulnerability was found
https://svn.apache.org/repos/asf/tomcat/trunk@892795
and the links within the CVE page also do not show how this was discovered
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2693
date: 2009-07-30
automated: false
contest:
subsystem:
question: |
What subsystems was the mistake in?
Look at the path of the source code files code that were fixed to get
directory names. Look at comments in the code. Look at the bug reports how
the bug report was tagged.
Examples: "clipboard", "gpu", "ssl", "speech", "renderer"
answer: startup
name: startup
interesting_commits:
question: |
Are there any interesting commits between your VCC(s) and fix(es)?
Write a brief (under 100 words) description of why you think this commit was
interesting in light of the lessons learned from this vulnerability. Any
emerging themes?
If there are no interesting commits, demonstrate that you completed this
section by explaining what happened between the VCCs and the fix.
answer:
commits:
- commit: 3b0ea850738c091299373a330929cc024dd1867a
note: There isn't anything interesting happening. But this commit reverted the
previous commit since the developer was not satisfied with the fix.
lessons:
question: |
Are there any common lessons we have learned from class that apply to this
vulnerability? In other words, could this vulnerability serve as an example
of one of those lessons?
Leave "applies" blank or put false if you did not see that lesson (you do
not need to put a reason). Put "true" if you feel the lesson applies and put
a quick explanation of how it applies.
Don't feel the need to claim that ALL of these apply, but it's pretty likely
that one or two of them apply.
If you think of another lesson we covered in class that applies here, feel
free to give it a small name and add one in the same format as these.
path_traversal:
applies: true
note: This is directly an example of using ../ to navigate outside the root directory
defense_in_depth:
applies: false
note:
least_privilege:
applies: false
note:
frameworks_are_optional:
applies: false
note:
native_wrappers:
applies: false
note:
distrust_input:
applies: false
note:
security_by_obscurity:
applies: false
note:
serial_killer:
applies: false
note:
environment_variables:
applies: false
note:
secure_by_default:
applies: false
note:
yagni:
applies: false
note:
complex_inputs:
applies: false
note:
mistakes:
question: |
In your opinion, after all of this research, what mistakes were made that
led to this vulnerability? Coding mistakes? Design mistakes?
Maintainability? Requirements? Miscommunications?
Look at the CWE entry for this vulnerability and examine the mitigations
they have written there. Are they doing those? Does the fix look proper?
Use those questions to inspire your answer. Don't feel obligated to answer
every one. Write a thoughtful entry here that those ing the software
engineering industry would find interesting.
answer: The mistake that was made here was simple. The developer neglected to consider
that someone might try to navigate outside of the root directory and never
put in test cases and exceptions for when that happens. Since there was a lack
of unit testing, the directory traversal was never tested for and stayed in the
code for a while unnoticed. This isn't exactly a mistake but more of an oversight
on the developers part. The vulnerability was fixed by adding checks for "../"
for any path that was being constructed.