Nytro

[h=3]CVE-2010-0232: Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack[/h]Thursday, January 21, 2010 Two days ago, Tavis Ormandy has published one of the most interesting vulnerabilities I've seen so far. It's one of those rare, but fascinating design-level errors dealing with low-level system internals. Its exploitation requires skills and ingenuity. The vulnerability lies in Windows' support for Intel's hardware 8086 emulation support (virtual-8086, or VM86) and is believed to have been there since Windows NT 3.1 (1993!), making it 17 years old. It uses two tricks that we have already published on this blog before, the #GP on pre-commit handling failure and the forging of cs:eip in VM86 mode. This was intended to be mentioned in our talk at PacSec about virtualization this past November, but Tavis had agreed with Microsoft to postpone the release of this advisory. Tavis was kind enough to write a blog post about it, you can read it below: From Tavis Ormandy: I've just published one of the most interesting bugs I've ever encountered, a simple authentication check in Windows NT that can incorrectly let users take control of the system. The bug exists in code hidden deep enough inside the kernel that it's gone unnoticed for as long as NT has existed. If you've ever tried to run an MS-DOS or Win16 application on a modern NT machine, the chances are it worked. This is an impressive feat, these applications were written for a completely different execution environment and operating system, and yet still work today and run at almost native speed. The secret that makes this possible behind the scenes is Virtual-8086 mode. Virtual-8086 mode is a hardware emulation facility built into all x86 processors since the i386, and allows modern operating systems to run 16-bit programs designed for real mode with very little overhead. These 16-bit programs run in a simulated real mode environment within a regular protected mode task, allowing them to co-exist in a modern multitasking environment. Support for Virtual-8086 mode requires a monitor, the collective name for the software that handles any requests the program makes. These requests range from handling sensitive instructions to mapping low-level services onto system calls and are implemented partially in kernel mode and partially in user mode. In Windows NT, the user mode component is called the NTVDM subsystem, and it interacts with the kernel via a native system service called NtVdmControl. NtVdmControl is unusual because it's authenticated, only authorised programs are permitted to access it, which is enforced using a special process flag called VdmAllowed which the kernel verifies is present before NtVdmControl will perform any action; if you don't have this flag, the kernel will always return STATUS_ACCESS_DENIED. The bug we're talking about today involves how BIOS service calls are handled, which are a low level way of interacting with the system that's needed to support real-mode programs. The kernel implements BIOS service calls in two stages, the second stage begins when the interrupt handler for general protection faults (often shortened to #GP in technical documents) detects that the system has completed the first stage. The details of how BIOS service calls are implemented are unimportant, what is important is that the two stages must be perfectly synchronised, if the kernel transitions to the second stage incorrectly, a hostile user can take advantage of this confusion to take control of the kernel and compromise the system. In theory, this shouldn't be a problem, Microsoft implemented a check that verifies that the trap occurred at a magic address (actually, a cs:eip pair) that unprivileged users can't reach. The check seems reasonable at first, the hardware guarantees that unprivileged code can't arbitrarily make itself more privileged without a special request, and even if it could, only authorised programs are permitted to use NtVdmControl() anyway. Unfortunately, it turns out these assumptions were wrong. The problem I noticed was that although unprivileged code cannot make itself more privileged arbitrarily, Virtual-8086 mode makes testing the privilege level of code more difficult because the segment registers lose their special meaning. This is because In protected mode, the segment registers (particularly ss and cs) can be used to test privilege level, however in Virtual-8086 mode they're used to create far pointers, which allow 16-bit programs to access the 20-bit real address space. However, I still couldn't abuse this fact because NtVdmControl() can only be accessed by authorised programs, and there's no other way to request pathological operation on Virtual-8086 mode tasks. I was able to solve this problem by invoking the real NTVDM subsystem, and then loading my own code inside it using a combination of CreateRemoteThread(), VirtualAllocEx() and WriteProcessMemory(). Finally, I needed to find a way to force the kernel to transition to the vulnerable code while my process appeared to be privileged. My solution to this was to make the kernel fault when returning to user mode from kernel mode, thus creating the appearance of a legitimate trap for the fabricated execution context that I had installed. These steps all fit together perfectly, and can be used to convince the kernel to execute my code, giving me complete control of the system. Conclusion Could Microsoft have avoided this issue? It's difficult to imagine how, errors like this will generally elude fuzz testing (In order to observe any problem, a fuzzer would need to guess a 46-bit magic number, as well as setup an intricate process state, not to mention the VdmAllowed flag), and any static analysis would need an incredibly accurate model of the Intel architecture. The code itself was probably resistant to manual audit, it's remained fairly static throughout the history of NT, and is likely considered forgotten lore even inside Microsoft. In cases like this, security researchers are sometimes in a better position than those with the benefit of documentation and source code, all abstraction is stripped away and we can study what remains without being tainted by how documentation claims something is supposed to work. If you want to mitigate future problems like this, reducing attack surface is always the key to security. In this particular case, you can use group policy to disable support for Application Compatibility (see the Application Compatability policy template) which will prevent unprivileged users from accessing NtVdmControl(), certainly a wise move if your users don't need MS-DOS or Windows 3.1 applications. Posted by Julien Tinnes at 7:48 AM Sursa: cr0 blog: CVE-2010-0232: Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack

[h=3]Bypassing Linux' NULL pointer dereference exploit prevention (mmap_min_addr)[/h]Friday, June 26, 2009 EDIT3: Slashdot, the SANS Institute, Threatpost and others have a story about an exploit by Bradley Spengler which uses our technique to exploit a null pointer dereference in the Linux kernel. EDIT2: As of July 13th 2009, the Linux kernel integrates our patch (2.6.31-rc3). Our patch also made it into -stable. EDIT1: This is now referenced as a vulnerability and tracked as CVE-2009-1895 NULL pointers dereferences are a common security issue in the Linux kernel. In the realm of userland applications, exploiting them usually requires being able to somehow control the target's allocations until you get page zero mapped, and this can be very hard. In the paradigm of locally exploiting the Linux kernel however, nothing (before Linux 2.6.23) prevented you from mapping page zero with mmap() and crafting it to suit your needs before triggering the bug in your process' context. Since the kernel's data and code segment both have a base of zero, a null pointer dereference would make the kernel access page zero, a page filled with bytes in your control. Easy. This used to not be the case, back in Linux 2.0 when the kernel's data segment's base was above PAGE_OFFSET and the kernel had to explicitely use a segment override (with the fs selector) to access data in userland. The same rough idea is now used in PaX/GRSecurity's UDEREF to prevent exploitation of "unexpected to userland kernel accesses" (it actually makes use of an expand down segment instead of a PAGE_OFFSET segment base, but that's a detail). Kernel developpers tried to solve this issue too, but without resorting to segmentation (which is considered deprecated and is mostly not available on x86_64) and in a portable (cross architectures) way. In 2.6.23, they introduced a new sysctl, called vm.mmap_min_addr, that defines the minimum address that you can request a mapping at. Of course, this doesn't solve the complete issue of "to userland pointer dereferences" and it also breaks the somewhat useful feature of being able to map the first pages (this breaks Dosemu for instance), but in practice this has been effective enough to make exploitation of many vulnerabilities harder or impossible. Recently, Tavis Ormandy and myself had to exploit such a condition in the Linux kernel. We investigated a few ideas, such as: using brk() creating a MAP_GROWSDOWN mapping just above the forbidden region (usually 64K) and segfaulting the last page of the forbidden region obscure system calls such as remap_file_pages putting memory pressure in the address space to let the kernel allocate in this region using the MAP_PAGE_ZERO personality All of them without any luck at first. The LSM hook responsible for this security check was correctly called every time. So what does the default security module do in cap_file_mmap? This is the relevant code (in security/capability.c on recent versions of the Linux kernel): if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO)) return -EACCES; return 0; Meaning that a process with CAP_SYS_RAWIO can bypass this check. How can we get our process to have this capability ? By executing a setuid binary of course! So we set the MMAP_PAGE_ZERO personality and execute a setuid binary. Page zero will get mapped, but the setuid binary is executing and we don't have control anymore. So, how do we get control back ? Using something such as "/bin/su our_user_name" could be tempting, but while this would indeed give us control back, su will drop privileges before giving us control back (it'd be a vulnerability otherwise!), so the Linux kernel will make exec fail in the cap_file_mmap check (due to the MMAP_PAGE_ZERO personality). So what we need is a setuid binary that will give us control back without going through exec. We found such a setuid binary that is installed on many Desktop Linux machines by default: pulseaudio. pulseaudio will drop privileges and let you specify a library to load though its -L argument. Exactly what we needed! Once we have one page mapped in the forbidden area, it's game over. Nothing will prevent us from using mremap to grow the area and mprotect to change our access rights to PROT_READ|PROT_WRITE|PROT_EXEC. So this completely bypasses the Linux kernel's protection. Note that apart from this problem, the mere fact that MMAP_PAGE_ZERO is not in the PER_CLEAR_ON_SETID mask and thus is allowed when executing setuid binaries can be a security issue: being able to map page zero in a process with euid=0, even without controlling its content could be useful when exploiting a null pointer vulnerability in a setuid application. We believe that the correct fix for this issue is to add MMAP_PAGE_ZERO to the PER_CLEAR_ON_SETID mask. PS: Thanks to Robert Swiecki for some help while investigating this. Posted by Julien Tinnes at 11:37 AM Sursa: cr0 blog: Bypassing Linux' NULL pointer dereference exploit prevention (mmap_min_addr)

[h=3]Local bypass of Linux ASLR through /proc information leaks[/h]Wednesday, April 22, 2009 EDIT2: Thanks to the efforts of Jake Edge who noticed our presentation, /proc/pid/stat information leak is now at least partially patched in mainline kernel, since 2.6.27.23 EDIT1: This is featured in an LWN article by Jake Edge Tavis Ormandy and myself talked about locally bypassing address space layout randomization (ASLR) in Linux in a lightning talk at CanSecWest. From Linux 2.6.12 to Linux 2.6.21, you could completely bypass ASLR when targeting local processes by reading /proc/pid/maps. Since Linux 2.6.22, if you cannot ptrace "pid", then you will see an empty /proc/pid/maps. It has been known for at least 7 years now that /proc/pid/stat and /proc/pid/wchan could also leak sensitive information. Reading this information has been prevented in GRSecurity since the beginning as well as in this patch. The question was: could you exploit this information to bypass ASLR in practice? If you want to find out, it's easy: we've just published the slides and Tavis' tool! Posted by Julien Tinnes at 4:21 PM Sursa: cr0 blog: Local bypass of Linux ASLR through /proc information leaks

[h=3]History of memory corruption vulnerabilities and exploits[/h] I came across a great paper, “Memory Errors: The Past, the Present, and the Future” by van der Veen et al. The authors cover the history of memory corruption errors as well as exploitation and countermeasures. I think there are a number of interesting conclusions to draw from it. It seems that the number of flaws in common software is still much too high. Consider what’s required to compromise today’s most hardened consumer platforms, iOS and Chrome. You need a flaw in the default install that is useful and remotely accessible, memory disclosure bug, sandbox bypass (or multiple ones), and often a kernel or other privilege escalation flaw. Given a sufficiently small trusted computing base, it should be impossible to find this confluence of flaws. We clearly have too large a TCB today since this combination of flaws has been found not once, but multiple times in these hardened products. Other products that haven’t been hardened require even less flaws to compromise, making them more vulnerable even if they have the same rate of bug occurrence. The paper’s conclusion shows that if you want to prevent exploitation, your priority should be preventing stack, heap, and integer overflows (in that order). Stack overflows are by far still the most commonly exploited class of memory corruption flaws, out of proportion to their prevalence. We’re clearly not smart enough as a species to stop creating software bugs. It takes a Dan Bernstein to reason accurately about software in bite-sized chunks such as in qmail. It’s important to face this fact and make fundamental changes to process and architecture that will make the next 18 years better than the last. Download: http://www.isg.rhul.ac.uk/sullivan/pubs/raid-2012.pdf Sursa: History of memory corruption vulnerabilities and exploits | root labs rdist

Am gasit un "bridge" intre Wordpress si vBulletin, insa nu merge pe aceasta versiune. Mai exact, crapa tot blog-ul. Voi incerca sa fac eu ceva "manual" pentru comentarii, insa nu stiu cand. Deocamdata lasam asa, sa vedem ce iese.

' or username=NUMELE_TAU_REAL/**/and/**/aDDreSS=ADRESA_TA_DE_ACASA Inlocuiesti ce e cu majuscule cu datele tale reale.

1. 6 (1 + 2 + 3) 2. RSTRSTRSTRST (cand b ajunge 0) 3. Hello world (format de compatibilitate cu tastaturile "vechi" adica antice) 4. Nu ai "using namespace std;". Invalid lvalue... ? 5. RST 6. Acum este ora 4 noaptea! Sa fac un challenge pe RST 7. 9 (2 + 3 + 4) 8. exit(0), RST (nu se mai compileaza deci nu mai afiseaza nimic) Plm

Da, de acea pagina am avea nevoie, de un design pentru ea.

Legat de istorie, sunt foarte putini persoane pe care o cunosc, care activeaza de cel putin 5-6 ani. Daca tot veni vorba, se ofera cineva sa faca un homepage? Doar de design avem nevoie, de integrare ma voi ocupa eu.

Da, m-am gandit la asta. Cand voi avea timp liber voi scrie un articol mai detaliat, sper doar sa am timp...

Salut, Pentru a completa forumul am decis sa deschidem un blog: https://rstforums.com/blog/ Blog-ul are doar rol informativ, va contine anunturi administrative, mici articole in limba romana si multe altele. Mai multe informatii: https://rstforums.com/blog/2013/03/23/blog-ul-rst/ Pe blog vor posta doar membrii din staff. Daca aveti ceva frumos care considerati ca se poate posta, luati legatura cu cineva din staff. Daca sunt probleme sau daca aveti sugestii le asteptam cu placere aici. // RST

La revedere.

Nu te risca, sunt multi tepari. Nu am incercat si nici nu voi incerca, dar aia sunt ratatii care copiau exploit-urile altora si spuneau ca sunt ale lor: injector. Daca vrei exploit-uri e simplu: inchiriaza un exploit kit! Si da-mi si mie de veste daca faci asta

Cand suni in alta retea se aude un "bipuit" care te anunta ca "poti fi taxat suplimentar".

www.youtube.com/watch?v=Z1eX1vEgiRQ

Info: Sun? la 544 ?i afl? dac? ai telefonul ascultat: Ofi?erii de la Informa?ii pot fi surprin?i în „flagrant”? Cine le autorizeaz? intercept?rile

Da, parca un joc, parca de la Steam era. Adica nu stiu daca avea treaba cu OpenGL, parca nu OpenGL optimizasera ci acel joc...

Link "permanent" (cod sursa): https://rstforums.com/proiecte/DK_v3.3.zip Voi proceda la fel pentru cat mai multe proiecte.

[h=1]Windows 8 Outperforming Ubuntu Linux With Intel OpenGL Graphics[/h] Published on March 21, 2013 Written by Michael Larabel In our benchmarks of Microsoft Windows 8, we have found that Intel's Windows OpenGL driver is generally superior to that of their open-source Linux graphics driver. Some progress has been made, but in today's testing of an ASUS Ultrabook bearing an Ivy Bridge processor, Linux has a ways to go for some games in matching the Windows binary performance and features. Over the years there have been many Windows 7 vs. Linux benchmarks on Phoronix. Having recently picked up an ASUS Ultrabook for benchmarking, some Windows 8 vs. Ubuntu 13.04 development benchmarks were carried out to see the positioning today. An ASUS S56CA-WH31 was the candidate for this testing, which is a $500 Intel Ultrabook sporting an Intel Core i3 3217U CPU, 4GB of DDR3 system memory, 500GB 5400RPM HDD + 24GB Solid-State Drive, and a 15.6-inch display with 1366 x 768 resolution. The ASUS Ultrabook comes pre-loaded with Microsoft Windows 8. The Intel Core i3 3217U processor provides HD 4000 graphics, two physical cores plus Hyper Threading, 1.8GHz clock frequency, 3MB cache, and is rated at a 17 Watt TDP. All benchmarking in this article between Windows and Linux happened from this ASUS S56CA-WH31 Ultrabook. The stock Intel Windows 8 graphics performance was compared to Ubuntu 13.04 in a variety of cross-platform games using OpenGL where the games are known to have quality/similar ports to Windows and Linux. Benchmarking on both operating systems were all handled via the open-source Phoronix Test Suite software in conjunction with OpenBenchmarking.org. The Ubuntu 13.04 development snapshot used was from mid-March and packaged the Linux 3.8 kernel, Unity 6.6.0, xf86-video-intel 2.21.4, X.Org Server 1.13.2, GCC 4.7.2, and Mesa 9.0.2. For also seeing the very latest state of the Intel OpenGL driver software on Linux, Ubuntu 13.04 was additionally tested when using a Git development snapshot of the Linux 3.9 kernel and then Mesa 9.2-devel Git master from mid-March. This represents the very latest state of the Intel Linux graphics driver. (Ubuntu 13.04 will ship with Mesa 9.1, but that stable release wasn't pulled into the repository at the time of testing and 9.2-devel offers the absolute latest innovations for this open-source driver.) Previous to this article, my latest Windows 7 test articles were: Intel Linux OpenGL Driver Remains Slower Than Windows, NVIDIA Performance: Windows 7 vs. Ubuntu Linux 12.10, and AMD Radeon Catalyst: Windows 7 vs. Ubuntu 12.04 LTS. This testing is quite straightforward and looking namely at the "out of the box" OpenGL gaming performance between Windows 8 and Ubuntu 13.04 for Intel Ivy Bridge graphics. Articol complet: [Phoronix] Windows 8 Outperforming Ubuntu Linux With Intel OpenGL Graphics

[h=1][C++] Dump wireless passwords[/h]By RAGE Before I get started I just want to say some things first. This application WILL NOT crack passwords or hack wifi, this program simply displays information on your PC that you can already access. Moving on, this program simply queries Native Wifi for a list of Wireless Network Profiles which it then "parses" the resultant xml looking for the network key. To actually retrieve the plain text key you need to be a member of the administrators group and elevate the exe. The binary has an easter egg for bored members with nothing to do #ifndef WLAN_PROFILE_GET_PLAINTEXT_KEY #define WLAN_PROFILE_GET_PLAINTEXT_KEY 4 // Dont have the latest platform SDK on this box #endif #pragma comment(lib, "wlanapi.lib") #include <stdio.h> #include <windows.h> #include <wlanapi.h> BOOL IsElevated() { DWORD dwSize = 0; HANDLE hToken = NULL; BOOL bReturn = FALSE; TOKEN_ELEVATION tokenInformation; if(!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken)) return FALSE; if(GetTokenInformation(hToken, TokenElevation, &tokenInformation, sizeof(TOKEN_ELEVATION), &dwSize)) { bReturn = (BOOL)tokenInformation.TokenIsElevated; } CloseHandle(hToken); return bReturn; } bool IsVistaOrHigher() { OSVERSIONINFO osVersion; ZeroMemory(&osVersion, sizeof(OSVERSIONINFO)); osVersion.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); if(!GetVersionEx(&osVersion)) return false; if(osVersion.dwMajorVersion >= 6) return true; return false; } int main(int argc, char *argv[]) { HANDLE hWlan = NULL; DWORD dwError = 0; DWORD dwSupportedVersion = 0; DWORD dwClientVersion = (IsVistaOrHigher() ? 2 : 1); GUID guidInterface; ZeroMemory(&guidInterface, sizeof(GUID)); WLAN_INTERFACE_INFO_LIST *wlanInterfaceList = (WLAN_INTERFACE_INFO_LIST*)WlanAllocateMemory(sizeof(WLAN_INTERFACE_INFO_LIST)); ZeroMemory(wlanInterfaceList, sizeof(WLAN_INTERFACE_INFO_LIST)); WLAN_PROFILE_INFO_LIST *wlanProfileList = (WLAN_PROFILE_INFO_LIST*)WlanAllocateMemory(sizeof(WLAN_PROFILE_INFO_LIST)); ZeroMemory(wlanProfileList, sizeof(WLAN_PROFILE_INFO_LIST)); if(!IsElevated()) printf("[!] Running without administrative rights\n"); try { if(dwError = WlanOpenHandle(dwClientVersion, NULL, &dwSupportedVersion, &hWlan) != ERROR_SUCCESS) throw("[x] Unable access wireless interface"); if(dwError = WlanEnumInterfaces(hWlan, NULL, &wlanInterfaceList) != ERROR_SUCCESS) throw("[x] Unable to enum wireless interfaces"); if(wlanInterfaceList->dwNumberOfItems == 0) // Almost missed this before posting throw("[x] No wireless adapters detected"); if(dwError = WlanGetProfileList(hWlan, &guidInterface, NULL, &wlanProfileList) != ERROR_SUCCESS) throw("[x] Unable to get profile list"); LPWSTR profileXML; printf("\nNetwork\t\t\t\t\tPassword\n\n"); for(int i = 0; i < wlanProfileList->dwNumberOfItems; i++) { DWORD dwFlags = WLAN_PROFILE_GET_PLAINTEXT_KEY, dwAccess = 0; wprintf(L"%s", wlanProfileList->ProfileInfo[i].strProfileName); int j = 20 - wcslen(wlanProfileList->ProfileInfo[i].strProfileName); for(int k = 0; k < j; k++) printf(" "); if(IsElevated()) { if(WlanGetProfile(hWlan, &guidInterface, wlanProfileList->ProfileInfo[i].strProfileName, NULL, &profileXML, &dwFlags, &dwAccess) == ERROR_SUCCESS) { // This is really half assed but I'm really hungover WCHAR *pszStr = wcstok(profileXML, L"<>"); while(pszStr) { if(!wcscmp(pszStr, L"keyMaterial")) { pszStr = wcstok(NULL, L"<>"); wprintf(L"\t\t\t%s\n", pszStr); break; } pszStr = wcstok(NULL, L"<>"); } WlanFreeMemory(profileXML); } } else { printf("\t\t\tAccess Denied.\n"); } } } catch(char *szError) { printf("%s (0x%X)\nQuitting...\n", szError); } if(wlanProfileList) WlanFreeMemory(wlanProfileList); if(wlanInterfaceList) WlanFreeMemory(wlanInterfaceList); if(hWlan) WlanCloseHandle(hWlan, NULL); return dwError; } Screenshot: Enjoy! [h=4]Attached Files[/h] wldecrypt.zip 40.62K 1446 downloads Sursa: [C++] Dump wireless passwords - rohitab.com - Forums

Linux Kernel kvm Multiple Vulns * CVE-2013-1796 Description of the problem: If the guest sets the GPA of the time_page so that the request to update the time straddles a page then KVM will write onto an incorrect page. Thewrite is done byusing kmap atomic to get a pointer to the page for the time structure and then performing a memcpy to that page starting at an offset that the guest controls. Well behaved guests always provide a 32-byte aligned address, however a malicious guest could use this to corrupt host kernel memory. Upstream commit: https://git.kernel.org/cgit/virt/kvm/kvm.git/commit/?id=c300aa64ddf57d9c5d9c898a64b36877345dd4a9 References: https://bugzilla.redhat.com/show_bug.cgi?id=917012 * CVE-2013-1797 Description of the problem: There is a potential use after free issue with the handling of MSR_KVM_SYSTEM_TIME. If the guest specifies a GPA in a movable or removable memory such as frame buffers then KVM might continue to write to that address even after it's removed via KVM_SET_USER_MEMORY_REGION. KVM pins the page in memory so it's unlikely to cause an issue, but if the user space component re-purposes the memory previously used for the guest, then the guest will be able to corrupt that memory. Upstream commit: https://git.kernel.org/cgit/virt/kvm/kvm.git/commit/?id=0b79459b482e85cb7426aa7da683a9f2c97aeae1 References: https://bugzilla.redhat.com/show_bug.cgi?id=917013 * CVE-2013-1798 Description of the problem: If the guest specifies a IOAPIC_REG_SELECT with an invalid value and follows that with a read of the IOAPIC_REG_WINDOW KVM does not properly validate that request. ioapic_read_indirect contains an ASSERT(redir_index < IOAPIC_NUM_PINS), but the ASSERT has no effect in non-debug builds. In recent kernels this allows a guest to cause a kernel oops by reading invalid memory. In older kernels (pre-3.3) this allows a guest to read from large ranges of host memory. Upstream commit: https://git.kernel.org/cgit/virt/kvm/kvm.git/commit/?id=a2c118bfab8bc6b8bb213abfc35201e441693d55 References: https://bugzilla.redhat.com/show_bug.cgi?id=917017 All three issues were found and reported by Andrew Honig of Google. References: https://bugzilla.redhat.com/show_bug.cgi?id=917012 https://bugzilla.redhat.com/show_bug.cgi?id=917013 https://bugzilla.redhat.com/show_bug.cgi?id=917017 http://seclists.org/oss-sec/2013/q1/702 Sursa: Linux Kernel kvm Multiple Vulns - CXSecurity.com

TorProject-Annual-Report Da, nu e tutorial, dar contine catev statisici si informatii interesante... Download: https://www.torproject.org/about/findoc/2012-TorProject-Annual-Report.pdf

[h=3]Infiltrate Preview - TrueType Font Fuzzing and Vulnerability[/h] TrueType font files are made up of a number of tables; each table begins on a 4 byte boundary that comprises an outline font and must be long aligned and padded with zeroes if necessary. Referring to the “TrueType 1.0 Font File Technical Specification”, provided by Microsoft; the TrueType font file begins at byte 0 with the Offset Table. Offset Table is divided into 5 subtable: sfnt version : 65536(0x0001 0000) for version 1.0 numTables : Number of tables searchRange : (Maximum power of 2 ? numTables) x 16 entrySelector : Log2(Maximum power of 2 ? numTables) rangeShift : numTables x 16 – searchRange Beginning at byte 12, after the Offset Table, is the Font Table Directory. Entries in the Table Directory must be sorted in ascending order by ‘tag’ name. Overall, the Font Table Directory Header consists of: tag : 4 byte identifier checkSum : checksum of the table offset : Beginning offset of the font table entry length : Length of the table [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center] The Structure of True Type Font Directory [/TD] [/TR] [/TABLE] The required tables in the Font Table Directory: cmap : character to glyph mapping glyf : glyph data head : font header hhea : horizontal header hmtx : horizontal metrics loca : index to location maxp : maximum profile name : naming table post : PostScript information OS/2 : OS/2 and Windows specific metrics The optional tables in the Font Table Directory: cvt : Control Value Table EBDT : Embedded bitmap data EBLC : Embedded bitmap location data EBSC : Embedded bitmap Scaling data fpgm : font program gasp : grid-fitting and scan conversion procedure hdmx : horizontal device metrics kern : kerning LTSH : Linear threshold table prep : CVT Program PCLT :PCL5 VDMX : Vertical Metrics header vhea : Vertical Metrics Due to font validation purposes, the dumb fuzzing technique is not recommended for these fields: ‘checkSum’, ‘offset’, ‘length’ and ‘Table’. To reduce the number of irrelevant tests, a checksum validation program is used to determine the checksum of ‘head’ table. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center] Fix the Checksum value of the “head” Font Table Directory [/TD] [/TR] [/TABLE] During the fuzzing process, the table checksum has to re-compute. The checksum calculation implies 4 byte boundaries as shown in Python program below: Data provided by Pastebin.com - Download Raw - See Original [LIST=1]def chk(tab): total_data=0 for i in range(0, len(tab), 4): data=unpack(“>I”,tab[i:i+4])[0] total_data += data final_data=0xFFFFFFFF & total_data return final_data [/LIST] <NOTE TO NICO: NO PYTHON PROGRAM IS HERE> Our font fuzzer is to fuzz the TrueType font file into different sizes which enables the generation of the test cases to determine the size of font in triggering the vulnerability. Each fuzzing process starts with automating the installation of the mutated font in Windows system. It will then display the font; both in open the font file via fontview.exe and displaying the character maps. Lastly, uninstall the font and repeat the process if no vulnerability is found. The windll.gdi32.AddFontResourceExA function is used to automate the installation of the crafted font into the “C:\Windows\Fonts” folder. htr = windll.gdi32.AddFontResourceExA(FileFont, FR_PRIVATE, None) Once the fuzzing environment is ready, a LOGFONT object is created to define the attributes of a font. lf=win32gui.LOGFONT() Assuming no vulnerability has been found at a font with a specified size that has been called; the windll.gdi32.RemoveFontResourceExW function will be called to remove the fonts in “C:\Windows\Fonts” folder. windll.gdi32.RemoveFontResourceExW(fileFont, FR_PRIVATE, None) Another size of font in the range that has been set will be called and the same process will repeat until vulnerability is found or the list of font size elements under a loop function has all been called and no vulnerability is found. Figure below shows the Blue Screen of Death (BSOD) proof of concept via our font fuzzer. [Editor's note: BOOM! :>] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center] BSOD of Windows 8 Pro [/TD] [/TR] [/TABLE] The details of the fuzzer and findings will be discussed in the talk. Looking forward to see you guys in INFILTRATE 2013. --- Ling Chuan Lee & Lee Yee Chan from F13 Labs Sursa: Immunity Products: Infiltrate Preview - TrueType Font Fuzzing and Vulnerability

Am inteles ca pustiul e roman si ca mesajul e pentru bozgori.