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 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321
|
<?xml version="1.0"?>
<!DOCTYPE RATS [
<!ENTITY taintedfileop "When using this function, it is important to be sure that the string being passed in does not contain relative path elements (../ for example), or a null, which may cause underlying C calls to behave in ways you do not expect. This is especially important if the string is in any way constructed from a user supplied value.">
<!ENTITY dns "DNS results can easily be forged by an attacker (or arbitrarily se
t to large values, etc), and should not be trusted.">
<!ENTITY randdesc "Standard random number generators should not be used to
generate randomness used for security reasons. For security sensitive randomnes
s a crytographic randomness generator that provides sufficient entropy should be
used.">
]>
<VulnDB lang="perl">
<Vulnerability>
<Name>srand</Name>
<Info>
<Severity>Medium</Severity>
<Description>&randdesc;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>rand</Name>
<Info>
<Severity>Medium</Severity>
<Description>&randdesc;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>getc</Name>
<Input/>
</Vulnerability>
<Vulnerability>
<Name>readdir</Name>
<Input/>
</Vulnerability>
<Vulnerability>
<Name>read</Name>
<Input/>
</Vulnerability>
<Vulnerability>
<Name>sysread</Name>
<Input/>
</Vulnerability>
<Vulnerability>
<Name>exec</Name>
<Info>
<Severity>Medium</Severity>
<Description>When using exec, it is important to be sure that the string being used does not contain relative paths elements (../ for example), or a null, which may cause underlying C calls to behave strangely. </Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>fcntl</Name>
<Info>
<Severity>Medium</Severity>
<Description>The filehandle argument should not be derived from
user input. Doing so could allow arbitrary filehandles
to have operations carried out on them.
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>bind</Name>
<Info>
<Severity>Medium</Severity>
<Description>The second argument specifiying the packed address to bind
to, should not be derived from user input. If the address
is derived from user input, it is possible for a malicious
user to cause the socket to be bound to an address of their
choice.
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>setpgrp</Name>
<Info>
<Severity>Medium</Severity>
<Description>When using setpgrp, neither argument should be derived
from user input, doing so may allow the attacker to modify
both the PID and the PGRP argument, possibly allowing
arbitrary processes to have their process group changed.
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>setpriority</Name>
<Info>
<Severity>Medium</Severity>
<Description>When using setpriority, do not pass arguments to it that
are derived from user input. Doing so could allow an
attacker to set the priority of an arbitrary process on
the system.
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>syscall</Name>
<Info>
<Severity>High</Severity>
<Description>Care should be exercised when using the syscall function.
Arguments derived from user input are to be avoided, and
are especially dangerous due to the fact they are passed
directly to the underlying OS call. There is also a
potential for buffer-overflow like problems with strings
that may be written to. Extend all perl strings to sane
lengths before passing them into this function.
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>connect</Name>
<Info>
<Severity>High</Severity>
<Description>The second argument specifiying the packed address to bind
to, should not be derived from user input. If the address
is derived from user input, it is possible for a malicious
user to cause the socket to connect to an arbitrary remote
address, enabling hijacking of potentially sensitive
network data.
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>system</Name>
<Info>
<Severity>Medium</Severity>
<Description>When using system, it is important to be sure that the string being used does not contain relative path elements (../ for example), or a null, which may cause underlying C calls to behave strangely. It is also imperative
to insure the string has no characters that may be interpreted by the shell, possibly allowing arbitrary commands to be run
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>open</Name>
<Input/>
<Info>
<Severity>Medium</Severity>
<Description>The filename argument of open should be carefully checked if it is being created with any user-supplied string as a compontent of it. Strings should be checked for occurences of path backtracking/relative path components (../ as an example), or nulls, which may cause the underlying C call to interpret the filename to open differently than expected. It is also important to make sure that the final filename does not end in a "|", as this will cause the path to be executed.
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>unlink</Name>
<Info>
<Severity>Medium</Severity>
<Description>&taintedfileop;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>mkdir</Name>
<Info>
<Severity>Medium</Severity>
<Description>&taintedfileop;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>chdir</Name>
<Info>
<Severity>Medium</Severity>
<Description>&taintedfileop;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>rmdir</Name>
<Info>
<Severity>Medium</Severity>
<Description>&taintedfileop;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>chown</Name>
<Info>
<Severity>Medium</Severity>
<Description>&taintedfileop;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>chmod</Name>
<Info>
<Severity>Medium</Severity>
<Description>&taintedfileop;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>link</Name>
<Info>
<Severity>Medium</Severity>
<Description>&taintedfileop;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>symlink</Name>
<Info>
<Severity>Medium</Severity>
<Description>&taintedfileop;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>truncate</Name>
<Info>
<Severity>Medium</Severity>
<Description>&taintedfileop;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>chroot</Name>
<Info>
<Severity>Medium</Severity>
<Description>&taintedfileop;</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>umask</Name>
<Info>
<Severity>Medium</Severity>
<Description>Using a user supplied expression as an argument to this function should be avoided. Explicitly set the umask to a value you know is safe.</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>kill</Name>
<Info>
<Severity>Medium</Severity>
<Description>Avoid constructing the list of process ids to kill with any strings that contain user inputted data. Users may be able to manipulate the pid values in such a way as to cause arbitrary signals to be sent to processes, possibly leading to exploits or DoS attacks.
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>ioctl</Name>
<Info>
<Severity>Medium</Severity>
<Description>Using user supplied strings as the arguments to ioctl may allow the user to manipulate the device in arbitrary ways.
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>eval</Name>
<Info>
<Severity>High</Severity>
<Description>Using user supplied strings anywhere inside of an eval is extremely dangerous. Unvalidated user input fed into an eval call may allow the user to execute arbitrary perl code. Avoid ever passing user supplied strings into eval.</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>glob</Name>
<Info>
<Severity>High</Severity>
<Description>Glob invokes a shell (usually /bin/csh) to obtain the list of filenames that match the glob pattern. Unvalidated user input used in a glob pattern could allow arbitrary shell code to be run, possibly executing programs as a result. Avoid using user input in glob patterns.
</Description>
</Info>
</Vulnerability>
<Vulnerability>
<Name>fork</Name>
<Info>
<Description>
Remember that sensitive data get copied on fork. For example, a random
number generator's internal state will get duplicated, and the child
may start outputting identical number streams.
</Description>
<Severity>Low</Severity>
</Info>
</Vulnerability>
<Vulnerability>
<Name>gethostbyname</Name>
<Info>
<Description>&dns;</Description>
<Severity>High</Severity>
</Info>
</Vulnerability>
<Vulnerability>
<Name>gethostbyaddr</Name>
<Info>
<Description>&dns;</Description>
<Severity>High</Severity>
</Info>
</Vulnerability>
</VulnDB>
|