MySQL facepalm, avagy próbálkozz sokszor, sikerülni fog!

Címkék

Röviden:


$ for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done
mysql>

CVE-2012-2122 tessék frissíteni! Már ahol van friss, javított verzió.

Hozzászólások

Én is végignéztem az összes gépet (különböző Ubuntu verziók 11.04-től felfelé, 32-64 bit vegyesen), egyiken sem ment, pedig a metasploitos bejegyzés szerint x64-es Ubuntun megy. Aztán megnéztem, de a ma reggeli automatikus frissítésekkel már jött új mysql-server.

Az egészben az a szép, hogy ez nem is MySQL bug, hanem GCC.

"This flaw was rooted in an assumption that the memcmp() function would always return a value within the range -127 to 127 (signed character). On some platforms and with certain optimizations enabled, this routine can return values outside of this range"

Ha valaki nem tudná, a memcmp, memset és társaik nem libc hívások, hanem a gcc által optimalizált inline makrók.

+1

A linux man nem részletezi, de pl MacOSX-en elvileg az vagyon írva hogy:
"The memcmp() function returns zero if the two strings are identical, oth-
erwise returns the difference between the first two differing bytes
(treated as unsigned char values, so that `\200' is greater than `\0',
for example). Zero-length strings are always identical."

Azaz jelen esetben a visszatérési érték -255,255 között lesz...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Ezt én sem értem.
Elég nagy baj a XXI. században, hogyha visszakapok egy bitkupacot, azt úgy értelmezem, ahogy kedvem tartja: ha akarom, bool, ha akarom, karakter (betű, szám, írásjel), ha akarom, szám, ha akarom, pointer...

És erre nem jó válasz az, hogy a programozónak tudnia kell, mit csinál. Szemmel láthatóan a gcc-sek/libc-sek is tudták és a MySQL-esek is tudták, mégis valahol eltévedt az információ.

Azon már csak mosolygok, hogy a C++ csúcstechnikában még mindig nincs interfész és absztrakt class (mint nyelvi elem).

Fuszenecker_Róbert

"Azon már csak mosolygok, hogy a C++ csúcstechnikában még mindig nincs interfész és absztrakt class (mint nyelvi elem)."

Nincs is rá szükség. Abstract metódusokat lehet írni, ha nem valósítasz meg egy ilyen metódust, a compiler szól. Interface-t meg tudsz írni úgy, hogy csak absztrakt metódusai vannak. Mivel van többszörös öröklés, ezért nincs különbség aközött, hogy több interface-t valósítasz meg, vagy több osztályból örökölsz.

Igaz, emiatt nyelvi szinten elveszik az az információ, hogy egy osztály class, abstract class, vagy interface, de ezt a hiányosságot lehet pótolni megfelelő elnevezések használatával (amit egyébként akkor is illik alkalmazni, ha a nyelvben meg vannak különböztetve ezen osztályok).

Taknyolás.

Tulajdonképpen nem is kellenek absztrakt fogalmak, kódolhatnánk mind a mai napig gépi kódban, majd átadunk minden... (hát függvénynek ugye nem) szubrutinnak egy memóriacímet, ahova dolgozhat, és majd az R0 regiszterben visszaad valamit, amit majd valahogyan értelmezünk.

Természetesen mindent meg lehet oldani. De ha valaminek az a célja, hogy egy interfészt definiáljon, akkor az legyen mondjuk (nem leszek túl fantázisdús) interfész. És ugyan, támogassa már a nyelv, hiszen nem elveszünk a specifikációból, hanem hozzáteszünk.

Alapvetően a bajom azzal van, hogy 2012-t írunk, és teljesen úgy érzem magam, mint 1986-ban. Nem értem ezt a maradiságot (úgy, hogy én nagyon is konzervatív vagyok).

Fuszenecker_Róbert

