Újabb hibajavító változat jelent meg a PHP-ből
2012-05-10T16:13:03+02:00
2012-05-10T23:50:12+02:00
2022-07-19T05:12:55+02:00
  • Te már a kezdőhozzászólásoddal kiszálltál. Csak idáig tartott amíg rájöttél erre.
    Mutasd a teljes hozzászólást!
  • ok, en itt kiszaltam.

    Tyrael
    Mutasd a teljes hozzászólást!
  • csak annyira venned a faradtsagot, hogy ha mar fikazni akarod a projectet

    Melyik projektet, zsenikém? A PHP-t? Hiszen pont én szoktam megvédeni az alaptalan kritikákkal szemben itt. Ezek után nyilván égek, hogy "fikázzam". Ami adott esetben persze nem más, mint az, hogy megírtam egy valóban létező sebezhetőségét - ahogy azt teszem más nyelvek, platformok esetében is, és aminek oka ill. célja nem a projekt "fikázása", hanem az, hogy aki futtat, használ ilyen szervert, az értesüljön arról, hogy ha nem frissíti a telepítését, akkor sebezhető lesz/marad a gépe.

    Egyéb hülyeség amit szeretnél kiírni magadból?
    Mutasd a teljes hozzászólást!
  • szoval csak a trollkodas.
    :(

    csak annyira venned a faradtsagot, hogy ha mar fikazni akarod a projectet, hogy raszansz egy fel orat hogy utanaolvass, ahelyett hogy ures kapura fole losz, es utana hoborogsz. :/

    Tyrael
    Mutasd a teljes hozzászólást!
  • "It has also come to our attention that some sites use an insecure cgiwrapper script to run PHP. These scripts will use $* instead of "$@" to pass parameters to php-cgi which causes a number of issues."

    itt bujik meg a hivatalos bejelentesben a remote code execution-re valo hivatkozas.

    Na, ja. Ennyi erővel azt is mondhattad volna, hogy a repülő spagettiszörnyre vonatkozó utalás bújik meg benne. Mert hogy az is kb. annyira van nevesítve benne, mint a remote code execution. Ráadásul ez a két mondat nem is magában a PHP-ban, hanem egyes - nyilvánvalóan a PHP-tól független - cgiwrapper scriptekben lévő problémáról szól.

    ezen felul a php.net-es hibajegyben is szerepel az RCE: PHP :: Sec Bug #61910 :: VU#520827 - PHP-CGI query string parameter vulnerability

    Igen. Csak éppen az a ticket nem más, mint az eredeti CVE copy-paste változata, és nyilvánvalóan ugyanaz a forrása, mint a CVE-nek. _Nem_ a PHP fejlesztőcsapata, hanem az eredeti felfedező - aki, mint már megírtam, ugyan valóban azt állította, hogy kódfuttatásra is használható, de egyrészt ennek ellenőrzésére nem biztosított bárki számára egyszerűen hozzáférhető módszert, másrészt ezt a PHP-sok sehol nem erősítették meg.

    A helyzet tehát az, hogy van egy egyetlen személy - a felfedező által - bedobott állítás, ami szerint RCE-re is használható a sebezhetőség; amit azonban közvetlenül ellenőrizni nem lehet, és amit a PHP-sok se erősítettek meg sehol. És én ezt az egyszerűen ellenőrizhetetlen és sehol meg nem erősített információt nem írtam meg. Csak a hivatalosan is megerősítettet.

    Micsoda egy mocskos szemét vagyok. Nem úgy, mint te, aki ugyan a tényeknek közvetlenül ellentmondó, nettó hülyeséget ír (ti. hogy a közleményben említve lett volna az RCE), ez alapján lecsesz, majd amikor kiderül, hogy tévedett, akkor nem, hogy bocsánatot kérne az újabb alaptalan beszólásért, de még tovább kardoskodik a hülyesége mellett.

    ha a reszletekre vagy kivancsi, akkor az eredeti reporter postjaban

    Köszi, de tisztában vagyok a részletekkel. Én inkább arra lennék kíváncsi, hogy mikor kérsz bocsánatot, mert már megint alaptalanul kritizáltál (mint gyakorlatilag mindig, ahányszor beesel ide), és mikor ismered be, hogy itt egyedül te írtál a valóságnak nem megfelelő információkat. Nos?
    Mutasd a teljes hozzászólást!
  • "It has also come to our attention that some sites use an insecure cgiwrapper script to run PHP. These scripts will use $* instead of "$@" to pass parameters to php-cgi which causes a number of issues."

    itt bujik meg a hivatalos bejelentesben a remote code execution-re valo hivatkozas.

    ha a reszletekre vagy kivancsi, akkor az eredeti reporter postjaban (http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/) vagy a php-security.net-en (New PHP-CGI exploit: CVE-2012-1823, PoC exploit - Yet Another PHP Security Blog) bovebb leirast.

    ezen felul a php.net-es hibajegyben is szerepel az RCE: PHP :: Sec Bug #61910 :: VU#520827 - PHP-CGI query string parameter vulnerability valamint az osszes disztro/vendor rce-kent hivatkozik a hibara (Debian -- Security Information -- DSA-2465-1 php5 CVE-2012-2311 in Ubuntu CVE-2012-1823 in Ubuntu access.redhat.com

    megemlitettem irc-n, hogy jobban ki kellene emelni ezt a vektort a bejelentesben, de nem fuzok hozza tul sok remenyt, hogy ez megvalosul. :/

    szerintem ennyibol eleg nyilvanvalo, hogy mi a helyzet, de nyilvan ha csak trollkodni akarsz, akkor zarjuk le itt a szalat.

    ps: meg mielott belekotnel, nem, nem (csak) a cgiwrapperben volt a bug, lasd a relavans modositasokat itt.

    Tyrael
    Mutasd a teljes hozzászólást!
  • A kozlemenyben nem esik rola szo de a felfedezok keszitettek egy szep leirast: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/

    Amiben csak bemondásra közlik, hogy szerintük tetszőleges kódot is lehet ezzel futtatni - de módszert ennek ellenére nem írják le; pedig (szintén az ő szavaikkal élve) az triviális. Bezzeg azt, hogy hogyan lehet forrásokat kiolvasni vele, azt oldalakon keresztül elemzik.

    Nyilván oka van annak, hogy a PHP nem írt a tetszőleges kódfuttatás lehetőségéről a kiadott közleményében, hanem csak arról, hogy forrásokat lehet lopni vele. Én meg azt írtam meg, amit ők írtak. Ebben te pontosan hol is látod a hibát?

    ha mar teved(ami nem baj mert mindenki tevedhet)

    Mármint, hogy ki tévedett? Tyrael? Mert a dolgok jelenlegi állása szerint egyedül az ő esetében áll meg az állítás, hogy téves információkat közölt - ti. hogy a közelményben benne lett volna a tesztőleges kódfuttatás lehetősége.

    Vagy szerinted én hol állítottam valótlant, téveset?
    Mutasd a teljes hozzászólást!
  • Pontosan, viszont ket kattintassal el lehet jutni a kozlemenytol a cikkig es ha mar valaki maga is publikalasra adja a fejet akkor tisztaban lehetne a tenyekkel, vagy ha mar teved(ami nem baj mert mindenki tevedhet) akkor ne oltogassa azt aki felhivja erre a figyelmet.
    Mutasd a teljes hozzászólást!
  • Tehát Sting jól értelmezte a közleményt, csak nem találta meg felfedezők leírását.
    Mutasd a teljes hozzászólást!
  • A kozlemenyben nem esik rola szo de a felfedezok keszitettek egy szep leirast: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/

    This is a detailed discussion of the generic PHP-CGI remote code execution bug we found while playing Nullcon CTF. We found that giving the query string "?-s" somehow resulted in the "-s" command line argument being passed to php, resulting in source code disclosure. We explored this bug further and managed to improve our exploit to remote code execution
    Mutasd a teljes hozzászólást!
  • mar a masodik hirt kozlod, es meg mindig nem sikerult ertelmezni a kozlemenyt. a CVE-2012-2311 nem csak a forraskodlopast, hanem tavoli kodfuttatast tesz lehetove.

    Aha. Tehát nekem nem sikerült értelmezni a közleményt - de neked igen. Akkor biztos nem jelent gondot neked megmutatnod, hogy a PHP.net a hibáról kiadott közelményében egészen pontosan hol is esik szó tetszőleg programkód futtatásáról:


    "There is a vulnerability in certain CGI-based setups (Apache+mod_php and nginx+php-fpm are not affected) that has gone unnoticed for at least 8 years. Section 7 of the CGI spec states:

    Some systems support a method for supplying a [sic] array of strings to the CGI script. This is only used in the case of an `indexed' query. This is identified by a "GET" or "HEAD" HTTP request with a URL search string not containing any unencoded "=" characters.

    So, requests that do not have a "=" in the query string are treated differently from those who do in some CGI implementations. For PHP this means that a request containing ?-s may dump the PHP source code for the page, but a request that has ?-s&=1 is fine.

    A large number of sites run PHP as either an Apache module through mod_php or using php-fpm under nginx. Neither of these setups are vulnerable to this. Straight shebang-style CGI also does not appear to be vulnerable.

    If you are using Apache mod_cgi to run PHP you may be vulnerable. To see if you are, just add ?-s to the end of any of your URLs. If you see your source code, you are vulnerable. If your site renders normally, you are not.

    To fix this, update to PHP 5.3.12 or PHP 5.4.2.

    We recognize that since CGI is a rather outdated way to run PHP, it may not be feasible to upgrade these sites to a modern version of PHP. An alternative is to configure your web server to not let these types of requests with query strings starting with a "-" and not containing a "=" through. Adding a rule like this should not break any sites. For Apache using mod_rewrite it would look like this:

    RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
    RewriteRule ^(.*) $1? [L]

    If you are writing your own rule, be sure to take the urlencoded ?%2ds version into account.

    Making a bad week worse, we had a bug in our bug system that toggled the private flag of a bug report to public on a comment to the bug report causing this issue to go public before we had time to test solutions to the level we would like. Please report any issues via bugs.php.net.

    For source downloads of PHP 5.3.12 and PHP 5.4.2 please visit our downloads page, Windows binaries can be found on windows.php.net/download/. A ChangeLog exists."

    -- közlemény vége --


    Én egyedül azt látom benne, hogy "a request containing ?-s may dump the PHP source code for the page" - de biztos vagyok benne, hogy te majd megmutatod nekem, hogy hol szerepel benne az, hogy "execution of arbitrary code", vagy valami ilyesmi is.

    Vagy kiderül, hogy kettőnk közül nem én vagyok az aki nem tudta értelmezni a közleményt - vagy esetleg már azt sem tudja mi a különbség a "közlemény" és egy "biztonsági értesítő" között? Az nem lehet. Vagy igen?

    "a masik hiba(CVE-2012-2329) pedig a apache_request_headers fuggveny implementaciojaban van jelen, emiatt csak ott kihasznalhato, ahol ez a fuggveny hasznalva van."
    Miért, állított valaki mást? Ki? Hol?
    Mutasd a teljes hozzászólást!
  • mar a masodik hirt kozlod, es meg mindig nem sikerult ertelmezni a kozlemenyt.
    a CVE-2012-2311 nem csak a forraskodlopast, hanem tavoli kodfuttatast tesz lehetove.

    a masik hiba(CVE-2012-2329) pedig a apache_request_headers fuggveny implementaciojaban van jelen, emiatt csak ott kihasznalhato, ahol ez a fuggveny hasznalva van.

    Tyrael
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd