LSE Blog systems, computer security, languages theory, and even more!Tue, 16 Dec 2014 10:06:04 GMTPyRSS2Gen-1.1.0 a Sega Whitestar Pinball<h2>Sega Starship Troopers Pinball Overview</h2> <p>The <code>Sega Starship Troopers Pinball</code> is fairly representative of the <em>WhiteStar Board System</em> used in several <em>Sega</em> pinball games and <em>Stern Pinball</em>. This hardware architecture was firstly designed in 1995 for the <em>Apollo 13</em> game with the objective to be convenient and extensible in order to be reusable for other playfields. This way, Sega could exploit a large number of licenses without having to design new control circuits for each machine.</p> <p>This architecture is based on three Motorola <code>68B09E</code> clocked at 2MHz and used as main CPU, display controller and sound controller. The two last are mainly dedicated to monitor application-specific processors: for instance, the <code>6809</code> used on the display board is charged to interface a <code>68B45</code> CRT controller to the main CPU. The sound processing is handled by a <code>BSMT2000</code>, a custom masked-rom version of the <code>TI TMS320C15</code> DSP.</p> <p>Sega used this system for 16 other games including <em>GoldenEye</em>, <em>Star Wars</em> and <em>Starship Troopers</em>.</p> <p><img alt="" src="/medias/images/playfield_top.jpg" /></p> <h3>Playfield's wiring</h3> <p>The playfield wiring is quite simple: all switches are disposed in a matrix grid. This method provides a simple way to handle a high number of I/O with a reasonable number of connectors. So, in order to read the switches state, the CPU has to scan each raw of the matrix by grounding it and watching in which column the current is flowing.</p> <p>A similar circuit is used to control playfield lamps: each raw has to be scanned by grounding it and applying voltage on the column connector according to lamps that have to be switched on the selected raw.</p> <p><img alt="Lamp wiring" src="/medias/images/lamp_wiring.png" /></p> <p>It's truly easy to control a high number of lamps with this layout. The following code switches on the lamp 31 (multiball).</p> <pre><code>lda #$8 sta LAMP_ROW ;; Ground selected row clra sta LAMP_AUX ;; Clear auxiliary rows lda #$40 sta LAMP_COL ;; Drive selected column </code></pre> <p>Although playfield switches are handled by the matrix grid, some frequently used buttons are connected to a dedicated connector. This allows the CPU to directly address this input without having to scan the entire input matrix. These switches are user buttons and End-Of-Stroke.</p> <p><img alt="Flippers Wiring" src="/medias/images/flipper_wiring.png" /></p> <p>The E.O.S switch prevents foldback when the player has the flipper energized to capture balls. When the Game CPU detects that this switch is open, it stabilizes the position of the selected flip by reducing the pulse applied to the coil.</p> <h3>The Backbox</h3> <p>The Backbox contains all the electronic circuits controlling playfield's behaviour. We will focus on this very part throughout the article.</p> <h4>CPU/Sound Board</h4> <p>The main board contains the Game CPU and the Sound circuit. The switches are directly connected to this board so that it is really simple for the CPU to fetch their values.</p> <p><img alt="CPU Board" src="/medias/images/cpu_board.jpg" /></p> <p>One of the main problems of this board is the battery location. Populated with a 3xAA battery holder to keep the RAM content alive, alkaline batteries are located on top of the CPU, ROM and RAM chip, which is critical when they will start to leak on this components. Before I started playing with this machine, I spend hours restoring and cleaning the PCB because of the corrosive leaking. To avoid deterioration, relocating this battery could be a smart idea.</p> <h4>Display Controller Board</h4> <p>Like many pinball machines from the 90s, the backbox is equipped with an old school dot matrix display.</p> <p>As the CPU Board, it is based on a Motorola <code>68B09E</code> with a dedicated 512MB UVPROM which contains the dot matrix display driver code and images that can be displayed on it. It communicates with the main board via a specific protocol.</p> <p>To interface the raster display, the board uses a Motorola <code>68B45</code> (<code>68B45 CRTC</code> for "cathode ray tube controller"). Although this chip was primarily designed to control the CRT display, it can also be used to generate correctly timed signal for a raster dot matrix display like in this case.</p> <h4>I/O Power Driver Board</h4> <p>The IO Power Driver Board is an interface between the low current logic circuit and the high current playfield circuit.</p> <p>The first part of this circuit consists of converting the alternative current provided by the transformer into exploitable direct current thanks to 5 bridges rectifiers.</p> <p>The only electromagnetic relay is dedicated to the general illumination and is not controllable via the main CPU. The rest is driven by MOSFET power transistors which are designed to be able to handle high current in order to power playfield coils. Moreover, fuses are placed before each bridges rectifiers in order to easily help identifying where the problem comes from in case of failure.</p> <p><img alt="IO Board" src="/medias/images/io_board.jpg" /></p> <p><img alt="IO Board Power supply" src="/medias/images/power.png" /></p> <h2>Upgrading the firmware</h2> <p><img alt="ROM Summary" src="/medias/images/rom_summary.png" /></p> <p>The title screen displayed in the dot matrix plasma display indicates that the firmware's version is <code>2.00</code>. However, an up-to-date image of this ROM exists in <a href="">Internet Pinball Database</a> which seems to be on version <code>2.01</code> according to the ascii string located at offset <code>$66D7</code>. Let's try to upgrade the pinball!</p> <p>An almost suitable flash memory to replace the original UVPROM is the <code>A29040C</code>. The only mismatches on the pinout are the <code>A18</code> and <code>WE</code> pins. This is a minor problem since I fixed the PCB to match the <code>A29040C</code> layout.</p> <p><img alt="Pinout Mismatch" src="/medias/images/pinout_mismatch.png" /></p> <p>Burning the <code>A29040C</code> with the new firmware requires a flash memory programmer. I decided to craft one with an <code>Arduino mega 1280</code> based on an <code>AVR Atmega 1280</code> microcontroller. The large number of IO of this chip is essential to complete the programming protocol of the <code>A29040C</code>.</p> <p><img alt="Homemade Flash Programmer" src="/medias/images/flash_programmer.jpg" /></p> <p>After successfully programming the flash memory, I was pretty disappointed when I noticed that the new ROM chip was still not working.</p> <p>I thought that this UVPROM was able to store 512KB of data, just like <code>A29040C</code>. It took me a while to realise that the game is a 128KB ROM although the chip is designed to be connected to a 19 bit address bus. This means that the game's ROM simply ignores the value of <code>A17</code> and <code>A18</code> signals, which means that the game code is mirrored 4 times in the whole ROM address space.</p> <p><img alt="Mirroring" src="/medias/images/mirroring.png" /></p> <h2>Building a custom ROM</h2> <p>Now that we are able to substitute the original ROM with a custom flash memory, let's try to run our own code on this machine.</p> <p>The first thing that we have to do in this case is to determine where the CPU will fetch its first instruction after a reset. According to the<code>6809</code> datasheet, the interrupt vector table (which contents the address of the <code>reset</code> event handler) is located at <code>0xFFFE</code>. However, this offset refers to the CPU address space, not that of the ROM chip. So, after a reset, which part of this memory is mapped at <code>0xFFFE</code>?</p> <p>To answer this, it's essential to follow the address bus of the UVPROM. We then easily see that bits 14 to 18 of this bus are connected to 5-bit register (<code>U211</code>) while bits 13 to 0 are directly bound to CPU address bus.</p> <p>This is a typical configuration to implement a bank system since the CPU address space is too narrow to map the entire ROM. That's why only one part of it (also called a <em>bank</em>) is mapped at a given time. The mapped bank is chosen by the <code>U211</code> register, called <code>XA</code>, and can be easily wrote by the CPU when a bank switching is needed.</p> <p><img alt="Bank System" src="/medias/images/bank.png" /></p> <h3>Finding address space</h3> <p>On this kind of device, it's always painful to debug the code running directly on the board. The only way to achieve it here is to trigger some visual element of the playfield in order to get a basic tracing of the execution flow.</p> <p>As there is no IO port on the <code>6809</code>, all devices are memory-mapped. The question now is: where are they located?</p> <p>First, let's focus on the address decoding circuit of the IO Board.</p> <p><img alt="IO Addressing" src="/medias/images/IO_addr.png" /></p> <p>In order to simplify cascading, the <code>74138</code> multiplexer generates output only if the Boolean expression <code>G1 &amp;&amp; !G2A &amp;&amp; !G2B</code> is true. So, in this circuit, <code>U204</code> covers IO addresses from <code>0x0</code> to <code>0x7</code> and <code>U205</code> handles from <code>0x8</code> to <code>0xF</code>.</p> <p>As we can see on this schematic, the question is: where does the <code>IOSTB</code> signal come from?</p> <p>Following the wire, we can see that this control signal is generated by the CPU Board. It actually acts as a <em>chip select</em>: it means that this signal is used to indicates to the IO Board that we are addressing it.</p> <p>To be more precise, the <code>IOSTB</code> is driven by the <code>U213</code> chip, a <code>PAL16L8</code> (Programmable Array Logic). This kind of integrated circuit is used to implement combinatoric logic expressions. This is widely used for address decoding.</p> <p><img alt="PAL16L8 Pinout" src="/medias/images/PAL16L8.png" /></p> <p>Dumping the logical expression programmed on this chip is essential to determine the actual CPU address space. One way to do it is to basically test all possible inputs and watch how outputs evolves according to input values. However, some of the <code>PAL16L8</code> pins can be considered as inputs as well as outputs. In this case, we can guess that <code>XA0</code>, <code>A9</code> and <code>A10</code> are used as input pins according to the rest of the circuit.</p> <p>I desoldered the PAL, in order to prevent undesired side effect on the rest of the circuit, and used a simple <em>Arduino Uno</em> to generate the truth tables of all outputs.</p> <p><img alt="Dumping the PAL16L8" src="/medias/images/pal_dump.jpg" /></p> <p>Now, let's extract irreducible logical expressions from the recorded truth tables. As a matter of fact, these truth tables are significantly too large to apply the well-known Karnaugh map method to simplify the extended logical expression. This problem can be solved by using the <a href="">electruth python module</a>. It fully implements the Quine-McCluskey method which is perfectly suitable in this situation.</p> <p>After a few hours of computation, I got these expressions, which are truly helpful in the address space determination process:</p> <pre><code>~ROMCS = A15 || A14 ~RAMCS = !A15 &amp;&amp; !A14 &amp;&amp; !A13 &amp;&amp; (!A12 || !A11 || !A10 || !A9 || RW || MPIN) IOPORT = !(!A15 &amp;&amp; !A14 &amp;&amp; A13 &amp;&amp; !A12 &amp;&amp; !A11 &amp;&amp; !XA0) IOSTB = !A15 &amp;&amp; !A14 &amp;&amp; A13 &amp;&amp; !A11 </code></pre> <p>Notice the <code>MPIN</code> input which is a signal generated by the cabinet door when it's open. So, the <code>PAL</code> restricts the access to a small part of the RAM when the coin door is closed. This section is actually used to store game settings that are only editable for maintenance purpose.</p> <p>Here is the address space that I was finally able to discover according to the actual wiring:</p> <ul> <li><code>0000</code>-<code>1FFF</code> : RAM<ul> <li><code>0000</code>-<code>1DFF</code> : Read/Write Area</li> <li><code>1E00</code>-<code>1FFF</code> : Write Protected Area</li> </ul> </li> <li><code>2000</code>-<code>27FF</code> : IO (IOBOARD)<ul> <li><code>2000</code> : HIGH CURRENT SOLENOIDS A<ul> <li>bit 0 : Left Turbo Bumper</li> <li>bit 1 : Bottom Turbo Bumper</li> <li>bit 2 : Right Turbo Bumper</li> <li>bit 3 : Left Slingshot</li> <li>bit 4 : Right Singshot</li> <li>bit 5 : Mini Flipper</li> <li>bit 6 : Left Flipper</li> <li>bit 7 : Right Flipper</li> </ul> </li> <li><code>2001</code> : HIGH CURRENT SOLENOIDS B<ul> <li>bit 0 : Trough Up-Kicker</li> <li>bit 1 : Auto Launch</li> <li>bit 2 : Vertical Up-Kicker</li> <li>bit 3 : Super Vertical Up-Kicker</li> <li>bit 4 : Left Magnet</li> <li>bit 5 : Right Magnet</li> <li>bit 6 : Brain Bug</li> <li>bit 7 : European Token Dispenser (<em>not used</em>)</li> </ul> </li> <li><code>2002</code> : LOW CURRENT SOLENOIDS<ul> <li>bit 0 : Stepper Motor #1</li> <li>bit 1 : Stepper Motor #2</li> <li>bit 2 : Stepper Motor #3</li> <li>bit 3 : Stepper Motor #4</li> <li>bit 4 : <em>not used</em></li> <li>bit 5 : <em>not used</em></li> <li>bit 6 : Flash Brain Bug</li> <li>bit 7 : Option Coin Meter</li> </ul> </li> <li><code>2003</code> : FLASH LAMPS DRIVERS<ul> <li>bit 0 : Flash Red</li> <li>bit 1 : Flash Yellow</li> <li>bit 2 : Flash Green</li> <li>bit 3 : Flash Blue</li> <li>bit 4 : Flash Multiball</li> <li>bit 5 : Flash Lt. Ramp</li> <li>bit 6 : Flash Rt. Ramp</li> <li>bit 7 : Flash Pops</li> </ul> </li> <li><code>2004</code> : <em>N/A</em></li> <li><code>2005</code> : <em>N/A</em></li> <li><code>2006</code> : AUX. OUT PORT (<em>not used</em>)</li> <li><code>2007</code> : AUX. IN PORT (<em>not used</em>)</li> <li><code>2008</code> : LAMP RETURNS</li> <li><code>2009</code> : AUX. LAMPS</li> <li><code>200A</code> : LAMP DRIVERS</li> </ul> </li> <li><code>3000</code>-<code>37FF</code> : IO (CPU/SOUND BOARD)<ul> <li><code>3000</code> : DEDICATED SWITCH IN<ul> <li>bit 0 : Left Flipper Button</li> <li>bit 1 : Left Flipper End-of-Stroke</li> <li>bit 2 : Right Flipper Button</li> <li>bit 3 : Right Flipper End-of-Stroke</li> <li>bit 4 : Mini Flipper Button</li> <li>bit 5 : Red Button</li> <li>bit 6 : Green Button</li> <li>bit 7 : Black Button</li> </ul> </li> <li><code>3100</code> : DIP SWITCH</li> <li><code>3200</code> : BANK SELECT</li> <li><code>3300</code> : SWITCH MATRIX COLUMNS</li> <li><code>3400</code> : SWITCH MATRIX ROWS</li> <li><code>3500</code> : PLASMA IN</li> <li><code>3600</code> : PLASMA OUT</li> <li><code>3700</code> : PLASMA STATUS</li> </ul> </li> <li><code>4000</code>-<code>7FFF</code> : ROM</li> <li><code>8000</code>-<code>BFFF</code> : ROM (Mirror)</li> <li><code>C000</code>-<code>FFFF</code> : ROM (Mirror)</li> </ul> <h3>Handling reset circuitry</h3> <p>In this kind of real-time application, where a huge number of unpredictable events have to be handled, the risk of race condition cannot be fully faded.</p> <p>Although the software is designed to be able to face any situations, the hardware has to be prepared to a faulty program. One of the simplest and more robust method is to use a <em>watchdog timer</em>. This consists of an autonomous timer charged to trigger a reset signal to the system if it reaches its initial point. The main idea here is to force the circuitry to be stopped if it does not correctly respond in order to prevent any damage from uncontrolled behaviour.</p> <p>In most cases, the timer has to be fed by the software running on the CPU. So, if we want to run our own code on that machine, it's essential to implement as a subroutine the reset of the watchdog in order to stay alive.</p> <p>In the <em>Whitestar</em> pinball, two distinct watchdogs have to be correctly handled. The first one is located on the CPU/Sound Board and is directly connected to the reset pin of the <code>6809</code>. <em>SEGA</em> engineers chose to use a <code>DS1232</code> chip (<code>U210</code>) which integrates all the features that are commonly used to monitor a CPU. So, in addition to a regular watchdog timer, this chip also provides a power monitoring and an external override which is actually designed to allow the use of a push button to force the CPU reset (<code>SW200</code>).</p> <p>As the <code>TOL</code> pin of this chip is grounded, the <code>DS1232</code> continually watches the voltage applied on <code>Vcc</code> pin and triggers a reset signal if its value is under 4.7V. From a software engineer point of view, the important pin in that case is the <em>strobe input</em> (<code>ST</code>): it is used to reset the watchdog timer when a falling edge is applied to it.</p> <p>On the CPU/Sound Board, this pin is connected to either clock signal (generated by <code>U2</code>) or <code>BSEL</code> signal according to the location of the jumper (<code>Wx</code> or <code>Wy</code>). As <code>Wx</code> was jumpered on my board, we can assume that the configuration in which <code>Wy</code> is fit was used during firmware development. So programmers were able to test their code without having to mind about the watchdog reset: this was automatically done by the clock signal. When the pinball was about to be released, calls to the watchdog reset subroutine were injected in appropriate parts of the firmware and the jumper was moved from <code>Wy</code> to <code>Wx</code>.</p> <p>In my opinion, modifying the hardware by desoldering the jumper and resoldering it on <code>Wy</code> is a little bit too easy to solve this kind of problem. So, let's try to handle the watchdog timer with a suitable software subroutine.</p> <p>The <code>BSEL</code> signal is generated when writing at address <code>0x3200</code> and is actually used as clock signal for the bank selection (<code>U211</code>). This is a clever way to get a nonintrusive watchdog reset subroutine: it's, in fact, hooked on the bank switching mechanism. The hardware designers probably thought it was a good idea to check the regularity of the code execution only by testing a periodic bank switching...</p> <p>In our case, we do not need to switch from initial bank. The trick I used here is to write <code>0</code> in the <code>XA</code> register, so the bank is unchanged but the watchdog is fed anyway.</p> <p><img alt="CPU Board watchdog" src="/medias/images/watchdog_cpu.png" /></p> <p>The second watchdog is located on the IO Board. The chip used is still a <code>DS1232</code> (<code>U210</code>) but the wiring is a little bit different. Firstly, since there is no code running on that board, the reset pin of the <code>U210</code> is not connected to a CPU but to all registers (8-bit D flip-flop) which drive power transistors.</p> <p>Secondly, there is no reset pushbutton on the IO Board. The <code>PBRESET</code> pin is connected to the <code>BRESET</code> signal coming directly from the CPU/Sound board. So, if the first <code>DS1231</code> triggers a reset signal, it automatically overrides the second watchdog timer and forward the signal to all IO Board components. However, this is not reciprocal: the IO Board cannot stops the CPU/Sound Board.</p> <p>The <em>strobe input</em> of this watchdog is directly connected to the <code>DAV0</code> signal which is used to ground the first raw of the lamp matrix. This means that the firmware has to frequently scan it to keep the IO Board alive. Tricky, but not fully irrelevant since the lights are still blinking on this kind of arcade machine in order to keep the game catchy.</p> <p>All of this reset circuitry have to be kept in mind when developing a firmware for this kind of platform.</p> <p><img alt="IO Board watchdog" src="/medias/images/watchdog.png" /></p> <h3>Final code</h3> <p>After many hours spent to reverse engineer the hardware part of this machine, I was finally able to print <em>LSE</em> on the 7-segment display of the playfield thanks to the code fetched from a custom flash ROM.</p> <p>Here is the assembly code of my own basic firmware:</p> <pre><code>LAMP_ROW EQU $2008 LAMP_AUX EQU $2009 LAMP_COL EQU $200A BANK_SELECT EQU $3200 ;; CPU/Board Watchdog reset wdr .MACRO clra sta BANK_SELECT .ENDM ;; Dummy delay subroutine delay .MACRO i lda i @l: deca bne @l .ENDM ;; Entry point .ORG 0xC000 main: ldx #lamps clrb stb LAMP_AUX ;; Clear auxiliary rows incb ;; Select first row loop: clra sta LAMP_ROW sta LAMP_COL ;; Clear rows and colunms delay #$1F ;; Dummy delay lda ,x+ ;; Fetch columns value sta LAMP_COL ;; Set columns stb LAMP_ROW ;; Ground selected row delay #$1F ;; Dummy delay wdr ;; Watchdog reset lslb ;; Select next row bne loop ;; Branch if the first 8 rows are not updated bcc main ;; Branch if the 9th row is updated rolb stb LAMP_AUX ;; Select the 9th row clrb bra loop ;; Lamp matrix values lamps: DB $01, $00, $00, $00, $00 DB $00, $1C, $B6, $9F, $00 ;; Interrupt vector table .ORG 0xFFFE reset: DW main </code></pre> <p><code>tpasm</code> is needed to assemble the preceding code and turn it into an Intel hex file using the following commands:</p> <pre><code>$ tpasm -P 6809 -o intel cpu.hex cpu.s $ hex2bin ./cpu.hex $ dd if=/dev/zero of=cpu.rom bs=16K count=32 $ dd if=cpu.bin of=cpu.rom bs=16K seek=31 </code></pre> <p><img alt="LSE Pinball" src="/medias/images/lse_pinball.jpg" /></p> <h2>Conclusion</h2> <p>Hacking this kind of machine has been as rewarding for me as it is for some people to play flipper.</p> <p>Unfortunatly, <em>Sega Pinball</em> left the market in 1999 (2 years after releasing the Starship Troppers pinball...) and sold all pinball assets to <em>Stern Pinball, Inc</em>. This company used the <em>WhiteStar</em> architecture until 2005 with <em>NASCAR</em> arcade machine. When <em>The Lord of the Rings</em> was released in 2003, they edited some part of the sound system by replacing the <code>Motorola 6809</code> / <code>BSMT2000</code> duo by a 32-bit <code>Atmel AT91SAM</code> ARM-based CPU and three <code>Xilinx FPGAs</code>. So the <code>6809-BSMT2000</code> system is fully emulated by this circuit to provide backward-compatibility.</p> <p>Now that we have hacked the hardware, what about reverse engineering the original firmware? Maybe another time...</p> <p>I hope you enjoyed this guided tour!</p> <p><img alt="" src="/medias/images/concl.png" /></p> <h2>References</h2> <ul> <li><a href="">SST Manual</a></li> <li><a href="">74138 Datasheet</a></li> <li><a href="">DS1232 Datasheet</a></li> <li><a href="">68B09 Datasheet</a></li> <li><a href="">68B45 Datasheet</a></li> <li><a href="">PAL16L8 Datasheet</a></li> <li><a href="">A29040C Datasheet</a></li> </ul> (Pierre Surply)75Tue, 16 Dec 2014 10:05:00 GMTGetting back determinism in the Low Fragmentation Heap<h2>Introduction</h2> <p>The Low Fragmentation Heap is the Front End allocator for the userland in modern Windows OS. It has been introduced in 2001 in Windows XP and is used by default since Windows Vista. Microsoft has introduce a lot of new mitigations in response to <code>generic</code> attack against the LFH since its first disclosure in Windows XP. One of them, introduced in Windows 8, is the non-determinism of the allocation. This mitigation has quite a lot of consequences because it will break most of the overflows exploits but also use-after-free exploits.</p> <h2>Low Fragmentation Heap</h2> <p>The goal of the Low Fragmentation Heap is, as its names says, to reduce the fragmentation. It is not a different heap but a different policy. Here is a global overview of how the allocation is made by Windows:</p> <p><img alt="Global Gestion" src="/medias/images/global_memory.png" /></p> <p>The HeapAlloc and HeapFree functions will make some tests and decide if it should call the back-end or the front-end, which means the LFH since the removal of the Look-Aside-List. There are some conditions for an allocation to be made by the LFH: <em> The size must be inferior to 0x4000 bytes </em> The LFH must be activated for this heap. It is possible to deactivate the LFH in a heap by setting HEAP_NO_SERIALIZE when creating a heap with HeapCreate. <em> The LFH must be activated for this allocation. It is also possible to deactivate the LFH for a particular allocation (still with HEAP_NO_SERIALIZE). </em> There must be enough allocation for activating the LFH for this size.</p> <p>The function charge of the allocation for the LFH is <code>RtlpLowFragHeapAllocFromContext</code> and the one for the back-end is <code>RtlpAllocateHeap</code> which will use the VirtualAlloc from the system.</p> <p>If you want more details about how the LFH works, you can look at my presentation in french about this subject during the <a href="">lse summer week 2014</a>, or read the excellent paper <a href="">Windows 8 Heap Internals</a> by Chris Valasek and Tarjei Mandt.</p> <h2>Mitigation</h2> <p>Microsoft has introduced two factors of randomization with Windows 8. The first one is to add a random offset for each virtual allocation, its primary goal is removing the predictability of heap metadata for preventing their corruption. The second is for randomizing the UserBlock returned by an allocation.</p> <p>Before those changes, a simple code like this:</p> <pre><code>#include &lt;Windows.h&gt; #include &lt;stdio.h&gt; #include &lt;iostream&gt; int main() { HANDLE hHeap = GetProcessHeap(); int i = 0; int size = 0x40; LPVOID chunk; // lfh activation while (i &lt; 0x10) { chunk = HeapAlloc(hHeap, 0, size); i++; } chunk = HeapAlloc(hHeap, 0, size); printf("\n\nchunk1: %p\n", chunk); HeapFree(hHeap, 0, chunk); chunk = HeapAlloc(hHeap, 0, size); printf("\n\nchunk2: %p\n", chunk); HeapFree(hHeap, 0, chunk); } </code></pre> <p>would give us an output which is predictable and will allow us to trigger a simple use-after-free:</p> <pre><code>chunk1: 011D8CC0 chunk2: 011D8CC0 </code></pre> <p>The same code since Windows 8 will give us this result:</p> <pre><code>chunk1: 011D8CC0 chunk2: 011D8DE0 </code></pre> <p>We can clearly see that the result is not easily predictable anymore. The next question is how is this implemented ? The implementation is pretty simple, in <code>RtlpCreateLowFragHeap</code> there is a call to <code>RtlpInitializeLfhRandomDataArray</code>:</p> <p><img alt="RtlpInitializeLfhRandomDataArray" src="/medias/images/RtlpInitializaLfhRandomDataArray.png" /></p> <p>It will basically fill the <code>RtlpLowFragHeapRandomData</code> array with 0x100 random values. This array will then be used with a value called <code>LowFragHeapDataSlot</code> from the TEB (Thread Environment Block) which is use for storing value by thread.</p> <pre><code>mov ecx, large fs:18h ; getting the current TEB movzx esi, word ptr [ecx+0x0FAA] ; getting LowFragHeapDataSlot lea eax, [esi+1] ; adding 1 to LowFragHeapDataSlot and eax, 0xff ; checking we don't go past the 0x100 mov [ecx + 0x0faa], ax ; rewrite LowFragHeapDataSlot + 1 movzx eax, byte ptr RtlpLowFragHeapRandomData[esi] ; getting the value at offset of LowFragHeapDataSlot </code></pre> <p>This value is then used with a ror on the bitmap to determine the position where to start, and from this position it will look for the first free block in the bitmap which will allow to make two consecutive allocations to not be at predictable place.</p> <h2>Attacks</h2> <p>In 2008 at ruxcon, Ben Hawkes presented <a href="">Attacking the Vista Heap</a> in its slides he made several claims and more precisely : <code>Application specific attacks are the future</code>. This is probably more true than ever with a heap implementation like the one we get since Windows 8 and the non-determinism of the allocation is a big problem even for application specific attacks. This mitigations has been well documented but I haven't found any documentation about how to bypass it.</p> <h3>First attack</h3> <p>The first basic attack we can think of is the idea to fill all the slots except one with the object we want to overwrite. We then fill the last slot remaining with the object in which we can overwrite.</p> <p><img alt="LFHSuccess" src="/medias/images/lfh_success.png" /></p> <p>This technic will work perfectly for use-after-free because we don't care about the data locate right before or right after it. On the contrary for a classic overflow we really care about what is after (I don't consider underflow but it is basically the same principle). If you control the whole userblock you have fair chances of success: the only case for which it will not work is if we get the last chunk.</p> <p><img alt="LFHFailEnd" src="/medias/images/lfh_fail_end.png" /></p> <p>But if there is some allocations made for the user blocks the probability of success will decrease a lot because you have more position which will end with a failure.</p> <p><img alt="LFHFailChunk" src="/medias/images/lfh_fail_used_chunk.png" /></p> <p>It also means that you need to be able to allocate enough time the data you want to overflow which could not be the case and in the end you will not be able to know which one you overflowed so you will need a way to test this.</p> <h3>Second attack</h3> <p>In the mitigation part we saw that for getting a random value the <code>RtlpLowFragHeapAllocFromContext</code> function take a value from the pre-populated <code>RtlpLowFragHeapRandomData</code> array. This array is changed in only two occasions: <em> in the <code>RtlpInitializaLfhRandomDataArray</code> function when creating the LFH </em> in the <code>RtlpSubSegmentInitialize</code> function which is called by <code>RtlpLowFragHeapAllocFromContext</code> when a subsegment needs initialization So basically this array is not re-populated often, and we can make allocation without the array being changed. The counter is stored in the TEB and is incremented after each use of the array. Since the counter must stay inferior to array's size, a modulo 0x100 is made. That means that we can just make 0xff allocations and going back to the same position in the array. The following code will allow us to get twice the same chunk:</p> <pre><code>#include &lt;Windows.h&gt; #include &lt;stdio.h&gt; #include &lt;iostream&gt; int main() { HANDLE hHeap = GetProcessHeap(); char c; int i = 0; int size = 0x40; LPVOID chunk; // activating the LFH for the size we choose while (i &lt; 0x10) { chunk = HeapAlloc(hHeap, 0, size); i++; } // making the allocation we want chunk = HeapAlloc(hHeap, 0, size); printf("chunk: %p\n", chunk); HeapFree(hHeap, 0, chunk); // making 0xff allocation for getting back // to the same point in the RtlpLowFragHeapRandomData i = 0; while (i &lt; 0x100 - 1) { chunk = HeapAlloc(hHeap, 0, size); HeapFree(hHeap, 0, chunk); i++; } // reallocating : we get the same chunk chunk = HeapAlloc(hHeap, 0, size); printf("chunk: %p\n", chunk); } </code></pre> <p>So even if we don't know where the allocation took place we get back to our first result with twice the same chunk:</p> <pre><code>chunk: 012A9A40 chunk: 012A9A40 </code></pre> <p>This is really good for a use-after-free and we don't have to fill all the space in the userblock. What about the overflow ? If we don't free the chunk, after 0xff allocations, we will get back to the same point in the array, but this chunk will already be in use. At that point the allocation algorithm doesn't take an other random number and keep trying, it will just take the first next free chunk which follow: <em> First we activate the LFH </em> Then we allocate the vulnerable chunk <em> We allocate 0xff chunks </em> We allocate the chunk we want to overflow</p> <p>It will give us the following code:</p> <pre><code>#include &lt;Windows.h&gt; #include &lt;stdio.h&gt; #include &lt;iostream&gt; int main() { HANDLE hHeap = GetProcessHeap(); char c; int i = 0; int size = 0x40; LPVOID chunk; // activating the LFH for the size we choose while (i &lt; 0x10) { chunk = HeapAlloc(hHeap, 0, size); i++; } // making the allocation which is vulnerable chunk = HeapAlloc(hHeap, 0, size); printf("vulnerable chunk: %p\n", chunk); // making 0xff allocation for getting back // to the same point in the RtlpLowFragHeapRandomData i = 0; while (i &lt; 0x100 - 1) { chunk = HeapAlloc(hHeap, 0, size); HeapFree(hHeap, 0, chunk); i++; } // allocation we want to overwrite chunk = HeapAlloc(hHeap, 0, size); printf("chunk to overwrite: %p\n", chunk); } </code></pre> <p>Which will give us the result:</p> <pre><code>vulnerable chunk: 00559B20 chunk to overwrite: 00559B68 </code></pre> <p>As you can see we have a gap of 8 bytes, those bytes are the size of the _HEAP_ENTRY struct which contains the meta-data of our block.</p> <p>One of the best advantages of this technic is that we need only one chunk to overwrite and we know which one it is.</p> <h2>Conclusion</h2> <p>We have seen two ways of getting some determinism from the LFH. None of those solutions are perfect. Exploiting a use-after-free with this technic will not be much harder than before if we can have some heap-spray. Overflow is not that easy, even with the second solution we still have a chance to get the last chunk and our two blocks can be separated by an other allocated block. The best way of decreasing the risks is to append is to first fill a subsegment and then use the new one to trigger the overflow.</p> (Bruno Pujos)74Sun, 02 Nov 2014 22:07:00 GMTUEFI boot stub in Linux<p>As most of you know, the linux kernel is stored as a bzImage. This bzImage has been comprised of different files over the time, but it is usually the composition of two things:</p> <p><img alt="bzImage" src="/medias/images/bzImage-1.png" /></p> <p>The bit that interests us is the linux boot code, and how it paves the way for the kernel itself. You may consider that once the piggy.o (see later) object has been loaded at offset 0x100000, the basic bootloading job is done. But first, before tackling UEFI thematics, let's go back a bit to the legacy booting processes.</p> <p>I gave a conference about these matters in March. You can consult the slides at the <a href=";utm_medium=copy&amp;rc=ex0share">following address</a>. The prezi slides give a very good idea of where you are in the code, try it!</p> <h2>Legacy boot</h2> <h3>Way, way back in 2.5.64</h3> <p>Even before people used window managers and all that fancy stuff, linux actually was a bootable image, meaning you could run <code>dd if=bzImage of=/dev/sda</code> and just boot off the thing. This required the 512 first bytes to be MBR-material, able to load the rest of the kernel itself. Using this technique, it was not possible to easily specify a command-line (and therefore a root filesystem, an initrd file or an init binary).</p> <p>The bzImage was composed as follow:</p> <p><img alt="bzImage" src="/medias/images/bzImage-2.png" /></p> <p>The piggy.o object contains the bulk of the kernel image. misc.o is a bunch of gzip routines for the decompression of the kernel.</p> <p>The bootsect.o was a 512-bytes MBR. Since 2.5.65, it just prints an error message indicating that the feature is not supported anymore. arch/i386/boot has since 2.6.24 been moved into arch/x86/boot. bootsect.S and setup.S have been replaced by the <a href="">header.S</a> file since 2.6.23. The bootsect.S file performed only a few basic tasks:</p> <ul> <li>Relocated itself at address 0x9000 (<a href="">bootsect.S:62</a>)</li> <li>Loaded the setup.o code at address 0x9200 (<a href="">bootsect.S:153</a>).</li> <li>Loaded the system at address 0x100000 (<a href="">bootsect.S:225</a>)</li> </ul> <p>The size of the setup.o code, which needs to be loaded in low-memory, is defined in the setup_sects field (<a href="">bootsect.S:415</a>).</p> <p>After loading those two chunks in memory, the processor jumped into the setup.o code, at the symbol start_of_setup (<a href="">setup.S:173</a>). From here, it carried out a few tasks:</p> <ul> <li>Checked the memory layout with three different methods (<a href="">e820h</a>, <a href="">e801h</a> and <a href="">88h</a>)</li> <li>Jumped in protected mode (<a href="">setup.S:873</a>) at offset 0x100000 (<a href="">setup.S:905</a>).</li> </ul> <p>The code at 0x100000 (1Mo) is part of the startup_32 (<a href="">head.S:31</a>) routine, the first protected mode code in the kernel. It uses routines from <a href="">misc.c</a> to decompress the kernel in place and then re-jumps at 0x100000 (<a href="">head.S:77</a>), where the code from piggy.o has now been loaded.</p> <h3>The real world</h3> <p>As I previously said, the layout of the arch/i386/boot folder (as of today arch/x86/boot) changed drastically over the time.</p> <p>The first change to take place was the nullification of the MBR, and starting at version 2.5.65, the 512 first bytes were only able to print out a bugger-off message. Between versions 2.6.22 and 2.6.23, the folder was totally revisited. A new file header.S was created, containing the now useless 512 bytes MBR and a bit of the setup.S code as well. The main change remains in the creation of a <a href="">main.c</a> file executing most of the initializations performed by the old setup.S regarding the <a href="">BIOS mode</a>, the <a href="">memory detection</a>, the <a href="">video mode</a> and such. The code in the main.c file then jumps in protected mode in the pm.c file (<a href="">pm.c:149</a>) via the goto_protected_mode stub. The <a href="">head_32.S</a> file is still very similar to the original head.S source: its job is to decompress the kernel in-place, thus placing piggy.o at 0x100000.</p> <p>The bzImage is of the following composition according to my research and the compressed folder building files (<a href="">Makefile:29</a> and <a href=""></a>):</p> <p><img alt="bzImage" src="/medias/images/bzImage-3.png" /></p> <h3>Usual BIOS-enabled bootloaders startup</h3> <p>Let's take a look at the syslinux sources to understand when and how the linux bzImage is loaded in memory by the bootloader itself. A big thanks to the guys from #syslinux on freenode for their help in finding the module loading and jumping into the kernel linux, the path was not obvious. It is split in two according to the setup_sects header (<a href="">load_linux.c:243</a>) in the first 512 bytes of the header.o file (<a href="">header.S:264</a>).</p> <ul> <li>The realmode code is loaded at an offset below 1M (<a href="">load_linux.c:320</a>)</li> <li>The command-line is loaded right behind this code (<a href="">load_linux.c:344</a>)</li> <li>The vmlinux.bin.gz file is loaded above 1M (<a href="">load_linux.c:362</a>)</li> </ul> <p>Once this is done, the bootloader simply jump 512 bytes behind the beginning of the realmode code it copied into memory. This code will re-localize itself at 0x9000 offset according to the setup_move_size field (<a href="">header.S:306</a>) if the command-line address has not been specified in the command_line_ptr field (<a href="">header.S:338</a>). From then on, the kernel will follow the same route as when it was loaded as an image.</p> <p>It might also be interesting to specify that the setup segment of the bootloading process is aware of the bootloader that loaded it previously thanks to the ext_loader_type field (<a href="">header.S:335</a>) (<a href="">boot.txt:</a>).</p> <h3>Conclusion</h3> <p>Well, all we thus far is that the BIOS-dependent bootloading process for linux is quite a mess. It is not trivial to follow the control flow and the bzImage loading is far from obvious. The drastic changes the boot folder underwent did not help me get a sense of what was going on. However, here comes UEFI.</p> <h2>The UEFI model</h2> <h3>Introduction</h3> <p>The goal of the UEFI specification is first to unify the boot process and get rid of the mess the BIOS-dependent bootloading option is. When the IA64 architecture was designed, engineers from Intel thought it was time to get rid of the legacy 16bits to 32bits to 64bits booting process, and go straight into protected mode. However, as the IA64 architecture failed in favor of the AMD64, the idea of getting rid of the archaic firmware that is BIOS stuck, and after a few years, the EFI firmware became UEFI and development of this specification spread outside Intel.</p> <p>The idea here is to provide an API more user-friendly to the programmer, with simple applications as Portables Executables (PE from Windows). Most of these applications are services (usually drivers) exposing to the user a bunch of devices such as a keyboard, a screen or the clock. They are initialized and ran automatically by the firmware. Other applications include a shell (enabling the user to start other applications), or bootloaders (it might be useful).</p> <p>There are three types of application:</p> <ul> <li>Simple applications (type=10)</li> <li>Boot services (type=11)</li> <li>Runtime services (type=12)</li> </ul> <p>Boot services are protocols (API to stay simple) designed to die when the boot process is done and the control is handed to the OS (via the <code>ExitBootServices()</code> routine.) These services include drivers such as text/graphical console, block devices and such. On the other hand, Runtime services are designed to stay reachable by the OS, even after a call to <code>ExitBootServices()</code>. These services provide access to the NvRAM for example, or drivers for the clock.</p> <p>The NvRAM stores a few variables, including the configuration for the boot manager. This boot manager reads the NvRAM to boot on a given application automatically. This configuration is alterable via the <code>efibootmgr</code> utility and allows the user to setup the bootloader order. This order usually defaults to:</p> <ol> <li>Try to boot on floppy</li> <li>Try to boot on hard drive</li> <li>Try to boot on NIC0</li> <li>Run shell application</li> </ol> <p>The user-defined applications and files are stored on a special <code>fat32</code> partition defined by the identifier <code>0xEF</code>.</p> <h3>UEFI: how to</h3> <p>As specified before, the code for an application is encapsulated in the PE format. This means the binary needs both the MZ and PE headers in order to be recognized as a valid efi executable. It needs to feature the .efi extension in the filesystem as well.</p> <p>The compilation of such binaries can be achieved with the help of the gnu-efi library, which is exposing to the user headers the firmware-provided data structures and function prototypes, such as the main. It also includes a basic library I/O C library using the EFI-defined drivers to the peripherals.</p> <p>The main prototype as defined by the gnu-efi library (<a href=";a=blob;f=inc/ia32/efibind.h;h=722542cfb9902639ffd95d1f3b8f6c2a61886158;hb=HEAD#l250">ia32/efibind.h:250</a>), and used in a sample 'hello world' application (<a href=";a=blob;f=apps/t.c;h=c7e3d57bdab7847b714ba4c99c04bc778462e135;hb=HEAD#l16">apps/t.c:16</a>):</p> <p><code>EFI_STATUS efi_main (EFI_HANDLE image_handle, EFI_SYSTEM_TABLE *systab);</code></p> <p>Arriving in that main, all the EFI features are available via the <a href="">EFI_SYSTEM_TABLE</a> (<a href=";a=blob;f=inc/efiapi.h;h=5e47324da491496bb37fefebe1e5160605f87426;hb=HEAD#l866">efiapi.h:866</a>) structure. The firmware thus exposes directly an stdin/stdout/stderr via the <code>systab-&gt;{ConIn,ConOut,StdErr}</code> handles.</p> <p>The <a href="">EFI_BOOT_SERVICES</a> structure gives a reference to the different protocols and drivers to the user via the <a href=""><code>LocateHandle()</code></a> and <a href=""><code>LocateProtocol()</code></a> functions. The <a href="">EFI_RUNTIME_SERVICES</a> structure yields directly access to the time and NvRAM variables.</p> <h2>Booting without a bootloader: the EFI boot stub</h2> <p>As expected, the linux kernel obviously does not use the gnu-efi library. The idea behind the EFI boot stub is to fake the previously seen bzImage as a valid efi application. This means setting up a MZ+PE header and all kinds of sneaky, sneaky stuff.</p> <p>The EFI boot stub became available as of linux 3.3. When compiling the kernel with options <code>CONFIG_EFI_STUB=y</code>, the header.S image features made up MZ+PE headers. The most important field, the AddressEntryPoint (<a href="">header.S:144</a>) is named <a href="">efi_pe_entry</a> in the source tree and is set by the <a href="">tools/build.c</a> program to either of the following (<a href="">tools/build.c:274</a>):</p> <ul> <li>0x010 (<a href="">compressed/head_64.S:37</a>) or (<a href="">compressed/head_32:34</a>). In the case of the head_64.S file, the EFI entry point is set to the 64 bits entry each time. However, a legacy bootloader will jump at 0x100000 and fall on the 32 bits entry which will do the jump into long mode and fall through in the (<a href="">startup_64</a>) routine. 64 bits legacy bootloader, however, will know enough to jump directly into startup_64.</li> <li>0x210 (<a href="">compressed/head_64:S:191</a>),</li> </ul> <p>The remaining problem here is that bootloaders usually provide a boot_params data structure. Here, the head_{32,64}.S files use a make_boot_params function (<a href="">compressed/eboot.c:693</a>) (<a href="">compressed/head_64.S:214</a>) (<a href="">compressed/head_32.S:45</a>) in order to setup this structure.</p> <p>The processor then enters the efi_stub_entry, (<a href="">compressed/head_64.S:221</a>) (<a href="">compressed/head_32.S:55</a>) the offset of which also depends on the architecture adopted by the kernel (ia32 or amd64). As implemented since the boot protocol 2.11 (<a href="">boot.txt:57</a>) (<a href="">boot.txt:1097</a>), the kernel supports EFI handover, meaning bootloaders can yield the remainder of the boot process to the EFI boot stub. This is where efi_stub_entry intervenes, representing that entry point and being stored in the handover_offset (<a href="">header.S:422</a>) (<a href="">boot.txt:728</a>) if the xloadflags (<a href="">header.S:371</a>) is set accordingly (<a href="">boot.txt:590</a>).</p> <p>The code beginning from the efi_stub_entry first calls efi_main (<a href="">compressed/eboot.c:748</a>) (not to be mistaken with the gnu-efi efi_main we talked about earlier,) which executes a basic initialization:</p> <ul> <li>Test if called by the UEFI firmware (might be called with efi_stub_entry as entry point.) Fail if not.</li> <li>Call to <a href="">setup_graphics</a>.</li> <li>Call to <a href="">setup_efi_pci</a>, which retrieves the main pci_handle (<a href="">compressed/eboot.c:65</a>) and fetches each individual device handle (<a href="">compressed/eboot.c:85</a>).</li> <li>Relocate the kernel code at the preferred address (<a href="">compressed/eboot.c:783</a>)</li> <li>Load the dummy GDT and disable interrupts (<a href="">compressed/eboot.c:857</a>).</li> <li>Performs the call to <code>ExitBootServices()</code> needed for the firmware to let go of the control (<a href="">compressed/eboot.c:800</a>) (<a href="">compressed/eboot.c:710</a>).</li> </ul> <p>After exiting efi_main successfully, the processor just jumps in the newly relocated kernel, according to the values in the boot_params (<a href="">asm/bootparams.h:111</a>) structure, stored in %eax at exit (<a href="">compressed/head_64.c:233</a>).</p> (Louis Feuvrier)68Wed, 01 Oct 2014 20:28:36 GMTLSE Week 2014: Schedule<p>Our schedule for the LSE Week 2014 is out !</p> <p>The schedule will be as follow:</p> <ul> <li>July, Thursday the 17th in the evening</li> <li>July, Friday the 18th in the evening</li> <li>July, Saturday the 19th all day long</li> </ul> <p>The complete schedule is available on the page dedicated to the <a href="">event</a></p> (Gabriel Laskar)73Wed, 02 Jul 2014 19:24:18 GMTLightning Talks Tuesday 13 2014<p>As you might have already noticed, this month lightning talks will take place on the 13th, meaning the second tuesday of the month. This will be the case each month from now on for logistical reasons.</p> <p>The program will be as follow:</p> <ul> <li>Heartbleed, technical overview by Bruno Pujos. Abstract: An explanation of the Heartbeat extension and how the Heartbleed bug is working, what kind of information can leak from it, and why it has not been found earlier.</li> <li>Anti-Virtual Machine Techniques by Pierre Rovis. Abstract: An overview of some of the techniques being used by malwares to recognize virtual machine environments, how they work and what they are detecting.</li> </ul> <p>Those conferences will take place in IP 11 from 7:30 PM.</p> (Louis Feuvrier)72Wed, 07 May 2014 18:31:04 GMTLSE Week 2014 announcement<p>For the fourth year, we are going to give 3 days of talks to show the work we are doing here at the LSE, about various themes we like, have encountered or overall judge interesting.</p> <p>The schedule will be as follow:</p> <ul> <li>July, Thursday the 17th in the evening</li> <li>July, Friday the 18th in the evening</li> <li>July, Saturday the 19th all day long</li> </ul> <p>The exact planning and subjects addressed will be announced later, as well as the exact timetable. As we did last year, we are also opening the talks to external contributors and all LSE members, present or past.</p> <p>The presentations will be held in French as usual and we will try to record everything.</p> <p>If you want to propose a talk, you can contact us at or on #lse@rezosup. The deadline for submitting content is June 8.</p> (Louis Feuvrier)71Fri, 02 May 2014 17:13:55 GMTIssue 54 in Java<h2>Introduction</h2> <p>One of the quite recent (at least, not too old) and amusing things to look at when you are beginning to study security in java is the issue 54 from Security Exploitation. This issue is quite interesting, because it is a low level trick and is, so far, not patched.</p> <h2>Security in java</h2> <p>Before talking about this particular issue, let's see some basics about security in Java in general.</p> <p>The first thing to know is what and why are we attacking java? Java is designed to run code from untrusted sources securely. This is a well known property and you can find it "everyday" in your browser with the java applets. When an applet is downloaded from a website the browser will run it and you don't want a potentially malicious attacker to have full permissions under your machine.</p> <p>Java implements a system of permissions to limit possibilities for the code executed with unprivileged rights (the applet). The goal for an attacker will be to acquire full privileges from an unprivileged application, allowing full jeopardy of the computer. The traditionnal attacks (overflow, use-after-free...) are still working but there is an additional type which is less common : the sandbox bypass (which can itself be divided in several parts: unsafe reflection, least privilege violation...).</p> <p>The security of Java is based on several things, the first is the gestion of the memory which is handled by the JVM (Java Virtual Machine) and not by the user. It first avoids most of the stupid errors developers can make, but it is also mandatory for running code safely (if we can do what we want with the memory we already have the same privilege that the program).</p> <p>The second part of the security is handled at the loading of a class. This loading process is divided into two parts: the class loader and the bytecode verifier.</p> <p>The class loader has a similar goal as the dynamic linker in Unix systems. There are several implementations (classes) of the class loader, like the applet class loader which can load code over the internet from a website. All class loaders inherit from <code>java.lang.ClassLoader</code>. Of course, a class loader has to take some precautions not to execute malicious code. In particular, it will have to check that we are not trying to spoof a System class which would allow us to bypass all security protections.</p> <p>During the validation step by the class loader, the bytecode will be checked by the bytecode verifier. It is called from the class loader through the method <code>defineClass</code>. It will not perform any check of logic but only check that the bytecode is valid and other various things, for example that it is not overflowing the stack. Once the bytecode verifier has done his work, if the class loader validates the class, the code is considered to be of no harm to the JVM (this doesn't mean you have all the privileges).</p> <p>The last important part in java security is the security manager, it's the part which will check all the permissions during runtime. If unprivileged code tries to do something forbidden, it will raise an exception. The basic class for the security manager is <code>java.lang.SecurityManager</code> Usually, the security manager will be retrieved by a call to <code>getSecurityManager</code> (<code>java.lang.System</code>).</p> <p>If the security manager is set to <code>null</code>, no check is performed and the code runs with full privileges. Therefore, the goal of a lot of exploits will be to rewrite the security manager to <code>null</code>. Some permissions allow to change the security manager and to set it to <code>null</code> (<code>AllPermission</code>, <code>setSecurityManager</code>, <code>createClassLoader</code>, <code>accessClassInPackage.sun</code>...). Typically, a permission check looks like this:</p> <pre><code>::java // From SecurityManager sm = System.getSecurityManager(); if (sm != null) sm.checkPackageAccess(name.substring(0, i)); </code></pre> <p>The method <code>checkPackageAccess</code> and all the other check functions will throw an error if the code doesn't have the rights to perform the action desired. The check looks into the stack-call and if it finds an unprivileged function, it throws an exception. To go from unprivileged code to privileged code, Java uses the <code>ActionController.doPrivileged</code> method:</p> <pre><code>::java AccessController.doPrivileged(new PrivilegedAction() { public Object run() { // insert priviledge code here } }); </code></pre> <p>This check is performed by the security manager and will stop at the first doPrivileged it finds.</p> <h2>The MethodHandle resolution mecanism</h2> <p>In the constant pool of a class file it is possible to define a <code>MethodHandle</code>. This entry in the constant pool contains two elements: the reference kind and the reference index. The reference kind characterizes the bytecode behavior of the methodhandle, there are 9 possible kinds, as follow:</p> <pre><code>REF_getField REF_getStatic REF_putField REF_putStatic REF_invokeVirtual REF_invokeStatic REF_invokeSpecial REF_newInvokeSpecial REF_invokeInterface </code></pre> <p>All 9 kinds are used to get a <code>MethodHandle</code>. This object can reference not only methods but also fields, constructors "and similar low-level operations". The kinds 1 to 4 are used to create a <code>MethodHandle</code> on a field and the reference index must point to a <code>CONSTANT_Fieldref</code>. For kinds 5 to 8 the reference index must point to a <code>CONSTANT_Methodref</code>. It is used to get a <code>MethodHandle</code> on a method.</p> <p>The last kind (<code>REF_invokeInterface</code>) is used for <code>CONSTANT_InterfaceMethodref</code> and returns a <code>MethodHandle</code> for an interface method. The interesting part about the use of a <code>CONSTANT_MethodHandle</code> into the constant pool is that the creation of the <code>MethodHandle</code> is done at the loading of the class file. Theoretically, it should make no difference between retrieving the <code>MethodHandle</code> at the loading of the class and after the loading. We will see that it's not the case.</p> <h2>Issue 54: the vulnerability</h2> <p>The issue 54 has been found by Security Exploitation and is well documented ( The usual way to get a Method Handler of a function in a class is to call the public method <code>findVirtual</code> from the <code>MethodHandles.Lookup</code> module. The code of this method is the following:</p> <pre><code>::java public MethodHandle findVirtual(Class&lt;?&gt; refc, String name, MethodType type) throws NoSuchMethodException, IllegalAccessException { MemberName method = resolveOrFail(refc, name, type, false); checkSecurityManager(refc, method); return accessVirtual(refc, method); } </code></pre> <p>In this code we can see the call to the method <code>checkSecurityManager</code> which checks whether the calling code has the right to get the <code>MethodHandle</code>. In particular, it will forbid to get a <code>MethodHandle</code> on a private method of a super-class. On the other hand, when getting a MethodHandle at class loading with a <code>REF_invokeVirtual</code>, the method called is <code>resolveVirtual</code> :</p> <pre><code>::java private MethodHandle resolveVirtual(Class&lt;?&gt; refc, String name, MethodType type) throws NoSuchMethodException, IllegalAccessException { MemberName method = resolveOrFail(refc, name, type, false); return accessVirtual(refc, method); } </code></pre> <p>We can see that the only difference between these two functions is the call to the <code>checkSecurityManager</code> function which is not done in the <code>resolveVirtual</code> method. The <code>resolveVirtual</code> function is of course private but during loading it is called by the class loader. That means that a specially crafted class can get virtual and static methods (the same issue exists with findStatic and resolveStatic) from a class, allowing to have a valid <code>MethodHandle</code> on something we shouldn't have had access to.</p> <p>This issue is also present in most of the different kinds of <code>CONSTANT_MethodHandle</code> entries in the constant pool of a class file. Still, this issue alone does not allow to execute code from an untrusted source as privileged. When Security Exploitation reported that vulnerability, they used a second one (Issue 55 to get the execution of code as privileged. The issue 55 allows to bind a <code>MethodHandle</code> to an object instance of incompatible type. This could allow to set the securitymanager to null, bypassing all the permission protection.</p> <h2>Issue 54: the exploitation</h2> <p>With this issue, Security Exploitation has released a demonstration of the the issues 54 and 55 ( In particular, it contains a class <code>MyCL.class</code> which is "hand made", and contains the exploitation of issue 54. Here is the constant pool of this class:</p> <pre><code>::java CONSTANT_MethodRef(10) 5, 16 CONSTANT_MethodRef(10) 5, 17 CONSTANT_String(8) 10 CONSTANT_Class(7) 18 CONSTANT_Class(7) 19 CONSTANT_Utf8(1) 6 : &lt;init&gt; CONSTANT_Utf8(1) 3 : ()V CONSTANT_Utf8(1) 4 : Code CONSTANT_Utf8(1) 15 : LineNumberTable CONSTANT_Utf8(1) 5 : dummy CONSTANT_Utf8(1) 57 : (Ljava/lang/String;[BIILjava/security/ProtectionDomain;)V CONSTANT_Utf8(1) 18 : get_defineClass_mh CONSTANT_Utf8(1) 20 : ()Ljava/lang/Object; CONSTANT_Utf8(1) 10 : SourceFile CONSTANT_Utf8(1) 9 : CONSTANT_NameAndType(12) 6, 7 CONSTANT_NameAndType(12) 20, 21 CONSTANT_Utf8(1) 4 : MyCL CONSTANT_Utf8(1) 21 : java/lang/ClassLoader CONSTANT_Utf8(1) 11 : defineClass CONSTANT_Utf8(1) 73 : (Ljava/lang/String;[BIILjava/security/ProtectionDomain;)Ljava/lang/Class; CONSTANT_MethodHandle(15) REF_invokeVirtual(5), 2 </code></pre> <p>We can see that the entry 22 is a <code>CONSTANT_MethodHandle1</code> with the kind <code>REF_invokeVirtual</code> for exploiting the vulnerability and refer to the <code>CONSTANT_MethodRef</code> at the entry 2, which is in the class java.lang.ClassLoader the method <code>defineClass</code>.</p> <p>The <code>defineClass</code> method in <code>java.lang.ClassLoader</code> is a protected final method and it should be impossible to have an handle on this method and obviously to call it.</p> <p>In <code>MyCL.class</code> we have three methods :</p> <ul> <li><code>&lt;init&gt;</code> which is for the initialisation</li> <li><code>dummy</code></li> <li><code>get_defineClass_mh</code> which returns the <code>CONSTANT_MethodHandle</code> at the entry 22 of the constant pool.</li> </ul> <p>The other part of the exploit is for the issue 55 which will allow to bind the method handle to another class and get it called with privileged rights, allowing a sandbox bypass.</p> <h2>Conclusion</h2> <p>This issue, even if a little old, is really interesting because it puts in light some internals of the class loading process which are often unclear. It is also really disturbing because Oracle doesn't seem to consider this issue as a problem, indicating that this was an "allowed behavior". Still not patched, this issue can be used for developing exploits, enlarging the possibility for finding vulnerabilities. Even if this issue was basically focused on a MethodHandle pointing to a method, the same problem exists with MethodHandle pointing on a field, allowing to gain even more access.</p> (Fabien Goncalves), (Louis Feuvrier) and (Bruno Pujos)70Tue, 29 Apr 2014 09:05:00 GMT0xCAFEBABE ? - java class file format, an overview<p>Lately, we’ve been having a look into java. First, we tried to understand the file-format. A java application is often presented in a .jar, which is basically a zip archive (you can also find .war files which are also zip archive). Inside this archive you'll find several files, especially some .class files which are the one containing the java bytecode. Those files are the one we'll look into.</p> <p>The file begins with a header including the magic number (<code>0xCAFEBABE</code>), the minor version which is 0 and the major version for Java SE 7: <code>0x0033</code> (51.00). Every number in the class file are stored in big-endian. Right after that header, we can find the Constant Pool count which is the number of entries in the constant pool table plus one and then the array. There are several entries representing several items in the constant pool like constants, classes, etc..</p> <p>After that, there is the access flag of the class, the <code>this_class</code> and <code>super_class</code> identifiers which are indices in the constant pool in order to refer to the current class and the super class. This is followed by the interface table and its size, the table contains all the interfaces from which the current class inherits. Then we find the field table and size, followed by the methods and the attributes of the class.</p> <p>Here is mainly an overview of the class file.</p> <p><img alt="Class overview" src="/medias/images/Class_overview.png" /></p> <h2>Constant Pool</h2> <p>The constant pool is probably the most important part of the Class file. It contains all the information that will be needed on the other part of the file. The constant pool is an array containing several entries, the index of the array starts at 1, not 0. The different structures in the table do not have the same size, and so the constant pool may have a variable size. Each entry begins with a tag on one byte, indicating the type of entry:</p> <ul> <li> <p><code>CONSTANT_Utf8</code> : indicating an utf8 modified entry. Java uses a particular type of utf8 for representing the constant string values.</p> </li> <li> <p><code>CONSTANT_Integer</code> : representing a constant integer on 4 bytes, just like everything in the class file format the integer is a big-endian.</p> </li> <li> <p><code>CONSTANT_Float</code> : representing a float on 4 bytes, it follows the IEEE 754 floating point format, with possibility of representing both infinity and NaN.</p> </li> <li> <p><code>CONSTANT_Long</code> : same as <code>CONSTANT_Integer</code> but represents the integer on 8 bytes. Something particular about this entry is that it is counting twice in the constant pool’s number of entries.</p> </li> <li> <p><code>CONSTANT_Double</code> : as <code>CONSTANT_Float</code> it follows the IEEE 754 for the double format, like <code>CONSTANT_Long</code> it stores the number on 8 bytes and also counts twice in the constant pool.</p> </li> <li> <p><code>CONSTANT_Class</code> : this one is used to represent a class or an interface, it has only one caracteristic which is an index in the constant pool to a <code>CONSTANT_Utf8</code> indicating the name of the class.</p> </li> <li> <p><code>CONSTANT_String</code> : its goal is to represent constant object of string type. like <code>CONSTANT_Class</code>, it only contains one information which is the index of a <code>CONSTANT_Utf8</code> in the constant pool to represent the string’svalue.</p> </li> <li> <p><code>CONSTANT_Fieldref</code> : this represents a reference to a field. it contains the index of <code>CONSTANT_Class</code> to represent the class or interface in which the field is and the index of a <code>CONSTANT_NameAndType</code> (see below) for representing the name and the field’s type. (</p> </li> <li> <p><code>CONSTANT_Methodref</code> : like <code>CONSTANT_Fieldref</code>, it contains a <code>CONSTANT_Class</code> index and a <code>CONSTANT_NameAndType</code>. The <code>CONSTANT_Class</code> must represent a class and not an interface. The <code>CONSTANT_NameAndType</code> must represent a method descriptor (</p> </li> <li> <p><code>CONSTANT_InterfaceMethodref</code> : it is similar to the <code>CONSTANT_Methodref</code> type except that the <code>CONSTANT_Class</code> entry must represent an interface.</p> </li> <li> <p><code>CONSTANT_NameAndType</code> : this structure is used to represent a field or method without indicating the class or interface it belongs to, it contains two indices in the constant pool which must have the type <code>CONSTANT_Utf8</code>, the first represents the name and the other one represents a valid descriptor of the field or the method.</p> </li> <li> <p><code>CONSTANT_MethodHandle</code> : this field is used to resolve symbolic reference to a method handle. The way of resolving a method depends on something called the bytecode behavior which is indicated by a kind indicator (from 1 to 9). It also contains a reference on two bytes which is an index in the constant pool pointing on a <code>CONSTANT_Fieldref</code>, <code>CONSTANT_Methodref</code> or <code>CONSTANT_InterfaceMethodref</code> depending on the kind.</p> </li> <li> <p><code>CONSTANT_MethodType</code> : this field is used to resolve the method’s type, it contains an index to a <code>CONSTANT_Utf8</code> which should represent the method’s type.</p> </li> <li> <p><code>CONSTANT_InvokeDynamic</code> : this structure is used by the invokedynamic instruction to specify a bootstrap method. It contains an index into the bootstrap method table (see attributes below) and an index into the constant pool to a <code>CONSTANT_NameAndType</code> representing the method name and method descriptor.</p> </li> </ul> <p>Here is global overview of each of those structures:</p> <p><img alt="Constant Pool" src="/medias/images/Constant_pool.png" /></p> <h2>General and Interfaces</h2> <p>After the Constant Pool, we can find several information about the current class, there is an information about the class name and the superclass. There are also general information about the class in the access flag. There are several access flag types for classes, fields and methods. The different kind of access flags are:</p> <p><img alt="Access Flag" src="/medias/images/Access_flag.png" /></p> <p>After the general information field, there is an information field about the interfaces. All the interfaces the class implements are represented in the interface table. Each entry in that table is a constant pool index representing a <code>CONSTANT_Class</code> which must be an interface.</p> <h2>Attributes</h2> <p>Each field, method and class have others characteristics and informations. These information are contained inside attributes. There are several attribute types, each one of them can be applied to one or several fields, methods, classes and codes. The attributes are used to represent :</p> <ul> <li>Code</li> <li>Local variables, constant value, information about the stack and exceptions</li> <li>Inner Classes, Bootstrap Methods, Enclosing methods</li> <li>Annotations</li> <li>Information for debug/decompilation</li> <li>Complementary information (Deprecated, Signature...)</li> </ul> <p>Each attribute begins by an index into the constant pool, it must point to a <code>CONSTANT_Utf8</code> entry telling which type of attribute this is. Afterward, since the different types of attributes have different structures, the attribute length is indicated. An implementation of the Java Virtual Machine is not necessary in order to handle each kind of attribute because knowing the length allows to pass an unhandle attribute and execute correctly the file.</p> <p>The most important attribute is probably the Code:</p> <p><img alt="Code Attribute" src="/medias/images/Code_attribute.png" /></p> <p>It begins with the common header, the attribute name index should point to a <code>CONSTANT_Utf8</code> representing the string <code>"Code"</code>.</p> <p>It is followed by two variables: max stack and max locals which represent the stack size and the size of the local variables including the one used for passing arguments to methods. Then there is the code length and the code which is the bytecode that will be executed by the JVM when the method is called.</p> <p>Right after that, you’ll find a table representing the exception handlers inside the functions, it indicates the start and the end of the zone where the exception should be catched, the start of the entry if the exception is raised and the catch type which is an index to a <code>CONSTANT_Class</code> into the constant pool. The catch type can also be 0, in this case it will be called with every exceptions, this is in generally used for the finally statement.</p> <p>After the exceptions section, it is possible to add some attributes for the code especially about the stack and the local variable. The Code is an attribute that may contain other attribute.</p> <h2>Fields &amp; Methods</h2> <p>The fields and methods are added in two tables which contain the same elements. The access flags are different for the fields and methods since they are represented above.</p> <p>After the flag section, we find the name which is an index to a <code>CONSTANT_Utf8</code> in the constant pool representing the name of the method/field. The descriptor index is also an index to a <code>CONSTANT_Utf8</code> which represents a descriptor defining the method or field type.</p> <p>Finally, the method and field can have attributes, moreover a method will contain a code attribute which will contain itself the method code.</p> <h2>Conclusion</h2> <p>The class file is really important for the JVM and having a look at the file format explains a lot of things about the way the JVM work internally.</p> <p>Recently Java SE 8 has been released, there are several small differences with Java SE 7 even though the major part of the class file has not changed. In particular, it defines new attributes : <code>RuntimeVisibleTypeAnnotations</code>, <code>RuntimeInvisibleTypeAnnotations</code> and <code>MethodParameters</code>.</p> <p>There are also several modifications in different sections changing the default behaviour of the JVM. It also adds precision and constraints to parts of the class file. The version number for Java SE 7 is 51.00 and 52.00 for Java SE 8.</p> <p>We’ve written a parser of the class file format in Python3 that you can find here : <a href="/medias/data/"></a>.</p> <p>It uses the srddl module for python, available here : <a href="https//"></a></p> (Nassim Eddequiouaq) and (Bruno Pujos)69Mon, 28 Apr 2014 23:51:31 GMTLightning Talks Tuesday, 1st April<p>Here is the lightning talk program for the 1st April :</p> <ul> <li>Portable Executable: Overview of the executables files on Windows. by Jérémy Lefaure</li> <li>A first peek at asymmetric cryptography: The RSA cryptosystem. by Fabien Goncalves</li> <li>Introduction to Register Transfer Level: a simple way to design synchronous digital circuits. by Pierre Surply</li> <li>Analysing unknown data with python. by Rémi Audebert</li> </ul> <p>Talks will start in amphi 4, at 19h30.</p> <p>And here are the slides from last time :</p> <ul> <li>Malloc Internals by Bruno Pujos - <a href=" Pujos-Malloc internals.pdf">Slides</a></li> <li>vsyscall/vDSO by Adrien Schildknecht - <a href=" Schildknecht-vsyscall vDSO.pdf">Slides</a></li> <li>Qemu integrated testing: liqtest / libqos by Nassim Eddequiouaq - <a href=" Eddequiouaq-Qemu integrated testing.pdf">Slides</a></li> </ul> (Gabriel Laskar)66Thu, 20 Mar 2014 14:29:02 GMTLightning Talks at EPITA, Tuesday, March 4th 2014<p>Every month, on the first Tuesday of the month, we will have a lightning talk session.</p> <p>Last Month (February 11th) we had :</p> <ul> <li>Introduction to TI PRUSS by Pierre Surply - <a href=" Surply-tipruss.pdf">Slides</a></li> <li>PS/2 Archeology by Gabriel Laskar - <a href=" Laskar-PS2 Archeology.pdf">Slides</a></li> <li>IDAPython walkthrough by Bruno Pujos</li> </ul> <p>On Tuesday, we will have :</p> <ul> <li>Malloc Internals by Bruno Pujos</li> <li>vsyscall/vDSO by Adrien Schildknecht</li> <li>Qemu integrated testing: liqtest / libqos by Nassim Eddequiouaq</li> </ul> <p>Talks will start in amphi 1, at 19h30.</p> (Gabriel Laskar)65Fri, 28 Feb 2014 13:29:16 GMT