Szerintem a C-ben és a nagytesójában pont az (is) a jó, hogy eggyel közelebb vannak még a hardveres világhoz, mint a C# vagy a Java és barátaik. Ha valahol gondot jelent az általad hiányolt nyelvi elemek hiánya, akkor oda egyszerűen nem a C++ a megfelelő eszköz.
Nekem eddig az a tapasztalatom, hogy ha C-hez, C++-hoz nyúlok, azt általában azért teszem, mert teljesítményt akarok. Ekkor viszont előbb-utóbb ugyanezen okból úgyis nekiállok felrugdosni az OO-s szabályokat. Onnantól meg szerintem már szinte mindegy.
Szerk.: amúgy mi az, hogy nem jó válasz, hogy a programozónak tudnia kell, mit csinál? Ennyi erővel azt is mondhatnád, hogy a memóriakezelés ismerete is felesleges, mert vannak GC nyelvek.

C++ szabvány type casting:

http://www.cplusplus.com/doc/tutorial/typecasting/

Standard conversions affect fundamental data types, and allow conversions such as the conversions between numerical types (short to int, int to float, double to int...), to or from bool, and some pointer conversions. Some of these conversions may imply a loss of precision, which the compiler can signal with a warning. This can be avoided with an explicit conversion.

Nálam a gcc mélyen hallgatott arról, hogy az unsigned long-ot char-ba másoltam, pedig szerintem a C++ szabvány nem is engedi meg. Legalábbis az én olvasatom szerint.

(Tudom, hogy eredetileg C-ről volt szó, de hanyattvágott a gcc C++ automatikus konverziója)

Csak ez megint a fejlesztő bevitele a rekettyésbe: a -Wall egy jóérzésű programozóban azt a képzetet kelti, hogy minden (ALL) warning/Warnung ki lesz jelezve.

Ezek szerint van az "mindennél" még több.

Ez pont olyan, mint az "optimálisabb" szó. Ha valami optimális, azaz a legjobb, akkor attól nincsen jobb, különben más nem lehet optimális, azaz nincsen alapja az összehasonlításnak.

Fuszenecker_Róbert

Mondják az utálók. Én többször dolgoztam vegyes környezetben, és sokszor láttam olyat, hogy egy-egy probléma esetén a Windows-os kollégák csak szomorúan néztek, és gondolkodtak, hogy honnan lehetne erre a feladatra leakasztani egy célszoftvert, mert ott nincs más út. Én meg unix parancssori eszközökkel és egy kis shell scripttel megoldottam egy órán belül. A vicces kijelentésed úgy lenne korrekt, ha kiterjesztenéd azokra a problémákra is, ami más rendszerekben is felmerül és nagyon nehezen megoldható.

a Windows-os kollégák csak szomorúan néztek, és gondolkodtak, hogy honnan lehetne erre a feladatra leakasztani egy célszoftvert, mert ott nincs más út. Én meg unix parancssori eszközökkel és egy kis shell scripttel megoldottam egy órán belül.

Ott nincs más út? A Windowsra nincsenek parancssori - akár unix shell - eszközök?

Ne nézd már madárnak az embereket...

Láttál te már Windows-os informatikusokat? Mert én elég sokat. Én sose láttam egyet se, akinek eszébe jutott parancssori eszközökkel megoldani egy problémát. Értem, hogy lehetséges, csak nem jellemző (finoman szólva). Egyébként pedig vicces azt mondani, hogy Windows alatt is megoldható egy probléma unixos eszközökkel. Hát ja. Azokkal valóban megoldható.

A félreértelmezés nagyon megy. Évek óta látom, de eddig még nem sikerült személyesen megtapasztalnom. Na majd most :)

Fussunk neki újra. Milyen eszközökkel lehet Win alatt megoldani egy problémát? Céleszközökkel. Mert az oprendszer lényegében nem ad semmit a kezedbe. Azt mondod, hogy ott is lehet parancssori eszközökkel. Igen, lehet, ha felteszed őket, mert a rendszer alapból nem támogatja. Tehát célszoftvert telepítesz.

Másrészt mivel az alap rendszer nem tartalmazza (ellentétben a unixokkal), így az ottani informatikusoknak eszébe sem jut, hogy ilyesmiket használjanak. Szerintem megáll amit mondtam.

Ami nagyon megy az nálad a ferdítés.

