Biztonsági réseket foltoz a phpMyAdmin legújabb frissítése

MySQL, MariaDB

Biztonsági frissítések láttak napvilágot a phpMyAdmin névre hallgató MySQL adminisztrációs eszközhöz. A kiadott frissítések verziói: 2.11.9.6 és 3.2.2.1. A fejlesztők szerint a megelőző verziók XSS támadást és tetszőleges SQL parancsok injektálását tehetik lehetővé. A részletek a figyelmeztetőben.

( MysteryKe | 2009. 10. 18., v – 16:02 )

"[...] és tetszőleges SQL parancsok injektálását tehetik lehetővé. [...]"
Már nem azért, de nem pont erre való a PhpMyAdmin? xD

( xobor | 2009. 10. 18., v – 18:14 )

Alig futott, SQL injektoros portál eladó! :)

( wladek1 | 2009. 10. 18., v – 18:38 )

Érdekelne, hogy miért nem lehet egyszer normálisan megcsinálni ezt a cuccot?

"-Pedig vegetariánus vagyok; csak növényevő állatokat fogyasztok!"
azenoldalamponthu

Viszontkérdés: néztél már bele a PHPMyAdmin forráskódjába?

Egyébként ezeknek a vulnoknak az a szépsége, hogy ha nem használja az ember a könyvjelző, stb funkciót és nem ad default adatbázis-kapcsolatot neki, akkor nem is működnek. Persze a távoli kódfuttatás a csúnyábbik eset.

Ugyan nem nekem tetted fel a kerdest, de en mar neztem bele a kodjaba. Hatalmas elmeny, ilyen spagettit meg sose lattam korabban. Azt hiszem, azota sem..

(meg egy regi projectnel tortent, volt valami feature-je, ami kellett volna.. ugy gondultuk, belenezunk a forrasaba, hogy lehet meghivni programbol kulon ezt a funkciojat.. feladtuk..)

--
"You will have to look a long way before you find a bunch of scum-suckers more greedy, humourless and deserving of death than the suits in the music business." - Terry Pratchett

( oldesik | 2009. 10. 18., v – 22:30 )

Esetleg van valakinek ötlete, hogy autómatikusan hogyan akadályozzam meg, hogy az user akinek van
ftp hozzáférése a saját chroot -olt virtualjához ne rakhasson fel myadmint ? Van központi és mégis felrakják.
Most egy find fut időről időre, de ez ugye csak addig életképes, amíg a pecifikumok megvannak amire keresni lehet.
Köszi

Ha teljes chroot van, akkor kisebb a későbbi visszaállítás szívása, de a jellemző az, hogy docroot és safe mode van, ezek meg minden ellen nem védenek. Ha a myadmin exp. össze van kapcsolva egy local kernel exp.-el, akkor sajnos elég keményen az én gondom is.
Ezért elvi és technikai szinten bármi érdekel :)

Értem. :)

Nem vagyok hostingszakértő, csak jelen helyzetben két weboldalt tartok karban úgy puszi-szívességből kocarenccergazdaként, azaz a te szemszögedből én vagyok a júzer.

Sajna az egyik hosting szolgáltatásnál nem mindig m1 a "gyári" myadmin, ezért csináltam egy sandbox mappát, levédtem .htaccess meg .htpasswd fájlokkal, ahogy az a nagy gézikönyvben le van írva, és oda feltettem a myadmint. Nincs kedvem állandóan kilincselni a tisztelt cégnél h most mi van, az se érdekel, ha átlag 1 órás a reakcióidejük, csak simán akkor akarom használni a myadmint, amikor, hát, nekem kell. Mivel az admin felületük nem használ SSL-t, így a biztonság része részemről felejtős. Mindig imádkozom és keresztet vetek, amikor bejelentkezem. :)

Ha nem is vagyok hozzáértő, azért mégis felvetem, mi lenne, ha valahogy köteleznéd a usereket erre a könyvtárvédelmi megoldásra a totális tiltás helyett. Kapnának egy mailt valami random degenerált jelszavas elérhetőséggel egy mézes-mázos ímélben, miszerint a privát myadminjuk biztonsági kockázatát csökkentendő te, mint szolgáltató szültél nekik .htaccess + .htpasswd fájlt.

Talán a figyelmességtől elolvadnának és jobban érdekeltek lennének biztonsági kérdésekben. Persze lehet h idealista vagyok, ha igen, akkor tekintsd tárgytalannak az 5letelésem.

Jelenleg 4096 -os SSL -el védett területen htaccess -el tudnak bejelentkezni a gyári debianos myadminba. Ha ssl nélkül hívják meg az urlt, akkor az apache rewrite al átdobja az ssl -re. Docroot,openbasedir,safe mode, allow url off stb be van állítva. A docroot ban van feltetlenolvassel.txt amiben le van írva, hogy nem rakunk fel myadmint és kb 2 havonta mégis lesz egy - egy.

( pgabor v | 2009. 10. 19., h – 01:05 )

vasárnap délután frissítettem, mintha megéreztem volna:D