CVE-2017-10235: VirtualBox E1000 डिवाइस बफर ओवरफ्लो

परिचय

निम्नलिखित दस्तावेज़ VirtualBox v5.1.22 में पाए गए एक बग का विवरण देता है (अब v5.1.24 में ठीक किया गया है), जो गेस्ट डिवाइस एमुलेशन घटक DevE1000 (Intel 82540EM Ethernet Controller Emulation), फ़ंक्शन e1kFallbackAddToFrame में है, जो होस्ट में बफर ओवरफ्लो का कारण बनता है जब गेस्ट OS पर हमलावर का नियंत्रण होता है।

इस बग को Oracle ने जुलाई 2017 के CPU में जारी CVE-2017-10235 के साथ स्वीकार किया था।

इस भेद्यता की पुष्टि Linux (Ubuntu 16.04) और Windows (v8.1) दोनों होस्ट पर एक Linux (Ubuntu 16.04) गेस्ट चलाकर की गई थी, लेकिन यह भेद्यता विभिन्न होस्ट/गेस्ट संयोजनों में ट्रिगर हो सकती है। सभी परिदृश्यों में डिफ़ॉल्ट नेटवर्क कॉन्फ़िगरेशन माना जाता है: केवल एक नेटवर्क एडेप्टर NAT से जुड़ा और प्रकार Intel PRO/1000 MT Desktop (82540EM) का।

चूंकि नियंत्रण संरचनाओं (फ़ंक्शन पॉइंटर्स सहित) को हमलावर-नियंत्रित डेटा से ओवरराइट किया जा सकता है, यह मानना सुरक्षित है कि कई परिदृश्यों में रिमोट कोड एक्ज़ीक्यूशन (RCE) प्राप्त किया जा सकता है। Oracle ने इस बग को कम CVSS स्कोर दिया क्योंकि उन्होंने इसे None गोपनीयता जोखिम और Low अखंडता जोखिम माना, जो हमारी राय में इस बग की पूर्ण संभावित क्षति को नहीं दर्शाता है (RCE की संभावना का स्पष्टीकरण नीचे दिया गया है)।

बग विवरण और शोषण

VirtualBox कोड जो [Intel 82540EM Ethernet Controller][intel_manual] के एमुलेशन को लागू करता है (फ़ाइल [src/VBox/Devices/Network/DevE1000.cpp][DevE1000_cpp] में), फ़ंक्शन [e1kFallbackAddToFrame][e1kFallbackAddToFrame] में, हार्डवेयर TCP सेगमेंटेशन को लागू करता है:


static int e1kFallbackAddToFrame(PE1KSTATE pThis, E1KTXDESC *pDesc,
                                bool fOnWorkerThread)
{
#ifdef VBOX_STRICT
   PPDMSCATTERGATHER pTxSg = pThis->CTX_SUFF(pTxSg);
   Assert(e1kGetDescType(pDesc) == E1K_DTYP_DATA);
   Assert(pDesc->data.cmd.fTSE);
   Assert(!e1kXmitIsGsoBuf(pTxSg));
#endif

   uint16_t u16MaxPktLen = pThis->contextTSE.dw3.u8HDRLEN +
                           pThis->contextTSE.dw3.u16MSS;
   Assert(u16MaxPktLen != 0);
   Assert(u16MaxPktLen < E1K_MAX_TX_PKT_SIZE);

यह फ़ंक्शन सही ढंग से जाँचता है कि अधिकतम TX पैकेट लंबाई (u16MaxPktLen) मानक अधिकतम 16288 बाइट्स (E1K_MAX_TX_PKT_SIZE) से कम है, लेकिन यह Assert मैक्रो के रूप में जाँच करता है जो रिलीज़ बिल्ड में अक्षम हो जाएगा, प्रभावी रूप से अंतिम उपयोगकर्ता के लिए जाँच को बेकार छोड़ देता है। इसकी तुलना समान फ़ंक्शन [e1kAddToFrame][e1kAddToFrame] से की जा सकती है, जो Assert के बजाय एक स्पष्ट if के साथ जाँच लागू करता है:


static bool e1kAddToFrame(PE1KSTATE pThis, RTGCPHYS PhysAddr,
                         uint32_t cbFragment)
{
   PPDMSCATTERGATHER   pTxSg    = pThis->CTX_SUFF(pTxSg);
   bool const          fGso     = e1kXmitIsGsoBuf(pTxSg);
   uint32_t const      cbNewPkt = cbFragment + pThis->u16TxPktLen;

   if (RT_UNLIKELY( !fGso && cbNewPkt > E1K_MAX_TX_PKT_SIZE ))
   {
       E1kLog(("%s Transmit packet is too large: %u > %u(max)\n",
               pThis->szPrf, cbNewPkt, E1K_MAX_TX_PKT_SIZE));
       return false;
   }

सामान्य फ़ंक्शन (e1kAddToFrame) और फ़ॉलबैक (e1kFallbackAddToFrame) के उपयोग के बीच का अंतर e1kXmitDesc() में तय किया जाता है और यह दो कारकों पर निर्भर करता है: कि डेटा/कॉन्टेक्स्ट डिस्क्रिप्टर में TSE फ्लैग सक्षम है (गेस्ट मशीन का उपयोग करके OS द्वारा नियंत्रित) और GSO फ्लैग अक्षम है। उत्तरार्द्ध कई कारकों पर निर्भर करता है, और इसलिए इसे अक्षम करने के कई तरीके हैं, लेकिन सबसे सुविधाजनक है लूपबैक मोड को सक्षम करना, जो रिसीव कंट्रोल रजिस्टर (RCTL.LBM बिट्स) के माध्यम से कॉन्फ़िगर किया जाता है, जो गेस्ट OS द्वारा भी नियंत्रित होता है।

लूपबैक मोड को सक्षम करने से फ़ंक्शन [e1kXmitAllocBuf][e1kXmitAllocBuf] PDM स्कैटर/गैदर बफर के आवंटन के लिए aTxPacketFallback बफर (Transmit packet buffer use for TSE fallback and loopback) का उपयोग करेगा, जिसकी लंबाई 16288 बाइट्स (E1K_MAX_TX_PKT_SIZE) है, और यह संकेत देगा कि GSO अक्षम हो जाएगा (pvUser में NULL सेट करके)।


if (RT_LIKELY(GET_BITS(RCTL, LBM) != RCTL_LBM_TCVR))
{

  ...

}
else
{
 /* Create a loopback using the fallback buffer and preallocated SG. */
 AssertCompileMemberSize(E1KSTATE, uTxFallback.Sg, 8 * sizeof(size_t));
 pSg = &pThis->uTxFallback.Sg;
 pSg->fFlags      = PDMSCATTERGATHER_FLAGS_MAGIC |
                    PDMSCATTERGATHER_FLAGS_OWNER_3;
 pSg->cbUsed      = 0;
 pSg->cbAvailable = 0;
 pSg->pvAllocator = pThis;
 pSg->pvUser      = NULL; /* No GSO here. */
 pSg->cSegs       = 1;
 pSg->aSegs[0].pvSeg = pThis->aTxPacketFallback;
 pSg->aSegs[0].cbSeg = sizeof(pThis->aTxPacketFallback);
}

इससे फ़ंक्शन e1kXmitIsGsoBuf (अंदर [e1kXmitDesc][e1kXmitDesc]) का कॉल False लौटाएगा और, डेटा डिस्क्रिप्टर में TSE सक्षम होने के साथ, निष्पादन प्रवाह [e1kFallbackAddToFrame][e1kFallbackAddToFrame_call] (सुरक्षित फ़ंक्शन e1kAddToFrame के सही जाँच के साथ) की ओर जाएगा।


/*
 * Add the descriptor data to the frame.  If the frame is complete,
 * transmit it and reset the u16TxPktLen field.
 */
if (e1kXmitIsGsoBuf(pThis->CTX_SUFF(pTxSg)))
{

  ...

}
else if (!pDesc->data.cmd.fTSE)
{

  ...

}
else
{
    STAM_COUNTER_INC(&pThis->StatTxPathFallback);
    rc = e1kFallbackAddToFrame(pThis, pDesc, fOnWorkerThread);
}

e1kFallbackAddToFrame के अंदर, ऊपर उल्लिखित जाँच रिलीज़ बिल्ड में अक्षम होने के कारण, MSS को मनमाने ढंग से बड़ा (HDRLEN तक 64K तक) सेट किया जा सकता है, इस प्रकार [e1kFallbackAddSegment][e1kFallbackAddSegment_call] को एक मनमाने ढंग से बड़ा DTALEN पास करने की अनुमति देता है:


/*
* Carve out segments.
*/
int rc;
do
{
 /* Calculate how many bytes we have left in this TCP segment */
 uint32_t cb = u16MaxPktLen - pThis->u16TxPktLen;
 if (cb > pDesc->data.cmd.u20DTALEN)
 {
     /* This descriptor fits completely into current segment */
     cb = pDesc->data.cmd.u20DTALEN;
     rc = e1kFallbackAddSegment(pThis, pDesc->data.u64BufAddr, cb,
                 pDesc->data.cmd.fEOP /*fSend*/, fOnWorkerThread);

फ़ंक्शन [e1kFallbackAddSegment][e1kFallbackAddSegment] इस मान (अब आर्गुमेंट u16Len के रूप में) का उपयोग गेस्ट मेमोरी से होस्ट मेमोरी में बफर aTxPacketFallback में कॉपी करने के लिए करेगा (PDMDevHlpPhysRead के माध्यम से), इस लंबाई की आगे कोई जाँच किए बिना, इस प्रकार बफर ओवरफ्लो (16288 बाइट्स की बफर क्षमता के साथ 64K तक का मेमोरी आकार) का कारण बनेगा।


static int e1kFallbackAddSegment(PE1KSTATE pThis, RTGCPHYS PhysAddr,
                   uint16_t u16Len, bool fSend, bool fOnWorkerThread)
{
    int rc = VINF_SUCCESS;
    /* TCP header being transmitted */
    struct E1kTcpHeader *pTcpHdr = (struct E1kTcpHeader *)
            (pThis->aTxPacketFallback + pThis->contextTSE.tu.u8CSS);
    /* IP header being transmitted */
    struct E1kIpHeader *pIpHdr = (struct E1kIpHeader *)
            (pThis->aTxPacketFallback + pThis->contextTSE.ip.u8CSS);

    E1kLog3(("%s e1kFallbackAddSegment: Length=%x, remaining payload=%x,
             header=%x, send=%RTbool\n", pThis->szPrf, u16Len,
             pThis->u32PayRemain, pThis->u16HdrRemain, fSend));
    Assert(pThis->u32PayRemain + pThis->u16HdrRemain > 0);

    PDMDevHlpPhysRead(pThis->CTX_SUFF(pDevIns), PhysAddr,
                      pThis->aTxPacketFallback + pThis->u16TxPktLen, u16Len);

संभावित RCE

इस भेद्यता को RCE के लिए अधिक अनुकूल बनाने के लिए, यह ध्यान दिया जाना चाहिए कि बफर के ठीक बाद का वेरिएबल इसका इंडेक्स (u16TxPktLen) है, जिसका उपयोग उस पर लिखने के लिए किया जाता है (PDMDevHlpPhysRead के आर्गुमेंट में ऑफसेट के रूप में)। प्रारंभिक बफर ओवरफ्लो (लंबाई E1K_MAX_TX_PKT_SIZE + 2 बाइट्स के पहले डेटा डिस्क्रिप्टर के कारण) के साथ इस मान को नियंत्रित करने से फिर (दूसरे डेटा डिस्क्रिप्टर के साथ PDMDevHlpPhysRead के दूसरे कॉल में) बफर से 64K तक की दूरी पर किसी भी मेमोरी एड्रेस पर लिखा जा सकता है, बिना बीच की सारी मेमोरी को ओवरराइट किए (जो हमले को और जटिल बनाता, संभावित क्रैश से बचने की कोशिश में)।

vbox_cve_2017_10235

सबसे लोकप्रिय

CVE-2017-10235: VirtualBox E1000 डिवाइस बफर ओवरफ्लो

परिचय

बग विवरण और शोषण

संभावित RCE