Milyen eszközökkel lehet Win alatt megoldani egy problémát? Céleszközökkel. Mert az oprendszer lényegében nem ad semmit a kezedbe.

false statement

Azt mondod, hogy ott is lehet parancssori eszközökkel. Igen, lehet, ha felteszed őket, mert a rendszer alapból nem támogatja.

false statement

Másrészt mivel az alap rendszer nem tartalmazza (ellentétben a unixokkal), így az ottani informatikusoknak eszébe sem jut, hogy ilyesmiket használjanak.

A "nincs más út" és a "leakasztani egy célszoftvert" után szép lassan közelítünk az igazság felé, amit így kellett volna megfogalmaznod:

'az én balfasz Windowsos kollégáim nem tudták megoldani'

Mindjárt másképp néz ki a leány fekvése.

Az nem érv, hogy "Neked nincs igazad.". Még akkor se, ha nagyjából angolra fordítod. Inkább érveljünk. Nekem napi szinten többször jön elő olyan feladat, melyet valahogy így oldok meg:

prompt$ cut -d':' -f4 users.csv | sed 's/.*"\([^"]*\)".*/\1/' | sort | uniq -c | sort -nr | head -n 20

Ezt hogy lehet a legelterjedtebb Windows rendszeren megoldani? Na jó, lehet akár Win7 is, bár én céges környezetben főleg XP-t láttam, szóval az lenne az igazi megfejtés...

A feladat az, hogy egy csv állomány bizonyos mezőjének rész-sztringjének értékeinek számosságát összegezni és abból a húsz leggyakrabb előfordulást megmutatni azok számosságával. Ez nem hajánál fogva előrángatott példa, nálam legalábbis a mindennapokban sokszor előkerül ilyen jellegű feladat. Már csak az érdekesség kedvéért kíváncsi lennék a PowerShell megoldásra (ami egyébként tudomásom szerint nem része a Win XP-nek), ha valaki ide tudná írni, kérem! Érdekes, hogy sokat hallottam a PowerShell-ről, de nem láttam még egy embert se, aki a tantermen kívül használta is...

Ez még mindig nem a feladat, hanem a te megoldásod részletezése. Honnan jön a CSV-be az adat? Mire kell ez a lekérdezés?

"egy csv állomány bizonyos mezőjének"

Oké, innen kezdve, már nem cut-hoz nyúlnék. (CSV mióta :-vel van elválasztva?)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ha tenyleg tanulni akarnal, megnezned magad.

Egyekbent itt van ra pelda:
http://technet.microsoft.com/en-us/library/ee176874.aspx

Ha lusta lennel elolvasni, ez a bemenet:

Name,Department,Title
Pilar Ackerman,Research,Manager
Jonathan Haas,Finance,Finance Specialist
Ken Myer,Finance,Accountant

Feladat: osszes sort kivalasztani, ahol a department oszlop 'Finance'.

Import-Csv c:\scripts\test.txt | Where-Object {$_.department -eq "Finance"}

Csinald meg ezt bash-el ugy, hogy az oszlopok sorrendje nem fix, tehat nem feltetlen name,department,title, hanem lehet name, phone, title, department is. PS alatt ugyanigy nez ki, bash alatt csunyabb.

Nem mintha nem szeretnem nagyon a bash-t, tenyleg szuper eszkoz, de PS-ben ugyanugy meg tudsz csinalni mindent. Van, ami az egyikben csunyabb, van, ami a masikban.

----------------------
while (!sleep) sheep++;


users.csv: (utf-8)
"Lorem ipsum":"Sára":1:100
"dolor sit amet":"Manó":2:200
"consectetur adipiscing":"Rebeka":3:300
"elit":"Sára":4:400
"Aenean nulla":"Sára":5:500
"ligula":"Slomó":6:600
"rhoncus et semper":"Sára":7:700
"vitae":"Rebeka":8:800
"tempus nec":"Rebeka":9:900
"ante":"Sára":10:1000
"Donec":"Slomó":11:1100
PS> import-csv -header Jami,Name,Fisz,Fasz -delimiter : users.csv |
>> group Name -noelement |
>> sort Count -desc |
>> select -first 3
>>

