Kritikus biztonsági hibát javít a Drupal 7.32-es kiadása

PHP

A Drupal fejlesztői tegnap kiadták a népszerű CMF 7.32-es verzióját. A 7.x ágat használóknak javasolt a mielőbbi frissítés, mert a kiadás egy kritikus, SQL injection típusú támadást lehetővé tevő sebezhetőséget javít.

A Drupal 7 tartalmaz egy adatbázis absztrakciós API-t, amelynek feladata, hogy segítsen megelőzni az adatbázis ellen intézett SQL injection típusú támadásokat. Egy, az API-ban található sebezhetőség azonban pont ilyen típusú támadást tesz lehetővé a speciálisan összeállított kérést küldő támadó számára. Függően attól, hogy mi található a kérésben, a sebezhetőség privilégiumszint-emelést, tetszőleges PHP futtatást stb. tehet lehetővé.

Részletek a SA-CORE-2014-005 - Drupal core - SQL injection hibajegyben.

A hozzászóláshoz be kell jelentkezni
2833 megtekintés

https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch


-      foreach ($data as $i => $value) {
+      foreach (array_values($data) as $i => $value) {

Ez is egy phpwtfnek néz ki... Biztos én vagyok elfogult, de nekem ez +1 jó indok arra, hogy messzire elkerüljem a PHP-t. Biztos lehet jól is csinálni, csak ez keveseknek megy, vagy túl sok erőfeszítést igényel.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Inkább drupal specifikus dolognak néz ki. De nem állítom h 100%-ban felfogtam, h mit akarnak vele! Az $i-n keresztül lehetett injektálni az SQL-be, vagy mi?

0 szavazat

A hozzászóláshoz be kell jelentkezni

Roviden: igen. Ez ugye az az eset, egy IN()-es prepared statement-et akarnak kodbol generalni. Kap a fenti kod egy "sima" numeric arrayt, abbol az index ($i)-bol lesznek a mezonevek, ugy mint IN(:foo_0, :foo_1). Ha viszont associative array-t kap, akkor a $i nem szam lesz, hanem pl. string, ami raadasul attacker-controlled, es game over.

Az eredeti advisory-t erdemes megnezni.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Köszi, így már érthető!

0 szavazat

A hozzászóláshoz be kell jelentkezni

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Szerinted…

0 szavazat

A hozzászóláshoz be kell jelentkezni

De azért a Drupal Security Teamről megvan a véleményem:

"How long did it take to release this patch?

The Drupal Security Team has a standard process for releasing core security issues. We work on them in coordination with the system maintainers and then release them on the third Wednesday of each month. The Drupal Security Team was informed of this issue in the third week of September of 2014. Given the severity of the issue, we debated about releasing it early. Our main concern was when people would have the time to perform the upgrade. Drupalcon Amsterdam started on September 29th meaning that many of our community members were busy preparing for that event. The week after Drupalcon is typically busy catching up from being at Drupalcon and then October 15th was the first regularly planned security release Wednesday. We felt that it would be better to use the regularly scheduled date which also happened to be the first date when the Drupal community would be likely to have time to focus on the upgrade."

Highly critical, naná. Pont ezt a tohonyaságot tapasztaltam, amikor sok éve én jelentettem nekik security bugot a saját modulomban. Hetekig meg volt kötve a kezünk, pedig nagyon dolgoztunk volna. (Mert ilyenkor a "ne nyúlj semmihez, és még véletlenül se javítsd ki a hibát!"-policy lép életbe.)

Aztán később valaki más bejelentett egy ritkán használt konfiguráció mellett fennálló problémát egy olyan verzióval kapcsolatban, ami akkor már obsolete volt (de még letölthető), és biztonsági vonatkozása is volt. Több, mint egy évvel (!) később adta tovább nekem az információt a SecTeam. Addigra már az a verzió nem volt elérhető, de ők ragaszkodtak hozzá, hogy jöjjön ki advisory a senki által nem használt verzióhoz az addigra normál úton rég kijavított hibáról.

Grr.

0 szavazat