Count Name
----- ----
    5 Sára
    3 Rebeka
    2 Slomó

----8<--------------------
prompt$ cut -d':' -f4 users.csv | sed 's/.*"\([^"]*\)".*/\1/' | sort | uniq -c | sort -nr | head -n 20

PS> import-csv -header Jami,Name,Fisz,Fasz -delimiter : users.csv | group Name -noelement | sort Count -desc | select -first 3
----8<--------------------

Szerintem a második megoldás olvashatóbb.
Első ránézésre legalábbis.
Ami fontos lehet a kód karbantarthatósága miatt.

Fuszenecker_Róbert

Igazad van, bár megjegyzem, hogy az elsőben van egy reguláris minta illesztés, és attól olyan csúnya, ha az nincs, akkor már szebb. És ha szépségversenyre küldeném, akkor hosszú opciókat használnék:

cut --delimiter=':' --fields=4 users.csv |
sort | uniq --count | sort --numeric-sort --reverse |
head --lines=20

Mondjuk annak, aki gyakran használ ilyet, a korábbi, rövid verzió kényelmesebben olvasható :)

És akkor most dobjuk fel a feladatot azzal, hogy átvariáljuk a mezők sorrendjét, vagy teszünk bele egy többsoros adatot tartalmazó mezőt.

Mert látom, az az apróság, hogy a PS nem karakterkupacokkal dolgozik, az elkerülte a figyelmed.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ugyanúgy ahogy mindennek, az előnyök mellett hátrányai is vannak. Pl az, hogy minél célspecifikusabb valami, annál kevésbé lehet általánosságban használni - vagyis annál több eszközt kell ismerned a kapcsolóival / fejben tartanod teljes egészében, ha minél általánosabb feladatokat akarsz lefedni.

Programozói szemszögből Unix-okon a mindig text és karakter feldolgozás mindenütt elv éppen ezért olyan szempontból nagyon hasznos, hogy kreatívabb és szabadabb tudsz lenni vele. Az van, hogy meg kell húznod a poti méterét a "kényelemesebb + több specifikus tool + több infó szükséges" között és a "kevesebb tool + kevesebbet tudnak + több általános probléma megoldhatósága" között. Nem jobb, csak másmilyen.

Szerintem amikor azon megy a fapfap, hogy kell legalább 2-3 plusz eszköz ahhoz, hogy egy strukturált adatformátumot strukturáltan ki tudd bányászni ahelyett, hogy egyből egy feldolgozható struktúrában kapod/adod az adatot.

Szóval azt nem nevezném innovációnak, hogy ahhoz kell "kreatívnak" lenni, hogy egyáltalán össze tudd kötögetni az egyes toolokat.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A 70-es években a szövegbogarászás modern-haladó dolog volt. Űrtechnika. A lyukkártyához képest tutira.
De azóta eltelt néhány esztendő.
Vannak sokkal hatékonyabb/produktívabb megoldások a piacon.
Nem mindenki óhajt lépést tartani a fejlődéssel. Biztos vannak emberek, akik mind a mai napig lúdtollal írnak.

Fuszenecker_Róbert

Értem, szóval ahelyett, hogy a szoftvert megírták volna rendesen és adnak hozzá normális céleszközöket, amellyel fel tudnád tárni a problémát, inkább külső eszközökkel kell maszatolni.

Ezt nem nevezném túl innovatívnak.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezen a válaszon sokat gondolkodtam ma, és lenne egy kérdésem. Ha az oprendszernek csak az ütemezés, az erőforrás allokáció meg a hw kezelése (meg persze még sok-sok alapfunkció, de semmi speciális) akkor mi 10G benne? Én ezt halál komolyan nem értem. Felteszek egy Ubuntu-t, az legfeljebb 3G és van benne irodai szoftver, meg fotókezelő, zenelejátszó, levelező, böngésző, és még néhány hasznos segédprogram.

Illendő...lenne, de még kettőezertizenkettőben is van, aki rácsodálkozik, hogy a zászlógomb a billentyűzeten a start menüt nyitja meg, bármikor(!). A context-menu gomb a keyboardon meg már mindennek a csimborasszója. A printscreen gombra ki se térek. Arra meg végképp nem, hogy a win8 már tapira optimalizált, s tableteken nincs billentyűzet --> kattintásfétis.

Ja hogy a shell "Kattingatással működtethető"? A kolléga felvetése az volt, hogy nincs rá alternatíva Windowson.
Miért kéne, hogy benne legyen egy 11 éves rendszerben? Azóta volt több új termékük is... Az NVIDIA/AMD drivered része az alaptelepítőnek?

De akkor ott a VBScript mint alternatíva.

Írtam a srácnak egy alternatívát Windows alatt a shellre. Ha mindenképpen szeretnél belekötni, akkor legalább olyan dolgot írj ami egy összehasonlítási alap lehet a másik oldallal szemben. Az a kérdés, hogy lehet-e benne kattintgatni az egy baromság, mert a shell-ben sem lehet kattintgatni, nem is volt szempont. Sajnos ilyen hülye kérdésre nem lehet, csak egy ironikus költői kérdéssel "válaszolni"...

A második kérdésed már inkább mondható relevánsnak. Ezért hoztam alternatívaként a VBScriptet...

"a videokártyád mióta része az oprendszerednek?" - Ezt meg akkor gondolom lezártuk.

Attól, hogy egy halom Linuxosnak parancssor fétise van, az egyrészt nem jelenti azt, hogy Windowson az összes létező feladatot azzal kellene megoldani. Már csak azért is, mert - breaking news - szimplán nem ez az elsődleges út. De lehet, hogy csak nekem nem jut eszembe egy csillag alakú csavart lapos csavarhúzóval becsavarni, ha nem muszáj.

Bár egyébként megjegyzem, sok esetben lehetőség van rá, ld. PowerShell vagy egy rakás MS által adott vagy szállított eszköz, csak ismerni kellene.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Merről lehet kihasználni? Csak shellen vagy akár php-ból is kihasználható?

Hát, ha megnézed a linken, hogy mely linuxok érintettek, akkor beláthatod, hogy bőven lehetnek éles szerverek is.
A dolog valószínűleg remote is működik, szóval a sok tűzfal nélküli huszár majd kapja az ívet. Igazából egy nmap-et kell elindítani ip tartományokon, ha találsz open portot, már szórhatod is...
Várom, hogy a következő napokban hányszor fogom hallani, hogy szervereket lepucoltak :).
--
Discover It - Have a lot of fun!

FreeBSD-n 5.5.20-as mysql-el nem működik az exploit :)

Fordítottam gcc-vel egy memcmp-t. Alapból egy kegyetlen lassú szart pakol bele, ami 1,0,-1 értékekkel tér vissza.

    movl $.LC0, %esi
    movl $.LC1, %edi
    movl $5, %ecx
    repz
    cmpsb
    seta %al
    setb %dl
    subb %dl, %al

Gondolom optimalizáltak valamit, mert ugye 8-byte-onként is össze lehetne hasonlítani, nem muszáj egyesével küzdeni.

:)

Fyi, az h melyik megoldas hatekonyabb, erosen fugg a felhasznalas modjatol. Kis meretu tombokre a rep cmpsb/stosb/movs (ha ismert a hasonlitani kivant tombok hossza es az oszthato kettovel/neggyel, akkor ezen megfelelo parjaik) jobb, mint a simd optimalizalt valtozat.

---
pontscho / fresh!mindworkz

Egyszer írtam egy PERL kódot, ahol regexp-pel parsoltam 1-2 megás fájlokat.
Az idő 98.5%-ában memcpy-zott, a maradék 1.5%-ban dolgozott is.

Szóval ebben az esetben egy optimalizált memcpy 3x-osára növelhette volna a sebességet.

(A megoldás az lett, hogy kisebb dinamikus méretű ablakokon futtattam a regexp-et (~100 byte), mert az idióta PERL mindig memcpy-zta a puffert. Kb. 30-szorosára nőtt a sebesség.)