python_feedgen_maxwelldulin.invades.space.rss.xml - sfeed_tests - sfeed tests and RSS and Atom files
 (HTM) git clone git://git.codemadness.org/sfeed_tests
 (DIR) Log
 (DIR) Files
 (DIR) Refs
 (DIR) README
 (DIR) LICENSE
       ---
       python_feedgen_maxwelldulin.invades.space.rss.xml (96900B)
       ---
            1 <?xml version='1.0' encoding='UTF-8'?>
            2 <rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0"><channel><title>Maxwell Dulin's Blog</title><link>https://maxwelldulin.com/Blog</link><description>ꓘ's 1337 blog</description><docs>http://www.rssboard.org/rss-specification</docs><generator>python-feedgen</generator><language>en-US</language><lastBuildDate>Sat, 02 Oct 2021 00:00:03 +0000</lastBuildDate><item><title>Resetting Passwords  - What Could Possibly Go Wrong?</title><link>https://maxwelldulin.com/BlogPost?post=3702041600</link><description>&lt;meta property="og:image" content="https://maxwelldulin.com/static/favicon.ico"/&gt;
            3 
            4 &lt;h2&gt;Introduction&lt;/h2&gt;
            5 &lt;p&gt;
            6 Recently, a friend of mine (from outside the United States) had a third party make them a website for  eCommerce sales and blogging. Because of this, they wanted me to do a quick review of the security of the application. After reviewing the account handling on the application I determined that the Password Reset functionality was the &lt;b&gt;worst implementation ever made&lt;/b&gt;. If you can think of an issue I bet this had it... Below, we will be going into what went wrong and how to find these types of issues yourself. 
            7 &lt;/p&gt;
            8 
            9 &lt;h2&gt;Back to the Basics&lt;/h2&gt;
           10 
           11 &lt;p&gt;
           12 If accounts exists on a website there are some basic features of it: 
           13 &lt;ul&gt;
           14 &lt;li&gt;Create Account&lt;/li&gt;
           15 &lt;li&gt;Login&lt;/li&gt;
           16 &lt;li&gt;Forgot Password/ Password Reset&lt;/li&gt;
           17 &lt;li&gt;Update Account&lt;/li&gt;
           18 &lt;li&gt;Delete Account&lt;/li&gt;
           19 &lt;li&gt;View Account&lt;/li&gt;
           20 &lt;/ul&gt;
           21 
           22 If any of these is done in insecure way, major havoc can occur. In this blog post, we will be paying special attention to the &lt;i&gt;Password Reset&lt;/i&gt; functionality of a website and how it can go wrong. 
           23 &lt;/p&gt;
           24 
           25 &lt;h3&gt;
           26 Basic Flow of Password Reset
           27 &lt;/h3&gt;
           28 &lt;p&gt;
           29 What do you do if a user forgets their password? Well, you want them to be able to login, but you still want to make sure that it is the correct user. So, it is time to rest their password. 
           30 &lt;/p&gt;
           31 &lt;p&gt;
           32 Generally, a users account is tied to an email. With this, the website can send this users email a &lt;i&gt;magic link&lt;/i&gt;. This magic link deems that the user is trusted and will allow them to change the password. 
           33 &lt;/p&gt;
           34 
           35 &lt;!-break--&gt; 
           36 
           37 &lt;p&gt;
           38 Once the link is clicked on, a user can select their new password. When the user sends the new password to the backend, the &lt;i&gt;magic value&lt;/i&gt; is sent back along with it. This is so that the &lt;i&gt;magic value&lt;/i&gt; can be verified from the link to ensure this is the correct user. With the correct value, the password is reset and the user can continue! What could possibly go wrong? 
           39 &lt;/p&gt;
           40 
           41 &lt;h2&gt;
           42 What Went Wrong #1 - Email Enumeration (Low) 
           43 &lt;/h2&gt;
           44 &lt;p&gt;
           45 From the very beginning, the reset functionality had issues. The initial request gave two different messages, depending on if the email was valid or invalid. The initial request, with an improper email, gave back the following error message: 
           46 &lt;div style="width:98%; font-size:80%; text-align:center; float : left; border: 1px solid black; border-radius: 10px; margin: 10px;"&gt;&lt;img src="https://live.staticflickr.com/65535/50124974596_bcd7877b69_c.jpg" width="95%" alt=""&gt;&lt;center&gt;Incorrect Email Message&lt;/center&gt;&lt;/div&gt;
           47 
           48 With a valid email, it just said that the email had been sent. 
           49 &lt;/p&gt;
           50 &lt;p&gt;
           51 But, why is this bad? Because it is trivial to distinguish between a valid and invalid email, this can provide an easy way for &lt;b&gt;email enumeration&lt;/b&gt; of users with an account. This by itself is not a huge deal, but can be used in further attacks and information leakage. 
           52 &lt;/p&gt;
           53 
           54 &lt;h2&gt;
           55 What Went Wrong #2 - Host Header Injection (High)
           56 &lt;/h2&gt;
           57 
           58 &lt;p&gt;
           59 Now, this time, we are going to input a valid email address. Everything works are expected... So, let's tamper with the request itself!
           60 &lt;/p&gt;
           61 
           62 &lt;h3&gt;
           63 Host Header
           64 &lt;/h3&gt;
           65 &lt;p&gt;
           66 HTTP sends a plethora of different headers on each request, such as the Origin, Cookies, Content-Type and more. The important one for this attack is the &lt;i&gt;Host Header&lt;/i&gt;. The Host Header is defined as
           67 &lt;code&gt;Specifies the domain name of the server.
           68 &lt;/code&gt; by Mozilla. In layman's terms, this simply means the host name (domain) without the protocol. 
           69 &lt;/p&gt;
           70 
           71 &lt;p&gt;
           72 Even though the Host is set in the browser on a normal request (and cannot be altered), software like Burp and Curl can trivially spoof header/value in a request made to the backend. If the backend is trusting any of these values in an improper way, havoc can unfold.  
           73 &lt;/p&gt;
           74 
           75 &lt;h3&gt;
           76 Havoc
           77 &lt;/h3&gt;
           78 &lt;p&gt;
           79 The Host Header is sometimes used in order to create links from it. So, what if we alter the host header? It turns out that by altering the Host header, the &lt;i&gt;domain&lt;/i&gt; of the link can be changed! For example, see the following screenshot: 
           80 &lt;div style="width:98%; font-size:80%; text-align:center; float : left; border: 1px solid black; border-radius: 10px; margin: 10px;"&gt;&lt;img src="https://live.staticflickr.com/65535/50127447947_747f10d5bd_c.jpg" width="95%" alt=""&gt;&lt;center&gt;Host Header Injection &lt;/center&gt;&lt;/div&gt;
           81 &lt;/p&gt;
           82 
           83 &lt;p&gt;
           84 What's the attack here though? Well, this means that when the link is clicked (in the users email), the redirect (along with the magic value) will be sent to an &lt;b&gt;attacker controlled host&lt;/b&gt;! Once the link has been clicked, the attacker can simply use this reset token and reset the users password. Below is an example of the password reset link, after the host header modification, with the magic value: 
           85 
           86 &lt;div style="width:98%; font-size:80%; text-align:center; float : left; border: 1px solid black; border-radius: 10px; margin: 10px;"&gt;&lt;img src="https://live.staticflickr.com/65535/50127221241_cdec327d96_c.jpg" width="95%" alt=""&gt;&lt;center&gt;Email Reset Link&lt;/center&gt;&lt;/div&gt;
           87 &lt;/p&gt;
           88 
           89 &lt;h2&gt;
           90 What Went Wrong #3 - Short Reset Token (Medium/High)
           91 &lt;/h2&gt;
           92 &lt;p&gt;
           93 If we ignore the first issue (that takes a single click from the user) what else is out there? Immediately, when I hovered over the reset link, I noticed that only 6 digits were being used for the token. &lt;b&gt;SIX&lt;/b&gt;. 
           94 &lt;/p&gt;
           95 &lt;p&gt;
           96 Mathematically, this is 10^6 or 1,000,000 chances. With no throttling and a fairly long expiration time on the tokens (which are both issues in their own right), this is possible to brute force from a single computer.  
           97 &lt;/p&gt;
           98 
           99 &lt;p&gt;
          100 By requesting a reset email for a single user then attempting &lt;i&gt;each&lt;/i&gt; of the tokens in the set, it would be possible to reset the users password! Although this would take some time to perform, it is absolutely a viable attack method for taking over an account. 
          101 &lt;/p&gt;
          102 
          103 &lt;h2&gt;
          104 What Went Wrong #4 - Lack of Server Side Validation (Critical) 
          105 &lt;/h2&gt;
          106 
          107 &lt;p&gt;
          108 You are probably thinking &lt;i&gt;'There are already two ways to take over the account, what else could go wrong?'&lt;/i&gt; You are in luck though, because there is one more major bug. 
          109 &lt;/p&gt;
          110 
          111 &lt;p&gt;
          112 Upon clicking on the link to go back to the website, the magic token was validated. Now, all the user has to do is send the new password back to the backend. Do you see anything wrong with this?
          113 
          114 &lt;/p&gt;
          115 
          116 &lt;h3&gt;
          117 Lack of Validation of Token
          118 &lt;/h3&gt;
          119 &lt;p&gt;
          120 The first request validates the password reset token. But, the second request, where the password was actually being reset, did &lt;b&gt;not&lt;/b&gt; include the &lt;i&gt;magic value&lt;/i&gt;! Because of this, a single request could reset any users password; it was really as simple as that! A picture of the request in Burp is shown below:  
          121 &lt;div style="width:98%; font-size:80%; text-align:center; float : left; border: 1px solid black; border-radius: 10px; margin: 10px;"&gt;&lt;img src="https://live.staticflickr.com/65535/50124483628_ef20fa7938_c.jpg" width="95%" alt=""&gt;&lt;center&gt;Password Reset Request&lt;/center&gt;&lt;/div&gt;
          122 
          123 Notice that the above request does not include the &lt;i&gt;magic value&lt;/i&gt; inside of it. Boom, a single request to compromise the account: no clicks or brute forcing needed. 
          124 &lt;/p&gt;
          125 
          126 
          127 &lt;h2&gt;
          128 Fixing
          129 &lt;/h2&gt;
          130 &lt;p&gt;
          131 The creators of the website were from a third world country where English is not the primary language and the people only speak a little English. So, when looking for resources in their language, we could not find very much about the vulnerabilities discussed above. In particular, there was &lt;i&gt;nothing&lt;/i&gt; online referring to Host Header Injection. To solve this problem, I took videos of myself exploiting the vulnerabilities while speaking slow and simple English. With this, I also sent links in the native language and in some better ones in English.
          132 &lt;/p&gt;
          133 
          134 &lt;p&gt;
          135 After reporting the findings, the token was being validated on the backend and the proper entropy was added to the reset tokens. However, because of the lack of resources (and difficulty) for the security patches, the &lt;i&gt;Host Header Injection&lt;/i&gt; took &lt;b&gt;4 attempts&lt;/b&gt; to try to fix. The owner of the site said they would not pay until the issue was fixed. Magically, the next day, the vulnerability was patched! So, I'm unsure if they did not care about patching the bug or if they just did not know how. Regardless, this makes me consider the security of websites outside of the normal public eye and whether or non-English speakers have the proper resources to make secure software.  
          136 &lt;/p&gt;
          137 
          138 &lt;h2&gt;
          139 Test Cases 
          140 &lt;/h2&gt;
          141 
          142 &lt;p&gt;
          143 Password reset functionality is one of the hardest aspects of the user experience to get right. When something does go wrong with this, an account compromise can occur. Below are a list of issues with the password reset functionality found during this security review:
          144 &lt;ul&gt;
          145 &lt;li&gt;Username/email enumeration&lt;/li&gt;
          146 &lt;li&gt;Host Header Injection&lt;/li&gt;
          147 &lt;li&gt;Insufficient Length of Reset Tokens &lt;/li&gt;
          148 &lt;li&gt;Lack of Validation of Magic Values&lt;/li&gt;
          149 &lt;li&gt;Extended Expiration Time on Token&lt;/li&gt;
          150 &lt;li&gt;Lack of Brute Force Protections&lt;/li&gt;
          151 &lt;/ul&gt;
          152 
          153 Besides the issues described above, there are a few more that should be tested for:
          154 
          155 &lt;ul&gt;
          156 &lt;li&gt;Sending New Passwords over Email&lt;/li&gt;
          157 &lt;li&gt;Lack of Two Factor Authentication&lt;/li&gt;
          158 &lt;li&gt;Multiple Uses for a Single Reset Token&lt;/li&gt;
          159 &lt;li&gt;Reset tokens Not Specific To User&lt;/li&gt;
          160 &lt;/ul&gt;
          161 
          162 This is a fairly good list for testing password reset functionality. But, the test cases differ depending on the implementation.
          163 &lt;/p&gt;
          164 
          165 &lt;h3&gt;
          166 Defense In Depth
          167 &lt;/h3&gt;
          168 &lt;p&gt;
          169 Some of the issues listed above do not lead to a direct compromise of the user account but are considered best practice. By having a &lt;i&gt;defense-in-depth&lt;/i&gt; mindset, subtle issues become very difficult or impossible to exploit. 
          170 &lt;/p&gt;
          171 
          172 &lt;p&gt;For instance, the &lt;i&gt;insufficient token length&lt;/i&gt; vulnerability was made possible to exploit by a lack of brute force protections and extended length of the tokens times. If the brute forcing was not possible, this vulnerability would have been very difficult to exploit. 
          173 &lt;/p&gt;
          174 
          175 &lt;p&gt;
          176 Overall, adding slight security optimizations makes the overall security of the site much better. In the case that a single issue is found, having defense-in-depth measures can make the vulnerability more difficult to exploit for an attacker. During assessments, it is extremely important to point out not just impactful vulnerabilities but small/subtle things to help out the overall security of the site. 
          177 &lt;/p&gt;
          178 
          179 
          180 &lt;h2&gt;
          181 Conclusion
          182 &lt;/h2&gt;
          183 &lt;p&gt;
          184 Security is hard to get right! This is why having hackers poke around is a good thing (of course, get permission first). I hope you enjoyed the article and learned something interesting about web applications today. Feel free to reach out to me (contact information is in the footer) if you have any questions or comments about this article. Cheers from &lt;b&gt;Maxwell "ꓘ" Dulin&lt;/b&gt;.
          185 &lt;/p&gt;</description><guid isPermaLink="false">https://maxwelldulin.com/BlogPost?post=3702041600</guid><pubDate>Sun, 19 Jul 2020 00:00:00 +0000</pubDate></item><item><title>House of Muney - Leakless Heap Exploitation Technique</title><link>https://maxwelldulin.com/BlogPost?post=6967456768</link><description>&lt;h2&gt;
          186 Introduction
          187 &lt;/h2&gt;
          188 &lt;p&gt;
          189 Exploiting different heap libraries tends to be difficult, complex and requires a deep knowledge of the library itself. Recently, Qualys decided to go back and exploit a &lt;u&gt;15 year&lt;/u&gt; bug in QMail that was thought to unexploitable with some incredible techniques. &lt;a href="https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-execution-qmail.txt"&gt;This exploit&lt;/a&gt; uses a very interesting quirk of Malloc and exploit method that had not been seen before, which I have decided to name the &lt;b&gt;House of Muney&lt;/b&gt;. 
          190 &lt;/p&gt;
          191 
          192 &lt;p&gt;In this article, I wanted to shed more light on the exploitation method that was used by the Qualys researchers to ensure there is a well-documented location for this exploit method. In short, it is broken up into &lt;i&gt;Munmap&lt;/i&gt;ing part of LibC and to &lt;i&gt;rewrite&lt;/i&gt; the symbol table to get code execution. There are two main perks of this technique: this &lt;b&gt;bypasses ASLR&lt;/b&gt; entirely and works on &lt;b&gt;mmap&lt;/b&gt; chunks in GLibC Malloc. 
          193 &lt;/p&gt;
          194 
          195 &lt;p&gt;
          196 Just as a fair warning, this article has quite a bit of background knowledge to understand the exploit. If you think you have a good understanding a section, it is recommended you still review the section just to refamilarize yourself with the content. In this article, the following is discussed as background: 
          197 &lt;ul&gt;
          198 &lt;li&gt;Malloc Chunk (general)&lt;/li&gt;
          199 &lt;li&gt;Mmap and Munmap&lt;/li&gt;
          200 &lt;li&gt;Malloc Mmap Chunks &lt;/li&gt; 
          201 &lt;li&gt;ELF Symbol Resolution&lt;/li&gt;
          202 &lt;/ul&gt;
          203 &lt;/p&gt;
          204 
          205 
          206 &lt;p&gt;
          207 The article also comes with a working POC on version 2.31 of Malloc on my Github (mdulin2) at &lt;a href="https://github.com/mdulin2/munmap-and-rewrite"&gt; House of Muney&lt;/a&gt; if you would like to follow along. Additionally, if you want more security content, take a look at the &lt;a href="https://maxwelldulin.com/Resources"&gt;resources&lt;/a&gt; or other blog posts. Now, with the introduction out of the way, let's dive into the technical details. 
          208 &lt;/p&gt;
          209 
          210 &lt;h2&gt;
          211 GLibC Malloc Background
          212 &lt;/h2&gt;
          213 
          214 &lt;h3&gt;
          215 Chunks
          216 &lt;/h3&gt;
          217 
          218 &lt;p&gt;
          219 Chunks are the main object that users interact with. There are two main states to a chunk: &lt;i&gt;allocated&lt;/i&gt; and &lt;i&gt;free&lt;/i&gt;.  The following picture demonstrates a &lt;i&gt;free&lt;/i&gt; chunk: 
          220 &lt;div style="width: 98%; font-size:80%; text-align:center; float : left; border: 1px solid black; border-radius: 10px; margin: 10px;"&gt;&lt;img src="https://docs.google.com/drawings/d/1YrlnGa081NpO0D3wcoaJbGvhnPi3X6bBKMc3bN4-oZQ/pub?w=940&amp;h=669" width="95%" alt=""&gt;&lt;center&gt;Figure 1 - Free Chunk by Sploitfun&lt;/center&gt;&lt;/div&gt;
          221 
          222 
          223 The first field is the size of the previous chunk (prev_size). This is only used if the previous chunk is free. The second field is the &lt;b&gt;chunk size&lt;/b&gt;. The chunk size represents the size of the data of the chunk and the metadata about the chunk. The metadata of the chunk includes three fields: prev_inuse (if the previous chunk is in use), mmap (is the previous chunk mmapped) and if the chunk is in a non-main arena. 
          224 &lt;/p&gt;
          225 
          226 &lt;p&gt;
          227 On an allocated (non-free) chunk, the third and fourth field are used as data sections. However, on a free chunk, the third field is used in order to store a pointer to other freed chunks. This field is known as the forward pointer or the &lt;i&gt;Fd&lt;/i&gt; field. The fourth field is exactly the same, except that it stores a backwards pointer or &lt;i&gt;bk&lt;/i&gt;. &lt;!-break--&gt; 
          228 &lt;/p&gt;
          229 
          230 &lt;p&gt;
          231 This is a very small background on chunks but is all that is needed for the article. For further information, please to refer to &lt;a href ="https://sploitfun.wordpress.com/2015/02/10/understanding-glibc-malloc/"&gt;Sploitfun's&lt;/a&gt; amazing article about GLibC. 
          232 &lt;/p&gt;
          233 
          234 &lt;h2&gt;
          235 Mmap and Munmap
          236 &lt;/h2&gt;
          237 &lt;p&gt;
          238 &lt;i&gt;Mmap&lt;/i&gt; is used in order to create a new address mapping in the virtual address space. Mmap is the system call used behind the beginning mapping of all programs and is an extremely low level function (well, it is even a syscall). 
          239 &lt;/p&gt;
          240 
          241 &lt;p&gt;
          242 Munmap is the opposite of mmap: &lt;i&gt;munmap&lt;/i&gt; deletes the mappings for the specified address range. If anything in this range is attempted to be accessed, it is considered an invalid address and results in an access violation. For more information on these low level functions, refer to the &lt;a href="https://linux.die.net/man/2/munmap"&gt;man pages&lt;/a&gt;. 
          243 &lt;/p&gt;
          244 
          245 &lt;h2&gt;
          246 GLibC Malloc Mmap Chunks
          247 &lt;/h2&gt;
          248 &lt;p&gt;
          249 In Malloc, if a requested size is above a certain threshold then a separate call is made to mmap in order to get a new section of memory for this particular chunk. Very large chunks (which will be referred to as &lt;b&gt;Mmap chunks&lt;/b&gt; from this point on) are not handled like normal chunks though. 
          250 &lt;/p&gt;
          251 
          252 &lt;h3&gt;
          253 Mmap Chunks Differences
          254 &lt;/h3&gt;
          255 
          256 &lt;p&gt;
          257 &lt;div style="width:97%; font-size:80%; text-align:center; border: 1px solid black; border-radius: 10px; margin: 10px;"&gt;&lt;img src="https://live.staticflickr.com/65535/50316980181_4ff13b5811_z.jpg" width="97%"; alt=""&gt;&lt;center&gt;Figure 2 - Simplified Munmap Chunk GLibC 2.31 &lt;/center&gt;&lt;/div&gt;
          258 
          259 Once an mmap chunk is freed, they are sent back to system memory with a call to &lt;i&gt;munmap&lt;/i&gt; (as seen in Figure 2). With a normal chunk, it is given back to a bin to be used later. 
          260 &lt;/p&gt;
          261 
          262 &lt;p&gt;
          263 
          264 With mmap chunks, the prev_size field is used for part of the chunk that went unused with this specific allocation. The prev_size is added to the size of the mmap chunk to know how much memory to munmap, or free.
          265 &lt;/p&gt;
          266 
          267 &lt;p&gt;
          268 The final difference is that the second bit of the size is used in order to determine if this is an mmap chunk or not (the 'M' bit in Figure 1). 
          269 &lt;/p&gt;
          270 
          271 &lt;h3&gt;
          272 Munmap Madness
          273 &lt;/h3&gt;
          274 
          275 &lt;p&gt;
          276 With the funky handling of mmap chunks in GLibC, it was bound that somebody had done research on this in the past. In a very well-done article by Tukan titled &lt;a href="http://tukan.farm/2016/07/27/munmap-madness/"&gt;Munmap Madness&lt;/a&gt;, the author dives into the possibilities of what can happen with corrupted mmap Malloc chunks. In this article, the author discusses how mmap chunks work, potential exploits and weird quirks about it. For more information on mmap chunks, please refer to his &lt;a href="http://tukan.farm/2016/07/27/munmap-madness/"&gt;article&lt;/a&gt;. 
          277 &lt;/p&gt;
          278 
          279 &lt;p&gt;
          280 What we are taking from the the &lt;i&gt;Munmap Madness&lt;/i&gt; article, is that the author mentions &lt;i&gt;altering the size&lt;/i&gt; of an Mmap chunk to trigger the removal (munmap) of a section of memory. The main interests are the other parts of a program, such as a thread stack, LibC and so on. Although altering LibC may be difficult, the focus of this article will be on &lt;i&gt;munmapping&lt;/i&gt; a small section of LibC in order to take control of the program later. 
          281 &lt;/p&gt;
          282 
          283 
          284 &lt;h2&gt;
          285 Symbol Lookup
          286 &lt;/h2&gt;
          287 &lt;p&gt;
          288 With ELF files, one would think that Symbol Lookup would be a trivial task. However, Symbol lookup is vastly complex and takes quite of bit of time to understand. In this article, only the GOT/PLT sections will be briefly discussed and the actual dynamic symbol table lookup process will be briefly discussed later. 
          289 &lt;/p&gt;
          290 
          291 &lt;h3&gt;
          292 PLT and GOT
          293 &lt;/h3&gt;
          294 
          295 &lt;p&gt;
          296 Have you ever wondered &lt;b&gt;how&lt;/b&gt; library functions are magically found without the actual function being defined in the binary? Well, I can tell ya, it is pretty black magic-y! 
          297 &lt;/p&gt;
          298 
          299 &lt;div style="width:97%; float:left; font-size:80%; text-align:center; border: 1px solid black; border-radius: 10px; margin: 10px;"&gt;&lt;img src="https://eli.thegreenplace.net/images/2011/plt_before.png" width="97%"; alt=""&gt;&lt;center&gt;Figure 3 - GOT First Time by Eli Bendersky&lt;/center&gt;&lt;/div&gt;
          300 
          301 &lt;p&gt;
          302 First off, a library function call is replaced with a function stub, known as the &lt;i&gt;Procedure Linkage Table&lt;/i&gt; (PLT) at compile time (with dynamic linked binaries, which is the default compilation mode). When this is called, there are two known states: &lt;i&gt;first time&lt;/i&gt; and &lt;i&gt;all others&lt;/i&gt;.
          303 &lt;/p&gt;
          304 
          305 &lt;p&gt;
          306 The &lt;i&gt;first time&lt;/i&gt; a call is made, the process is passed to the &lt;i&gt;loader&lt;/i&gt; in order to resolve the symbol (more on this process later). This is seen in &lt;i&gt;Figure 3&lt;/i&gt; by the &lt;i&gt;prepare resolver&lt;/i&gt; line of code. Once the symbol is resolved, it is added to the &lt;i&gt;Global Offset Table&lt;/i&gt; (GOT) for later usage. 
          307 &lt;/p&gt;
          308 
          309 &lt;p&gt;
          310 The next time that the PLT entry for a function is called, the entry is IN the GOT table, as the resolver has already been set. Because of this, we can skip the resolving process and just use the entry in the GOT table for the symbol. 
          311 &lt;/p&gt;
          312 
          313 &lt;p&gt;
          314 For more information on the PLT and GOT, please refer to the &lt;a href="https://systemoverlord.com/2017/03/19/got-and-plt-for-pwning.html"&gt;article&lt;/a&gt; by System Overlord and &lt;a href="https://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/"&gt;this&lt;/a&gt; article by Eli Bendersky. 
          315 &lt;/p&gt;
          316 
          317 &lt;h3&gt;
          318 Symbol Resolving (ld) 
          319 &lt;/h3&gt;
          320 
          321 &lt;p&gt;
          322 Now, here is the black magic-y part: &lt;i&gt;how does the loader know where symbols are located&lt;/i&gt;? At a high level, the loader iterates through all loaded ELF file symbol tables until it finds an entry to this specific symbol. The full process for how the symbol resolving process is done is out of the scope of the article but a fair amount of it will be discussed below. For an in-depth explanation on this, please look at &lt;a href="https://blogs.oracle.com/solaris/gnu-hash-elf-sections-v2"&gt;GNU Hash ELF Sections&lt;/a&gt;.
          323 &lt;/p&gt;
          324 
          325 &lt;h2&gt;
          326 Game Plan
          327 &lt;/h2&gt;
          328 &lt;p&gt;
          329 Whooo... that was a lot of background information just to understand this technique! Now, with the stage set, we will give a high level overview of the attack technique then and then dive into each aspect of the technique individually. 
          330 &lt;/p&gt;
          331 
          332 &lt;p&gt;
          333 The plan for exploitation is as follows: 
          334 &lt;ol&gt;
          335 &lt;li&gt;
          336 Overwrite mmap chunk &lt;i&gt;size&lt;/i&gt; or &lt;i&gt;prev_size&lt;/i&gt;.
          337 &lt;/li&gt;
          338 &lt;li&gt;Free the mmap chunk (with munmap) to override part of the memory mapping  of LibC (&lt;code&gt;.gnu.hash, .dynsym&lt;/code&gt;)&lt;/li&gt;
          339 &lt;li&gt;Get mmap chunk over the top of LibC region.&lt;/li&gt;
          340 &lt;li&gt;Rewrite &lt;code&gt;.gnu.hash&lt;/code&gt; and &lt;code&gt;.dynsym&lt;/code&gt; sections of LibC ELF.&lt;/li&gt;
          341 &lt;li&gt;Call previously uncalled function for code execution.&lt;/li&gt;
          342 &lt;/ol&gt;
          343 
          344 At a high level, the steps are shown above. The goal is to rewrite the symbol table of LibC in order to redirect the course of execution when a new symbol for a function is being resolved. Let’s now understand each of the steps listed above in detail.
          345 &lt;/p&gt;
          346 
          347 &lt;h2&gt;
          348 Altering Mmap Chunk Size
          349 &lt;/h2&gt;
          350 &lt;h3&gt;
          351 Why?
          352 &lt;/h3&gt;
          353 &lt;p&gt;
          354 The purpose of this step is to change the size of the chunk to &lt;i&gt;overlap&lt;/i&gt; with LibC. Then, when we free this chunk, it will munmap memory associated with LibC. The fruit of altering the size is only apparent after freeing and reallocating in later steps. But, our main goal is to control a normally &lt;i&gt;read-only&lt;/i&gt; section of LibC: &lt;code&gt;.gnu.hash&lt;/code&gt; and &lt;code&gt;.dynsym&lt;/code&gt;.
          355 &lt;/p&gt;
          356 
          357 &lt;h3&gt;
          358 Mmap Chunk Review
          359 &lt;/h3&gt;
          360 &lt;p&gt;
          361 Mmap chunks have two main components that dictate the addresses to be freed: &lt;i&gt;size&lt;/i&gt; and &lt;i&gt;prev_size&lt;/i&gt;. 
          362 &lt;/p&gt;
          363 
          364 &lt;p&gt;
          365 By altering the &lt;i&gt;size&lt;/i&gt; of a chunk, we can control the amount of bytes that are unmapped from the point of the original allocation, or going &lt;i&gt;forward&lt;/i&gt;. Additionally, the &lt;i&gt;prev_size&lt;/i&gt; can be used to munmap chunks going &lt;i&gt;backwards&lt;/i&gt; from the original point of allocation. The prev_size field is used for the &lt;b&gt;current chunk&lt;/b&gt; with mmap chunks, not for the size of the previous chunk. For the purpose of this exploit, only altering the size is going to be useful though. I wanted to make mention of altering the &lt;i&gt;prev_size&lt;/i&gt; because it can be useful in other mmap chunk heap exploits though!
          366 &lt;/p&gt; 
          367 
          368 &lt;h3&gt;
          369 Valid Chunks
          370 &lt;/h3&gt;
          371 
          372 &lt;p&gt;
          373 For an mmap chunk, the following must to be true: 
          374 &lt;ul&gt;
          375 &lt;li&gt;Mmap bit must be set (2nd bit of the size metadata)&lt;/li&gt;
          376 &lt;li&gt;&lt;code&gt;prev_size + size&lt;/code&gt; must to be a page size (0x1000 for example) &lt;/li&gt;
          377 &lt;/ul&gt;
          378 
          379 The source code for both of these checks can be seen in Figure 2 (way above). 
          380 &lt;/p&gt;
          381 
          382 &lt;h3&gt;
          383 Chunk Attack Size
          384 &lt;/h3&gt;
          385 &lt;p&gt;
          386 The size of the chunk is different on a case by case basis. The important part is that the chunk needs to overlap with the &lt;code&gt;.gnu.hash&lt;/code&gt; and &lt;code&gt;.dynsym&lt;/code&gt; of LibC in order to rewrite the symbol table entry later on. To see the sizes of these sections, the tool &lt;code&gt;readelf&lt;/code&gt; is extremely useful. 
          387 &lt;/p&gt;
          388 
          389 &lt;p&gt;
          390 In general, the size to overwrite with can be calculated with the following forumla: &lt;code&gt;size_of_chunk = bytes_to_libc + bytes_to_overlap__dynsym&lt;/code&gt;. Then, in the next step, when the chunk is freed, LibC (or a different library) will be gone from the virtual address mapping. 
          391 &lt;/p&gt;
          392 
          393 &lt;h2&gt;
          394 Free the Chunk
          395 &lt;/h2&gt;
          396 &lt;p&gt;
          397 From the previous step, we have created an mmap chunk that has a size overlapping part of LibC. All of the hard work for this was done! All we have to do is to call &lt;i&gt;free&lt;/i&gt; on this corrupted chunk. Now, part of LibC will be unmapped from the virtual address space. 
          398 &lt;/p&gt;
          399 
          400 &lt;h2&gt;
          401 Overlap Chunk with LibC
          402 &lt;/h2&gt;
          403 
          404 &lt;p&gt;
          405 &lt;div style="width:97%; font-size:80%; text-align:center; float : left; border: 1px solid black; border-radius: 10px; margin: 10px;"&gt;&lt;img src="https://live.staticflickr.com/65535/50317704177_395cc78219_w.jpg" width="97%"; alt=""&gt;&lt;center&gt;Figure 4 - Overlap Mmap Chunk on LibC &lt;/center&gt;&lt;/div&gt;
          406 
          407 From the previous step, we have removed a significant portion of LibC from the virtual address space. The goal of this step is to &lt;b&gt;gain control&lt;/b&gt; of this section of LibC (as seen in Figure 4). 
          408 &lt;/p&gt;
          409 
          410 Although the allocation appears to be simple, it is more complicated than one would think. There are two main pain points with this:
          411 &lt;ul&gt;
          412 &lt;li&gt;mmap_threshold&lt;/li&gt;
          413 &lt;li&gt;Heap Locations&lt;/li&gt;
          414 &lt;/ul&gt;
          415 
          416 &lt;/p&gt;
          417 
          418 &lt;h3&gt;
          419 mmap_threshold
          420 &lt;/h3&gt;
          421 &lt;p&gt;
          422 Very large chunks (&lt;i&gt;mmap chunks&lt;/i&gt;) are assigned in a completely different way in order to prevent fragmentation with &lt;i&gt;one-off&lt;/i&gt; extremely large chunks. The &lt;i&gt;mmap_threshold&lt;/i&gt; is used in order to determine the largest chunk size that should go onto the standard section of the heap. In order to allocate an mmap chunk, the size has to be larger than the &lt;i&gt;mmap_threshold&lt;/i&gt;. 
          423 &lt;/p&gt;
          424 
          425 &lt;p&gt;
          426 When an mmap chunk is freed, the size of the chunk is checked with the &lt;u&gt;previously largest freed&lt;/u&gt; mmap chunk (or the default size), which is known as the &lt;i&gt;mmap_theshold&lt;/i&gt;. If the size being freed is larger, then the mmap_threshold is updated. For example, mmap_theshold is 0x100000. If we free a chunk of size 0x200000 then the mmap_theshold gets updated to 0x200000.
          427 &lt;/p&gt;
          428 
          429 &lt;p&gt;
          430 If the size of the chunk being allocated is NOT larger than the mmap_threshold value, then the chunk will be put into the normal heap section instead of getting a special mmap chunk. 
          431 &lt;/p&gt;
          432 &lt;h3&gt;
          433 Heap Locations
          434 &lt;/h3&gt;
          435 &lt;p&gt;
          436 The heap locations is just about if the physical spot in memory is actually available or not. This can be fixed with proper &lt;i&gt;heap feng shui&lt;/i&gt;. Heap Feng Shui is the process of arranging the heap memory in the exact way that an attacker needs. 
          437 &lt;/p&gt;
          438 
          439 &lt;p&gt;
          440 Getting the mmap chunks directly behind LibC just requires some knowledge of how these chunks are allocated. From empirical observations of my own and Tukan, here is what the common ordering from (at least, on my 16.04 Ubuntu instance): 
          441 
          442 &lt;ul&gt;
          443 &lt;li&gt;Memory above LibC and below the loader&lt;/li&gt;
          444 &lt;li&gt;Below the mmap_base (practically, just below LibC). Allocations are made consecutively below each other.&lt;/li&gt;
          445 &lt;/ul&gt;
          446 &lt;/p&gt;
          447 
          448 &lt;p&gt;
          449 Now that the chunk has been allocated into the proper location (over LibC) we can move on to the next step. A visual diagram of the &lt;i&gt;before&lt;/i&gt; and &lt;i&gt;after&lt;/i&gt; can be seen above in Figure 4. 
          450 &lt;/p&gt;
          451 
          452 &lt;p&gt;
          453 NOTE: Mmap initializes all memory to be NULL. So, all of the values from the original mapping of LibC (that we munmapped) are gone. 
          454 &lt;/p&gt;
          455 
          456 &lt;h2&gt;
          457 Rewriting LibC .gnu.hash and .dynsym
          458 &lt;/h2&gt;
          459 &lt;p&gt;
          460 Recall, from the previous step, we control a chunk that overlaps with what used to be the beginning of LibC. 
          461 &lt;/p&gt;
          462 
          463 &lt;p&gt;
          464 Now begins the real fun :) Rewriting the symbol resolution process! In order to rewrite the parts of LibC, there are multiple ways to go about it: 
          465 &lt;ol&gt;
          466 &lt;li&gt;Copy in the LibC sections byte for byte. Then, make several small changes to the symbol table. This is the technique that Qualys chose to use.&lt;/li&gt;
          467 &lt;li&gt;Completely reverse the process and deterministically figure out what to write. &lt;/li&gt;
          468 &lt;li&gt;Step through the code in GDB to understand the loader and write only what is needed.&lt;/li&gt;
          469 &lt;/ol&gt;
          470 
          471 Option 1 is likely easiest but would not help me understand the resolving process as a whole. Upon my preliminary research of option 2, it seemed to be too complex for my purposes. The symbol resolution process uses complicated hashing, bloom filters and other crazy things. So, rewriting this section with a completely deterministic understanding sounded like too much effort for this project, but doable (could be a future research project though). For more information on this, please visit &lt;a href="https://blogs.oracle.com/solaris/gnu-hash-elf-sections-v2"&gt;here&lt;/a&gt;. 
          472 
          473 &lt;p&gt;
          474 After ruling out the copy-paste method of 1 and the hard reversing of 2, I decided to go with option 3. Although option 1 would have worked, option 3 looked new and interesting to learn about!
          475 &lt;/p&gt;
          476 
          477 &lt;h3&gt;
          478 What Is Actually Needed? 
          479 &lt;/h3&gt;
          480 &lt;p&gt;
          481 First, let's setup a nice debugging ENV. Viewing assembly by itself is very complex and tedious to look at. So, for the purpose of this, having the LibC source code attached is really nice. This can be done by downloading the source code of the version of LibC you are trying to debug and running the following command in GDB: &lt;code&gt;gdb&gt; dir /libc/source/location&lt;/code&gt;. This is to set GDB to look for source code at the location that is set.  
          482 &lt;/p&gt;
          483 &lt;p&gt;
          484 After stepping through a program with the source code hooked up, I realized that there were 4 main locations that needed to be set (from empirical testing):
          485 &lt;ul&gt;
          486 &lt;li&gt;l_gnu_bitmask&lt;/li&gt;
          487 &lt;li&gt;l_gnu_buckets&lt;/li&gt;
          488 &lt;li&gt;l_gnu_chain_zero&lt;/li&gt;
          489 &lt;li&gt;Symbol Table Entry&lt;/li&gt;
          490 &lt;/ul&gt;
          491 
          492 The first three entries have to do with &lt;b&gt;locating&lt;/b&gt; the actual spot where the symbol table is located. The last field we are overwriting is symbol table entry itself. 
          493 &lt;/p&gt;
          494 
          495 &lt;h3&gt;
          496 Symbol Table Entry Locating
          497 &lt;/h3&gt;
          498 &lt;p&gt;
          499 After setting up a version of LibC with debugging symbols and source code attached, the reversing was ready to go. To do the actual debugging, I had two windows open: the modified version (corrupted) and one with the regular flow (non-corrupted). The corrupted version will only have NULLs in this section to start with because mmap initializes all memory to NULL. Figure 5 shows this setup: 
          500 &lt;div style="width:97%; font-size:80%; text-align:center; border: 1px solid black; border-radius: 10px; margin: 10px;"&gt;&lt;img src="https://live.staticflickr.com/65535/50317109232_ae6a87cdd4_c.jpg" width="97%"; alt=""&gt;&lt;center&gt;Figure 5 - Two Screen Difference &lt;/center&gt;&lt;/div&gt;
          501 &lt;/p&gt;
          502 
          503 &lt;p&gt;
          504 After reversing the symbol table resolving process for a while, it became apparent that the function doing the actual symbol resolving (that handled parts of LibC that we corrupted) was the function &lt;code&gt;do_lookup_x&lt;/code&gt;. This is called from the trampoline function  &lt;code&gt;_dl_runtime_resolve&lt;/code&gt;, which is the first thing called from the PLT stubs. 
          505 &lt;/p&gt;
          506 
          507 &lt;p&gt;
          508 The function &lt;code&gt;do_lookup_x&lt;/code&gt; 
          509 iterates all ELF files until it finds the one with the proper symbol. Step through &lt;a href="https://code.woboq.org/userspace/glibc/elf/dl-lookup.c.html#332"&gt;do_lookup_x&lt;/a&gt; until &lt;i&gt;LibC&lt;/i&gt; comes up as the ELF entry to look for the symbol to resolve. Once there, I did the following steps (on repeat), until the symbol resolution process worked again:
          510 &lt;ol&gt;
          511 &lt;li&gt;Found a LibC value that is corrupted (this is going to be NULL instead of proper value). This is shown in the right terminal in &lt;i&gt;Figure 5&lt;/i&gt;.&lt;/li&gt;
          512 &lt;li&gt;Found &lt;i&gt;proper&lt;/i&gt; value in non-corrupted version of the binary with a regular symbol resolution process. This is shown in the left terminal in &lt;i&gt;Figure 5&lt;/i&gt;.&lt;/li&gt;
          513 &lt;li&gt;Wrote proper value to the same exact location in LibC (corrupted version) via the overlapping mmap chunk that we allocated in step 3. Now, this step in the symbol resolution process will start working again.&lt;/li&gt;
          514 &lt;li&gt;Repeat steps 1-3 until the entire symbol resolution process is working, as expected. 
          515 &lt;/ol&gt;
          516 
          517 After repeating this step a handful of times, the proper values will be set to finally resolve the symbol we want!
          518 &lt;/p&gt;
          519 
          520 &lt;h3&gt;
          521 Symbol Tables
          522 &lt;/h3&gt;
          523 &lt;p&gt;
          524 Once the entry has been located, faking the symbol table entry is very simple. &lt;a href="https://code.woboq.org/userspace/glibc/elf/elf.h.html#529"&gt;Symbol table entries&lt;/a&gt; are made up of the following format: 
          525 &lt;pre&gt;
          526 typedef struct {
          527         Elf64_Word      st_name;
          528         unsigned char   st_info;
          529         unsigned char   st_other;
          530         Elf64_Half      st_shndx;
          531         Elf64_Addr      st_value;
          532         Elf64_Xword     st_size;
          533 } Elf64_Sym;
          534 &lt;/pre&gt;
          535 
          536 It is recommended that the &lt;i&gt;entire&lt;/i&gt; symbol table entry is just copied into memory so that the rest of the lookup process looks as expected. There is ONE extremely important field to point out though: &lt;b&gt;st_value&lt;/b&gt;. 
          537 &lt;/p&gt;
          538 
          539 &lt;p&gt;
          540 Assuming this is a relative offset entry (which can be altered with the type field), edit the &lt;i&gt;st_value&lt;/i&gt; to be the offset of whatever function you would like to call! For a situation where a function is being resolved, we can set this to point to ANY function, including &lt;b&gt;system&lt;/b&gt; or a one_gadget. 
          541 &lt;/p&gt;
          542 
          543 &lt;h2&gt;
          544 Function Call
          545 &lt;/h2&gt;
          546 &lt;p&gt;
          547 What can we call? We can call ANY function (or in the middle of a function) that is within a close proximity of the symbol we overwrote. Practically, anything within the same relative address space could be called, even functions/symbols from other libraries loaded close by (although, I have not tested this myself, this should work). All we need to know is a relative offset from LibC (or the library we are overwriting). 
          548 &lt;/p&gt;
          549 
          550 &lt;p&gt;
          551 The function that is going to be called must be a symbol table overwritten within a library. Additionally, this function must &lt;u&gt;not have been called before&lt;/u&gt;. This is because the symbol resolving process is what we are overriding, which only happens the first time a symbol in a dynamically linked library is resolved (recall this from the PLT/GOT section in the background). 
          552 &lt;/p&gt;
          553 
          554 &lt;p&gt;
          555 This can be used to call &lt;i&gt;system&lt;/i&gt;, a one_gadget, another  function or be the start of a ROP chain. At this point, this is where all of the hard work passes off! :)
          556 &lt;/p&gt;
          557 
          558 &lt;h2&gt;
          559 Thoughts 
          560 &lt;/h2&gt;
          561 &lt;p&gt;
          562 Overall, this technique is pretty devastating but is extremely technical and tedious. Below are the pros and cons of this technique. 
          563 &lt;/p&gt;
          564 &lt;h3&gt;
          565 Pros
          566 &lt;/h3&gt;
          567 &lt;p&gt;
          568 Very large chunks (mmap) are typically not discussed much with heap exploitation techniques. &lt;i&gt;House of Muney&lt;/i&gt; is an opening into this realm. 
          569 &lt;/p&gt; 
          570 
          571 &lt;p&gt;
          572 Here are some pros to the technique: 
          573 &lt;ul&gt;
          574 &lt;li&gt;Bypasses &lt;u&gt;address space layout randomization&lt;/u&gt; (ASLR) because symbol tables can have relative offsets.&lt;/li&gt;
          575 &lt;li&gt;Requires NO leaks.&lt;/li&gt;
          576 &lt;li&gt;A single buffer overflow can be enough to start this exploitation method.&lt;/li&gt;
          577 &lt;li&gt;Mmap chunk heap exploitation technique, which is not discussed very much. &lt;i&gt;House of Muney&lt;/i&gt; is an opening into this realm.  &lt;/li&gt;
          578 &lt;/ul&gt;
          579 &lt;/p&gt;
          580 
          581 &lt;h3&gt;
          582 Cons
          583 &lt;/h3&gt;
          584 &lt;p&gt;
          585 
          586 &lt;ul&gt;
          587 &lt;li&gt;This vulnerability does require the ability to overwrite the size of a mmap chunk. &lt;/li&gt;
          588 &lt;li&gt;Known &lt;b&gt;relative&lt;/b&gt; location of the overwritten chunk. In some scenarios, this may need to be brute forced.&lt;/li&gt;
          589 &lt;li&gt;Full RELRO or static compilation would prevent this attack from being successful because all symbols are loaded prior to the program running (no lazy symbol resolution).&lt;/li&gt;
          590 &lt;li&gt;The LibC (or other library) version being attacked must be known or brute forced in order to have the offsets work properly.&lt;/li&gt;
          591 &lt;li&gt;Fairly good control over the size of allocations in order to get mmap chunks in the proper locations&lt;/li&gt;
          592 &lt;/ul&gt;
          593 
          594 Being able to overwrite the size of an &lt;i&gt;mmap&lt;/i&gt; chunk is a little odd. Two of the main vulnerabilities with heap exploitation, use after free and double free, are not nearly as viable (but still possible) because mmap chunks are &lt;i&gt;not&lt;/i&gt; put into bins. Because of this, either a bad indexing method or (more likely) a buffer overflow vulnerability needs to be found. 
          595 &lt;/p&gt;
          596 
          597 &lt;h3&gt;
          598 POC
          599 &lt;/h3&gt;
          600 &lt;p&gt;
          601 Want to see an actual POC? As part of documenting this technique, the Github repo &lt;a href="https://github.com/mdulin2/munmap-and-rewrite"&gt;House of Muney&lt;/a&gt; has everything needed in order to understand this technique. In particular, it has a well-commented proof of concept, a pre-made pwntools script to load the file with the non-optmized LibC version with debugging symbols and a nice compilation script. If you really want to understand the technique, it is recommended that you play with this POC.  It should be noted that one of the values (to be written) is skipped because it is not completely necessary to write, but should be accounted for when indexing. 
          602 &lt;/p&gt;
          603 
          604 &lt;h2&gt;
          605 Conclusion
          606 &lt;/h2&gt;
          607 
          608 &lt;p&gt;
          609 Overall, this is an incredible technique for gaining code execution, although highly technical and complicated. In the future, I would love to see more techniques about exploiting LibC with mmap chunks and gaining code execution in different/interesting ways. I hope you enjoyed the article and learned something interesting about heap exploitation and computers today.
          610 &lt;/p&gt;
          611 
          612 &lt;p&gt;
          613 Major S/O's to the &lt;a href="https://dayzerosec.com/"&gt;Day[0]&lt;/a&gt; podcast for putting the Qmail exploit on my radar, Tukan for his work on malloc mmap chunks, Georgi Guninski for his QMail finding 15+ years ago, both Dinesh Shetty and iamalsaher for the reviews and Qualys for posting this technique in their exploit. Feel free to reach out to me (contact information is in the footer) if you have any questions or comments about this article. Cheers from &lt;b&gt;Maxwell "ꓘ" Dulin&lt;/b&gt;. 
          614 &lt;/p&gt;
          615 </description><guid isPermaLink="false">https://maxwelldulin.com/BlogPost?post=6967456768</guid><pubDate>Thu, 08 Oct 2020 00:00:00 +0000</pubDate></item><item><title>House of Mind - Fastbin Variant in 2021</title><link>https://maxwelldulin.com/BlogPost?post=2257705984</link><description>&lt;h2&gt;
          616 Introduction
          617 &lt;/h2&gt;
          618 
          619 &lt;p&gt;
          620 Have you ever discovered something amazing only to later realize that somebody else had already beaten you to it? In this article, I wanted to describe a new (rediscovered) GLibC heap exploitation method that works on all versions of the allocator. With this method, an attacker can write a heap value to an arbitrary location (WRITE-WHERE primitive). 
          621 &lt;/p&gt;
          622 
          623 &lt;p&gt;
          624 When I started looking for new ways to exploit the allocator via the &lt;i&gt;non-main arena&lt;/i&gt; chunks, I thought I had found a new technique! However, part way through writing this article, I reread the original post (&lt;a href="https://dl.packetstormsecurity.net/papers/attack/MallocMaleficarum.txt"&gt;Malloc Malefaricum&lt;/a&gt;) on the House of Mind
          625 only to realize that there is a  &lt;i&gt;fastbin&lt;/i&gt; variant of the attack as well. The original use case for the fastbin variant of the House of Mind writes a heap pointer to a GOT address to jump to shellcode. But, this technique to trivially pop a shell is no longer viable because of NX. With the original House of Mind being patched and the fastbin variant no longer being an auto shell, this technique was mostly forgotten about, waiting to be rediscovered for a new purpose. So, new or not, nobody seems to be talking about this technique. In this article I wanted to shed  light onto the House of Mind's Fastbin Variant as a useful WRITE-WHERE primitive and discuss when it can be used. 
          626 &lt;/p&gt;
          627 
          628 &lt;p&gt;
          629 This post will (hopefully)  have a POC in &lt;a href="https://github.com/shellphish/how2heap/pull/136"&gt;how2heap&lt;/a&gt;; the link is currently to a pull request with all of the code. For more security related content, check out this blog for other things, such as the &lt;a href="https://maxwelldulin.com/BlogPost?post=6967456768"&gt;House of Muney&lt;/a&gt; heap exploitation technique. 
          630 &lt;/p&gt;
          631 
          632 &lt;p&gt;
          633 Before we get to the meat of the technique, we will go over how the heap allocator works. I cannot stress enough how important understanding the allocator is for heap exploitation. Trying to pwn the heap without understanding the inner workings of the allocator is like trying to shot a fish in a lake. 
          634 &lt;/p&gt;
          635 
          636 &lt;h2&gt;
          637 Chunks
          638 &lt;/h2&gt;
          639 
          640 &lt;p&gt;
          641 Chunks are the main object that users interact with. There are two main states to a chunk: &lt;i&gt;allocated&lt;/i&gt; and &lt;i&gt;free&lt;/i&gt;.  The following picture demonstrates a &lt;i&gt;free&lt;/i&gt; chunk: 
          642 &lt;div style="width: 98%; font-size:80%; text-align:center; float : left; border: 1px solid black; border-radius: 10px; margin: 10px;"&gt;&lt;img src="https://docs.google.com/drawings/d/1YrlnGa081NpO0D3wcoaJbGvhnPi3X6bBKMc3bN4-oZQ/pub?w=940&amp;h=669" width="95%" alt=""&gt;&lt;center&gt;Figure 1 - Free Chunk by Sploitfun&lt;/center&gt;&lt;/div&gt;
          643 
          644 
          645 The first field is the size of the previous chunk (prev_size). This is only used if the previous chunk is free. The second field is the &lt;b&gt;chunk size&lt;/b&gt;. The chunk size represents the size of the data of the chunk and the metadata about the chunk. The metadata of the chunk includes three fields: prev_inuse (if the previous chunk is in use), mmap (is the previous chunk mmapped) and if the chunk is in a non-main arena. We will touch on the &lt;i&gt;non-main arena&lt;/i&gt; bit more in depth later.
          646 &lt;/p&gt;
          647 
          648 &lt;p&gt;
          649 On an allocated (non-free) chunk, the third and fourth field are used as data sections. However, on a free chunk, the third field is used in order to store a pointer to other freed chunks. This field is known as the forward pointer or the &lt;i&gt;Fd&lt;/i&gt; field. The fourth field is exactly the same, except that it stores a backwards pointer or &lt;i&gt;bk&lt;/i&gt;. &lt;!-break--&gt; 
          650 &lt;/p&gt;
          651 
          652 &lt;h2&gt;
          653 Bins
          654 &lt;/h2&gt;
          655 
          656 &lt;p&gt;When using Malloc, chunks that are freed are put into a local storage to be reused. The storage locations for the free chunks are called &lt;i&gt;bins&lt;/i&gt;.
          657 &lt;/p&gt;
          658 
          659 &lt;p&gt;
          660 There are a multiple kinds of bins for different sizes and situations. All bins use a &lt;a href="https://www.geeksforgeeks.org/data-structures/linked-list/"&gt;linked list&lt;/a&gt; data structure in order to keep track of the free chunks in the bin. For the purposes of this technique, only a single bin needs to be understood: &lt;i&gt;fastbins&lt;/i&gt;.
          661 &lt;/p&gt;
          662 
          663 &lt;h3&gt;
          664 Fastbin
          665 &lt;/h3&gt;
          666 
          667 &lt;p&gt;
          668 Prior to version 2.26 (current at 2.33), the fastbin was the first location where chunks were put into, if the size matched up. Fastbin chunks are very small chunks with the idea that small chunk sizes are going to be used frequently. On 64-bit systems (assumed for the rest of the article) the bins range from chunk sizes of 0x20-0x80 bytes in 0x10 byte intervals. 
          669 &lt;/p&gt;
          670 
          671 &lt;p&gt;
          672 Fastbins use a &lt;i&gt;singly linked list&lt;/i&gt;, while several of the other bins use doubly linked lists. This means that free chunks only have a single pointer to the chunk in front of it ('fd' field in figure 1). Because of this, validation of fastbin pointers is difficult to do.
          673 &lt;/p&gt;
          674 
          675 &lt;p&gt;
          676 Only fastbins are necessary for understanding how this technique works. However, this article only scratches the surface of how the allocator works, in particular, bins and chunks. If you want to learn more about the allocator, &lt;a href="https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/"&gt;Azeria Labs&lt;/a&gt; and &lt;a href="https://sploitfun.wordpress.com/2015/02/10/understanding-glibc-malloc/"&gt;Sploitfun&lt;/a&gt; have awesome articles on this. 
          677 &lt;/p&gt;
          678 
          679 &lt;h2&gt;Arenas&lt;/h2&gt;
          680 
          681 &lt;p&gt;
          682 Arenas are a &lt;code&gt;struct&lt;/code&gt; that is shared between threads which contains references to heaps, as well as the bins (where the free chunks are stored at) and other state information about a heap. Threads assigned to each arena will allocate memory from that arena's free lists. In layman's terms, the arena is the metadata information that makes the allocator work. All of this state information is stored in the &lt;code&gt;malloc_state&lt;/code&gt; struct. 
          683 &lt;/p&gt;
          684 
          685 &lt;p&gt;
          686 A single threaded process has a single arena called the &lt;i&gt;main arena&lt;/i&gt;. When threads become involved, multiple arenas are used in order to allow for concurrent heap data access, as heap data is specific to a process. These other arenas are called &lt;i&gt;non-main&lt;/i&gt; arenas. So, this begs the question: &lt;i&gt;"How does the allocator know which arena a chunk belongs to when being freed?"&lt;/i&gt; Excellent question! 
          687 &lt;/p&gt;
          688 
          689 &lt;h3&gt;
          690 Non-Main Arena Bit
          691 &lt;/h3&gt;
          692 
          693 &lt;p&gt;
          694 First, we need to learn about the third bit of the &lt;i&gt;size&lt;/i&gt; field (labeled as the 'N' bit in figure 1 above). This is used in order to specify if this chunk belongs in a &lt;i&gt;non-main arena&lt;/i&gt; or not. If this bit is set, then the chunk belongs to a &lt;i&gt;non-main arena&lt;/i&gt; and if the bit is NOT set, the chunk belongs to the &lt;i&gt;main arena&lt;/i&gt;. This bit is set at allocation time, prior to the chunk being passed back to the user.
          695 &lt;/p&gt;
          696 
          697 &lt;h3&gt;
          698 Finding the Arena
          699 &lt;/h3&gt;
          700 
          701 &lt;p&gt;
          702 &lt;div style="width: 500px; font-size:80%; text-align:center; padding: 10px; float: right; border-radius: 10px; margin: 20px;"&gt;&lt;img src="https://live.staticflickr.com/65535/51014104368_3865d361f3_o.png" width="350px" alt=""&gt;&lt;center&gt;Figure 2 - Get non-main arena from chunk &lt;/center&gt;&lt;/div&gt;
          703 The &lt;a href="https://elixir.bootlin.com/glibc/glibc-2.23/source/malloc/arena.c#L127"&gt;code&lt;/a&gt; below finds the arena to be used in GLibC: 
          704 &lt;pre&gt;
          705 #define arena_for_chunk(ptr) \
          706   chunk_non_main_arena (ptr) ? \
          707     heap_for_ptr (ptr)-&gt;ar_ptr : \
          708     &amp;main_arena 
          709 &lt;/pre&gt;
          710 &lt;/p&gt;
          711 
          712 &lt;p&gt;
          713 The else (second part of the conditional from the &lt;a href="https://www.freecodecamp.org/news/c-ternary-operator/"&gt;ternary operator&lt;/a&gt; at line #4 above) is easier to understand, so we will start there. If the chunk is in the &lt;i&gt;main arena&lt;/i&gt; (or, not a non-main arena chunk) then return a pointer to the &lt;a href="https://elixir.bootlin.com/glibc/glibc-2.23/source/malloc/malloc.c#L1761"&gt;main arena&lt;/a&gt;  global variable. This is all that is done to find the main arena. 
          714 &lt;/p&gt;
          715 
          716 &lt;p&gt;
          717 The first part of the conditional  (line #3 above) is for a &lt;i&gt;non-main arena&lt;/i&gt; chunk, which is specified by the &lt;i&gt;non-main arena&lt;/i&gt; bit flag on the size discussed earlier. If this is the case, it calls another macro called &lt;a href="https://elixir.bootlin.com/glibc/glibc-2.23/source/malloc/arena.c#L125"&gt;heap_for_ptr&lt;/a&gt;, which is where most of the magic happens at. This macro is shown below: 
          718 &lt;pre&gt;
          719 #define heap_for_ptr(ptr)    \
          720   ((heap_info *)             \
          721     ((unsigned long) (ptr) &amp; \
          722     ~(HEAP_MAX_SIZE - 1)))   \
          723 &lt;/pre&gt;
          724 &lt;/p&gt;
          725 
          726 &lt;p&gt;
          727 The &lt;code&gt;heap_for_ptr&lt;/code&gt; macro takes the chunk being freed and removes a large portion of the least significant bits. This is done by ANDing the value with a large quantity of 0s. But why? Here's the punchline! The bottom of a &lt;i&gt;non-main arena&lt;/i&gt; heap has a &lt;u&gt;pointer to our arena&lt;/u&gt;! To be precise, this is the &lt;a href="https://elixir.bootlin.com/glibc/glibc-2.23/source/malloc/arena.c#L48"&gt;heap_info&lt;/a&gt; struct; the first field (&lt;code&gt;ar_ptr&lt;/code&gt;) has the pointer to the arena. Notice the  &lt;code&gt;(ptr)-&gt;ar_ptr&lt;/code&gt; code being used in the &lt;code&gt;arena_for_chunk&lt;/code&gt; macro above to get the arena from the &lt;code&gt;heap_info&lt;/code&gt; struct. 
          728 &lt;/p&gt;
          729 
          730 &lt;p&gt;
          731 This is quite clever! The user will always have a pointer to the malloc chunk (the chunk is being freed). So, by storing the arena at the bottom of the heap itself, we can just remove the least significant bits of the chunk to find the arena! If this does not make sense, I completely understand. Figure 2 has a visual representation of this that should help.
          732 &lt;/p&gt;
          733 
          734 &lt;p&gt;
          735 To wrap this up, here are the important notes:
          736 &lt;ul&gt;
          737 &lt;li&gt;The &lt;code&gt;arena_for_chunk&lt;/code&gt; macro gets the arena by using the chunk itself.&lt;/li&gt;
          738 &lt;li&gt; The &lt;i&gt;non-main arena&lt;/i&gt; bit specifies which functionality to use for getting an arena. &lt;/li&gt;
          739 &lt;li&gt;The &lt;i&gt;main arena&lt;/i&gt; is stored in a global variable and the &lt;i&gt;non-main arena&lt;/i&gt; does some clever math on the chunk in order to get the arena.&lt;/li&gt;
          740 &lt;/ul&gt;  
          741 
          742 For more information on GLibC arenas, sploitfun covers it extensively &lt;a href="https://sploitfun.wordpress.com/2015/02/10/understanding-glibc-malloc/"&gt;here&lt;/a&gt; and the Malloc Maleficarum paper covers it quite well too.
          743 &lt;/p&gt;
          744 
          745 &lt;h2&gt;
          746 Flow of the Attack
          747 &lt;/h2&gt;
          748 &lt;p&gt;
          749 The attack writes the pointer of a chunk being freed to a nearly arbitrary location; this is  known as a WRITE-WHERE primitive. In the land of GLibC Heap exploitation, the &lt;a href="https://ctf-wiki.github.io/ctf-wiki-en/pwn/linux/glibc-heap/unsorted_bin_attack/"&gt;Unsorted Bin Attack&lt;/a&gt; and the &lt;a href="https://ctf-wiki.org/pwn/linux/glibc-heap/large_bin_attack/"&gt;Large Bin Attack&lt;/a&gt; are good reference points for similar WRITE-WHERE primitives.
          750 &lt;/p&gt;
          751 
          752 &lt;p&gt;
          753 For the attack itself, it can be broken up into several stages: 
          754 
          755 &lt;ul&gt;
          756 &lt;li&gt;Heap Feng Shui (aligning controllable data with &lt;code&gt;heap_info&lt;/code&gt; struct)&lt;/li&gt;
          757 &lt;li&gt;Creating a fake &lt;code&gt;heap_info&lt;/code&gt; and  arena&lt;/li&gt;
          758 &lt;li&gt;Corrupting a fastbin sized chunk&lt;/li&gt;
          759 &lt;li&gt;Trigger the write via freeing the altered chunk&lt;/li&gt;
          760 &lt;/ul&gt;
          761 
          762 The steps for this attack will be broken down in the sections below.
          763 &lt;/p&gt;
          764 
          765 &lt;h2&gt;
          766 Heap Feng Shui 
          767 &lt;/h2&gt;
          768 &lt;p&gt;
          769 As in the original House of Mind, our main goal is to create a fake arena to be abused. In order to get the arena, we first need to create a fake &lt;code&gt;heap_info&lt;/code&gt; struct. Where is this located at?
          770 &lt;/p&gt;
          771 
          772 &lt;p&gt;
          773 From looking at the macro &lt;code&gt;heap_for_ptr&lt;/code&gt; (shown above) the pointer is found by removing a large portion of the least significant bits of the chunk. For instance, a heap pointer like 0x555558a4340 would be transformed into 0x55555000000 to find the &lt;code&gt;heap_info&lt;/code&gt; struct. An example of this can be seen in Figure 2 above. So, to create a fake &lt;code&gt;heap_info&lt;/code&gt; struct and set the pointer for the arena properly, we will need to setup the pointer at the EXACT right spot in memory. How is this done? 
          774 &lt;/p&gt;
          775 
          776 &lt;h3&gt;
          777 Alignment of Allocations
          778 &lt;/h3&gt;
          779 &lt;p&gt;
          780 By allocating a large amount of chunks from the heap (ensure the size of each chunk smaller than the &lt;a href="https://elixir.bootlin.com/glibc/glibc-2.23/source/malloc/malloc.c#L1731"&gt;mmap_threshold&lt;/a&gt;), we can  control a section in memory that can be used for a fake &lt;code&gt;heap_info&lt;/code&gt; struct! 
          781 All we have to do is manipulate the heap so that the
          782 attacker controls the area of memory that the corrupted chunk is aligned down to at intervals of &lt;a href="https://elixir.bootlin.com/glibc/glibc-2.23/source/malloc/arena.c#L27"&gt;HEAP_MAX_SIZE&lt;/a&gt;  when calling &lt;code&gt;arena_for_chunk&lt;/code&gt;; this can be seen in figure 3. &lt;div style="width: 500px; text-align:center; float: left; border: 1px solid black; padding: 10px; border-radius: 10px; margin: 20px; font-size:80%"&gt;&lt;img src="https://live.staticflickr.com/65535/51014895122_ebf1acc008_o.png" width="300px" alt=""&gt;&lt;center&gt;Figure 3 - Fake Heap Info Alignment&lt;/center&gt;&lt;/div&gt;
          783 &lt;/p&gt;
          784 
          785 &lt;p&gt;
          786 The &lt;code&gt;HEAP_MAX_SIZE&lt;/code&gt; value varies depending on many settings. From empirical testing on a Ubuntu 16.04 64-bit machine, the size is 4MB. Because the &lt;i&gt;main_arena&lt;/i&gt; is not aligned to values of &lt;code&gt;HEAP_MAX_SIZE&lt;/code&gt;, this will require an average of '0x2000000' bytes of memory being allocated but no more than '0x4000000' bytes. In practice, this alignment is necessary because chunks at lower areas of the heap align down to an area of memory that is neither attack controlled nor mapped at all. 
          787 &lt;/p&gt;
          788 
          789 &lt;p&gt;
          790 Once we have a chunk at the proper location lined up, we need to setup two fake structures for this to work. The alignment is just the first piece in the puzzle. 
          791 &lt;/p&gt;
          792 
          793 &lt;h2&gt;
          794 Setting Up Fake Heap_info
          795 &lt;/h2&gt;
          796 
          797 &lt;p&gt;
          798 &lt;pre&gt;
          799 typedef struct _heap_info
          800 {
          801   malloc_state ar_ptr; // Arena
          802 ...
          803 }
          804 &lt;/pre&gt;
          805 
          806 Once we have control of the  aligned memory necessary for a &lt;code&gt;heap_info&lt;/code&gt; struct, we need to &lt;i&gt;prepare&lt;/i&gt; a fake one. Luckily for us, only a single field needs to be faked: &lt;code&gt;ar_ptr&lt;/code&gt;. This field, which is the first entry of the &lt;a href="https://elixir.bootlin.com/glibc/glibc-2.23/source/malloc/arena.c#L48"&gt;heap_info&lt;/a&gt;  struct, is the arena pointer. So, at a &lt;code&gt;MAX_HEAP_SIZE&lt;/code&gt; aligned value, we need to specify the location (pointer) of the arena, which seems easy enough. Where do we put this at for maximum damage though? This is where things start to come together!
          807 &lt;/p&gt;
          808 
          809 &lt;h2&gt;
          810 Fake Arena
          811 &lt;/h2&gt;
          812 
          813 &lt;h3&gt;
          814 Fake Arena Location
          815 &lt;/h3&gt;
          816 
          817 &lt;p&gt;
          818 From here, we will work backwards from the WRITE to the  get to the proper location of the fake arena. The WRITE takes place &lt;a href="https://elixir.bootlin.com/glibc/glibc-2.23/source/malloc/malloc.c#L3948"&gt;here&lt;/a&gt; when writing a fastbin pointer into the arenas free list. If we want to overwrite somewhere with our heap chunk, we have to consider two items: arena location and the fastbin size.  
          819 &lt;/p&gt;
          820 
          821 &lt;p&gt;
          822 Because the fake arena is controlled directly by us and can be set to an arbitrary location; this is the most important value to consider. Recall, this is set in the fake &lt;code&gt;heap_info-&gt;ar_ptr&lt;/code&gt; struct discussed above. If we want to overwrite a specific location in memory with our heap chunk, we must put the arena close to the target memory address.
          823 &lt;/p&gt;
          824 
          825 &lt;h3&gt;
          826 Arena Writing Offset
          827 &lt;/h3&gt;
          828 &lt;p&gt;
          829 &lt;pre&gt;
          830 struct malloc_state
          831 {
          832   mutex_t mutex;
          833   int flags; // Formly max_fast
          834 
          835   mfastbinptr fastbinsY[NFASTBINS]; // Fastbins
          836 ...
          837 }
          838 &lt;/pre&gt;
          839 Besides the location of the arena, the writing of the chunk to a fastbin adds an &lt;i&gt;offset&lt;/i&gt; to the WRITE. The &lt;code&gt;fastbinsY&lt;/code&gt; array (shown above in the &lt;code&gt;malloc_state&lt;/code&gt; struct) is an array of pointers that makes up the fastbins data storage; the &lt;code&gt;fastbinsY&lt;/code&gt; array is the third entry in the &lt;code&gt;malloc_state&lt;/code&gt; struct. This causes an offset of all of the struct fields that are ahead of the &lt;code&gt;fastbinsY&lt;/code&gt;. For instance, in 2.23 (shown above), the offset is only 0x8 because of the 4 byte mutex and the 4 byte flags field. In 2.27+, the additional field &lt;a href="https://elixir.bootlin.com/glibc/glibc-2.27/source/malloc/malloc.c#L1684"&gt;have_fastchunks&lt;/a&gt; makes the offset 16 bytes until the &lt;code&gt;fastbinsY&lt;/code&gt; array.
          840 &lt;/p&gt;
          841 
          842 &lt;p&gt;
          843 Finally, we can deal with the fastbins offset itself. When the chunk is written into the &lt;code&gt;fastbinsY&lt;/code&gt; array, the index is based upon the &lt;u&gt;chunk size&lt;/u&gt;. Different chunk sizes are written to different locations of the array, as each chunk size has its own bin. For instance, the smallest size 0x20 is written into the &lt;code&gt;fastbinsY[0]&lt;/code&gt; and the largest size 0x80 is written into &lt;code&gt;fastbinsY[6]&lt;/code&gt;.
          844 &lt;/p&gt;
          845 
          846 &lt;p&gt;
          847 When choosing the location of the arena, the offset (to overwrite the proper memory location) must be carefully chosen based upon the size of the chunk being freed and the version of malloc. 
          848 &lt;/p&gt;
          849 
          850 &lt;h3&gt;
          851 Numerical Example
          852 &lt;/h3&gt;
          853 &lt;p&gt;
          854 Let's assume our target is the address &lt;code&gt;0x5555554444&lt;/code&gt; for GLibC 2.23 and we are writing a chunk of size 0x30. In order to write to the proper location, we would need to subtract the offset to &lt;code&gt;fastbinsY&lt;/code&gt; (8 bytes) array. Additionally, we need to account for the index of the fastbins chunk being written. A size of 0x30 is the 2nd entry in the fastbins, which results in 8 more bytes needing to be subtracted. This ends up being &lt;code&gt;0x5555554444-8-8 = 0x5555554434&lt;/code&gt; for the arena location to use. Now, when we write the chunk to the fastbins, the 8+8 will be added back into the address to write to our actual target &lt;code&gt;0x5555554444&lt;/code&gt;.
          855 &lt;/p&gt;
          856 
          857 &lt;p&gt;
          858 At first, the subtraction on the location of the arena does not seem intuitive. However, let's do this improperly with the same problem from above. If we choose the arena to be &lt;code&gt;0x5555554444&lt;/code&gt; (our target) then the added offset will actually write to &lt;code&gt;0x5555554454&lt;/code&gt; because the write occurs at arena + 0x10. Sometimes, I wish I would have paid more attention to math as a 3rd grader! 
          859 &lt;/p&gt;
          860 
          861 &lt;h3&gt;
          862 Fixing the Size Sanity Check
          863 &lt;/h3&gt;
          864 &lt;p&gt;
          865 &lt;pre&gt;
          866 if next_chunk_size &lt;= 0x10 or 
          867    next_chunk_size &gt;= arena-&gt;system_mem
          868 
          869         Crash
          870 &lt;/pre&gt;
          871 
          872 Using the fastbin variant of the House of Mind on recent versions of LibC only one security check needs to be bypassed. The &lt;a href="https://elixir.bootlin.com/glibc/glibc-2.23/source/malloc/malloc.c#L3897"&gt;code&lt;/a&gt; (pseudocode shown above) is validating that the next chunks size is not larger than the system allocation and the next chunks size is not smaller than the smallest possible chunk (0x10). In layman's terms, check if the next chunk size is crazy small or crazy large. If the above conditional is true, then the program will abort. 
          873 &lt;/p&gt;
          874 
          875 &lt;p&gt;
          876 For the smaller end, the size of the &lt;i&gt;next chunk&lt;/i&gt; needs to be greater than or equal to 0x10. This should be trivial to bypass because there is already a chunk above this one! So, you can just set the size of the fake chunk to line up with the original size of the chunk for the bypass. If this is not possible (for offset reasons), then this value could be written to a controllable offset.
          877 &lt;/p&gt;
          878 
          879 &lt;p&gt;
          880 The validation on the larger side is a little more complicated though. Because we have created the arena, the value of the arenas &lt;code&gt;system_mem&lt;/code&gt; needs to be set. &lt;code&gt;system_mem&lt;/code&gt; needs to be larger than the next chunk size (which has a minimum of 0x10). The &lt;code&gt;system_mem&lt;/code&gt; value is at an offset of 0x880 on 2.23 and 2.29 is at 0x888 for the &lt;code&gt;malloc_state&lt;/code&gt; struct. The offset depends on the version of GLibC's &lt;code&gt;malloc_state&lt;/code&gt; struct but can easily be found while using GDB. 
          881 &lt;/p&gt;
          882 
          883 &lt;p&gt;
          884 Once you find an alignment for the arena that has a proper value at the offset (or you write it yourself), the sanity check has been bypassed! With  this check bypassed, the chunk will be put into the arenas fastbin to overwrite the memory address when the chunk is freed. 
          885 &lt;/p&gt;
          886 
          887 &lt;h2&gt;
          888 Corrupting a Fastbin Chunk
          889 &lt;/h2&gt;
          890 
          891 &lt;p&gt;
          892 &lt;div style="width: 500px; font-size:80%; text-align:center; float: right; border: 1px solid black; padding: 10px; border-radius: 10px; margin: 20px;"&gt;&lt;img src="https://live.staticflickr.com/65535/51014857006_b08c15358a_o.png" width="450px" alt=""&gt;&lt;center&gt;Figure 4 - Fake Chunk Proper Setup&lt;/center&gt;&lt;/div&gt;
          893 In order to force a fake arena to be used, we must free a chunk! So, what should this chunk look like? There are a few main items to consider (shown in figure 4):
          894 &lt;ul&gt;
          895 &lt;li&gt;Use the correct chunk size. This comes down to three things:
          896 &lt;ul&gt;
          897 &lt;li&gt;Setting up a size of the chunk being freed for the proper offset on the WHERE place to write. Naturally, this has to be a fastbin sized chunk.&lt;/li&gt;
          898 &lt;li&gt;Setting the chunk size to align with a valid &lt;code&gt;next_chunk&lt;/code&gt; size.&lt;/li&gt;
          899 &lt;li&gt;Set the non-main arena bit (bit #3 as shown in figure 1) for a chunk.
          900 &lt;/li&gt;
          901 &lt;/ul&gt; 
          902 &lt;/li&gt;
          903 &lt;li&gt;The chunk MUST align down to the &lt;code&gt;HEAP_MAX_SIZE&lt;/code&gt; for our fake arena to be used when the chunk is freed.&lt;/li&gt;
          904 &lt;li&gt;Use the heap value being written in a smart way.&lt;/li&gt;
          905 &lt;/ul&gt;
          906 
          907 
          908 Everything above has already been discussed in previous sections besides the final point. So, we will go a little deeper into where to write. 
          909 &lt;/p&gt;
          910 
          911 &lt;h3&gt;
          912 Where to Write? 
          913 &lt;/h3&gt;
          914 &lt;p&gt;
          915 This is a WRITE-WHERE primitive. An attacker fully controls the &lt;i&gt;location&lt;/i&gt; (memory address) being written to but NOT the &lt;i&gt;value&lt;/i&gt; itself. Although this is mostly true, the value being written is the address of the chunk that we are freeing! So, we do not fully control this value but we can manipulate it by freeing chunks at different spots on the heap.
          916 &lt;/p&gt;
          917 
          918 &lt;p&gt;
          919 This primitive is usually a step in the chain, not the full exploit itself. A common use case for a WRITE-WHERE primitive is to overwrite a maximum index value to a large value in order to induce a further out of bounds read/write issues. For example, in the &lt;a href="https://maxwelldulin.com/BlogPost?post=3107454976"&gt;House of Husk&lt;/a&gt;, a maximum index value is overwritten in order to overwrite a variety of values in LibC to eventually pop a shell. This works quite well but in certain situations we can do better!
          920 &lt;/p&gt;
          921 
          922 &lt;p&gt;
          923 The value being written is a heap memory pointer. Because this is a pointer, we can use this to overwrite &lt;i&gt;another pointer&lt;/i&gt; to cause further corruption. For example, let's picture a string that has a size of 0x200. Then, we use this technique to overwrite a pointer to this string. Later on, we go to edit the string which NOW only has a heap pointer of only 0x70 bytes because of the overwrite. When this edit occurs, it creates a major buffer overflow on the 0x70 sized chunk because it is expects something of size 0x200. If the chunk above our freed chunk (next chunk) has important data in it, this could lead to major memory corruption. 
          924 &lt;/p&gt;
          925 
          926 &lt;h2&gt;
          927 Boom Goes the Dynamite (Free)
          928 &lt;/h2&gt;
          929 &lt;p&gt;
          930 &lt;center&gt;&lt;div style="width: 85%; font-size:80%; text-align:center; border: 1px solid black; padding: 10px; border-radius: 10px; margin: 20px;"&gt;&lt;img src="https://live.staticflickr.com/65535/51014237258_3d8a8fd7f9_o.png" width="80%" alt=""&gt;&lt;br/&gt;Figure 5 - Full Technique Setup&lt;/div&gt;&lt;/center&gt;
          931 
          932 At this point, we have created the &lt;code&gt;heap_info&lt;/code&gt; struct, setup a fake arena and have crafted the perfect chunk, all while avoiding some security checks. Figure 5 (shown above) has the full technique setup in a diagram, in order to make it easier to see. Now all we have to do is call &lt;b&gt;free&lt;/b&gt; on our crafted chunk to cause the memory write to occur! We did all of the hardwork already and get to reap the fruit of that work. 
          933 &lt;/p&gt;
          934 
          935 &lt;h2&gt;
          936 Profit
          937 &lt;/h2&gt;
          938 &lt;p&gt;
          939 Once the chunk has been written, you can now use this to cause even more corruption to eventually pop a shell! Have fun with this WRITE-WHERE primitive. 
          940 &lt;/p&gt;
          941 
          942 
          943 &lt;h2&gt;
          944 Pros &amp; Requirements
          945 &lt;/h2&gt;
          946 
          947 &lt;p&gt;
          948 This attack allows for a WRITE-WHERE primitive of a heap pointer. This attack has its positives and negatives though.
          949 &lt;/p&gt;
          950 &lt;h3&gt;
          951 Pros
          952 &lt;/h3&gt;
          953 &lt;p&gt;
          954 &lt;ul&gt;
          955 &lt;li&gt;
          956 Works on all versions of Malloc! The bulk of techniques are version locked.
          957 &lt;/li&gt;
          958 &lt;li&gt;Only requires a single byte controlled value overflow of the size and a heap leak.&lt;/li&gt;
          959 &lt;li&gt;Writes a large value to a nearly arbitrary location. This can be used as the start of deeper memory corruption, such as the Unsorted Bin Attack usage in the &lt;a href="https://1ce0ear.github.io/2017/11/26/study-house-of-orange/"&gt;House of Orange&lt;/a&gt;.&lt;/li&gt;
          960 &lt;li&gt;
          961 Writes a heap pointer, which could be used in a similar way to the &lt;a href="https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit"&gt;Unsafe Unlink&lt;/a&gt; attack, to cause further memory corruption by overwriting pointers. 
          962 &lt;/li&gt;
          963 &lt;li&gt;If the vulnerability for corrupting the chunk can be triggered multiple times, it is possible to trigger the write as many times as you need! For the location to write to, the original arena pointer can be edited or a different offset of &lt;code&gt;MAX_HEAP_SIZE &lt;/code&gt; can be used to set a new fake arena. 
          964 &lt;/ul&gt;
          965 &lt;/p&gt;
          966 
          967 &lt;h3&gt;
          968 Requirements
          969 &lt;/h3&gt;
          970 &lt;p&gt;
          971 Instead of a cons section, below is a list of requirements for this to work: 
          972 &lt;ul&gt;
          973 &lt;li&gt;Ability to corrupt fastbin sized chunk size field. A single byte overflow would suffice this condition.&lt;/li&gt;
          974 &lt;li&gt;Known location to write to (fake arena location). This may require a leak.&lt;/li&gt;
          975 
          976 &lt;li&gt;Ability to create a fake &lt;code&gt;heap_info&lt;/code&gt; struct. This comes down to two things:
          977 &lt;ul&gt; 
          978 &lt;li&gt;An attacker needs to know their relative location on the heap for proper placement of the fake &lt;code&gt;heap_info&lt;/code&gt; structure, which likely requires a heap leak. This could potentially be sprayed if the attacker has good enough control of the data though.&lt;/li&gt;
          979 &lt;li&gt;An attacker must be able to allocate a significant amount of heap data to reach the proper offset for the fake &lt;code&gt;heap_info&lt;/code&gt; struct. &lt;/li&gt;
          980 &lt;/li&gt;
          981 &lt;/ul&gt;
          982 
          983 &lt;li&gt;The overflown chunk MUST be in the &lt;i&gt;main arena&lt;/i&gt;. This is because &lt;i&gt;non-main arenas&lt;/i&gt; have a size limit to prevent this exact issue from occurring.&lt;/li&gt;
          984 &lt;li&gt;The next chunk (of the freed fastbin chunk) must be larger than 0x10 and smaller than &lt;code&gt;system_mem&lt;/code&gt;.&lt;/li&gt;
          985 &lt;li&gt;The fake arena &lt;code&gt;system_mem&lt;/code&gt; value of the fake arena must be larger than the &lt;i&gt;next chunk&lt;/i&gt; value, with a minimum value of 0x10. This is because of a security chunk of the size of a freed chunk.&lt;/li&gt;
          986 &lt;li&gt;With versions using TCache (2.26+), the TCache bin needs to be filled for the fastbin chunk size where the attack is being performed.&lt;/li&gt;
          987 &lt;/ul&gt;
          988 
          989 Although this feels like a lot of requirements, some of these are trivial to do, such as the next size chunk alignment or using the &lt;i&gt;main arena&lt;/i&gt;. If the situation is right, this can be a devastating attack.
          990 &lt;/p&gt;
          991 
          992 &lt;h2&gt;
          993 Future Work
          994 &lt;/h2&gt;
          995 
          996 &lt;p&gt;
          997 Heap exploitation techniques are  awesome, but vastly complicated. Because of this, I post fairly consistently about it and contribute to the how2heap repository whenever something interests me. I am in the process of developing a &lt;u&gt;GLibC Malloc Heap Exploitation workshop&lt;/u&gt; to help teach this very complex subject. I am looking to start giving this workshop at conferences by the end of the year (2021). I have applied to single conference so far (looking at you DEFCON) but plan on applying to many other technical conferences to give the course. So far, the beta testing has gone extremely well and I have been happy with the participants  understanding of the material after taking the course. So, keep an eye out for this course in the future :)
          998 &lt;/p&gt;
          999 
         1000 &lt;h2&gt;
         1001 Conclusion
         1002 &lt;/h2&gt;
         1003 &lt;p&gt;
         1004 This went from the heart-pounding &lt;i&gt;new discovery&lt;/i&gt; to a &lt;i&gt;let me explain&lt;/i&gt; article. Regardless, I hope you enjoyed this and learned something interesting about heap exploitation and computers today. I am happy that this forgotten technique will now be more accessible to those in the binary exploitation world. 
         1005 &lt;/p&gt;
         1006 &lt;p&gt;
         1007 Feel free to reach out to me (contact information is in the footer) if you have any questions or comments about this article. Cheers from &lt;b&gt;Maxwell "ꓘ" Dulin&lt;/b&gt;. 
         1008 &lt;/p&gt;</description><guid isPermaLink="false">https://maxwelldulin.com/BlogPost?post=2257705984</guid><pubDate>Mon, 22 Mar 2021 00:00:00 +0000</pubDate></item><item><title>Business Logic Ratings Bug</title><link>https://maxwelldulin.com/BlogPost?post=7676291072</link><description>&lt;p&gt;
         1009 The web is full of user reviewed rating websites that we trust with our lives every day. Glassdoor allows us to see inside a company; Amazon reviews allow us to see what it is like to own a product; Yelp for restaurants... this is just the world that we live in. 
         1010 &lt;/p&gt;
         1011 
         1012 &lt;p&gt;
         1013 But, what if you could &lt;i&gt;sway&lt;/i&gt; the rating system? On Yelp, you could make a restaurant appear at the top of every search! Like in a dream, everyone would flock to your restaurant. Or, you could kill a competitors business, making yours look more appealing. This would be an amazing weapon to gain a competitive advantage on the rest of the market. In this article, we discuss a business logic vulnerability that was able to skew the ratings systems on a popular location-based ratings site.  
         1014 &lt;/p&gt;
         1015 
         1016 &lt;h2&gt;
         1017 Vulnerability - The Case of Bad Input Validation
         1018 &lt;/h2&gt;
         1019 
         1020 &lt;h3&gt;
         1021 Juice Shop Version
         1022 &lt;/h3&gt;
         1023 
         1024 &lt;p&gt;
         1025 The company asked to remain anonymous and to have no screenshots of the bug. So, we will get creative! To demo the bug, we will look at &lt;a href="https://owasp.org/www-project-juice-shop/"&gt;Juice Shop&lt;/a&gt;; the bug from OWASP Juice Shop is essentially the same as the real site. For those not familiar, OWASP Juice Shop is an intentionally vulnerable site from the Open Web Application Security Project (OWASP). In fact, this was one of my main resources for learning prior to becoming a security engineer at my current company. 
         1026 &lt;/p&gt;
         1027 
         1028 &lt;p&gt;
         1029 OWASP Juice Shop has a &lt;i&gt;customer feedback&lt;/i&gt; functionality, which is normal for many applications. This ratings system is on a scale of 1-5 where a sliding scale can be set to choose the rating. On the backend request, this is simply an &lt;i&gt;integer&lt;/i&gt; being sent. What if we changed this to something that is NOT 1,2,3,4 or 5? The request for the &lt;i&gt;customer feedback&lt;/i&gt; is shown in &lt;i&gt;Figure 1&lt;/i&gt; below within Burp. 
         1030 &lt;/p&gt;
         1031 
         1032 &lt;center&gt;&lt;div style="width:95%; font-size:80%; text-align:center; border: 1px solid black; border-radius: 10px; margin: 10px; center;"&gt;&lt;img src="https://live.staticflickr.com/65535/51398887771_6a87e4f5b8_z.jpg" width="90%" alt=""&gt;&lt;center&gt;Figure 1: -100 Rating &lt;/center&gt;&lt;/div&gt;&lt;/center&gt;
         1033 
         1034 &lt;p&gt;
         1035 By changing the &lt;u&gt;rating&lt;/u&gt; to a non-expected value, such as -100 shown in Figure 1, we can drastically affect the overall customer ratings! This works in either the positive or negative direction. 
         1036 The challenge for this is titled &lt;a href="https://github.com/apox64/OWASP-Juice-Shop-Write-Up/blob/master/juice-shop-writeup.md#7-give-a-devastating-zero-star-feedback-to-the-store"&gt;give a devastating zero-star feedback to the store&lt;/a&gt;. On Juice Shop, we can change the &lt;i&gt;rating&lt;/i&gt; value to be set to 0 in order to solve this challenge. Now, this website is meant to be vulnerable. Does this bug look the same on a real and in production website?  
         1037 &lt;/p&gt;
         1038 
         1039 &lt;h3&gt;
         1040 The Actual Site
         1041 &lt;/h3&gt;
         1042 
         1043 &lt;p&gt;
         1044 The target website stores information about a location and allows for ratings this specific type of location. When giving a rating on the user interface, the options are given as a collection of 5 stars. The user highlights the amount of stars for the rating (1-5) and this is the value sent to the backend. As a result, it is not possible to enter a value other than 1-5 in the UI. As demonstrated in the example above, this is not enough though! Client-side restrictions are a futile security protection.
         1045 &lt;/p&gt;
         1046 
         1047 &lt;p&gt;
         1048 This seemed like fertile testing ground to go through, as I remembered the Juice Shop example from years ago. I used a web app pentesters best friend Burp to proxy the request and altered the rating to be &lt;b&gt;-5000&lt;/b&gt;. But, this failed with a &lt;code&gt;500&lt;/code&gt; error, which surprised me, since the application had never thrown me a &lt;code&gt;500&lt;/code&gt; error like this before.  After trying increasingly smaller negative numbers, to my surprise, &lt;b&gt;-500&lt;/b&gt; worked! I did the same thing in the positive direction with positive &lt;b&gt;500&lt;/b&gt; and this worked as well. It appears they had some sanity checking on the values but  not enough. What does this actually mean though? 
         1049 &lt;/p&gt;
         1050 
         1051 &lt;h3&gt;
         1052 Impact of Bug
         1053 &lt;/h3&gt;
         1054 
         1055 &lt;p&gt;
         1056 Most rating systems are calculated by taking the &lt;i&gt;average&lt;/i&gt;. This average is then used everywhere on the website for finding locations to visit. In fact, this &lt;i&gt;overall rating&lt;/i&gt; is the most important descriptor about a location to decide if people do or do not go somewhere. Being able to inject a rating of -500 or +500 would drastically raise the average rating (even past 5 stars) or drop the rating of the location significantly. Raising it could make the location extremely popular while dropping it would make the location unlikely to be visited. 
         1057 &lt;/p&gt;
         1058 
         1059 &lt;p&gt;
         1060 In a community that relies upon the reviews of others, being able to have this &lt;u&gt;large of a stake&lt;/u&gt; in the voting on each location allows for the rise in popularity or the downfall of a place by a single person. This compromises the people sourced system entirely; eventually, this could break the trust of the users and force them to use other services. Luckily, the fix for the bug is simple: only allow values from 1-5 on the backend.  
         1061 &lt;/p&gt;
         1062 
         1063 &lt;h2&gt;
         1064 Disclosure
         1065 &lt;/h2&gt;
         1066 
         1067 &lt;p&gt;
         1068 From previous experiences, I am  nervous when trying to report security vulnerabilities. As a result, I have learned to be very kind and come from the perspective of "&lt;i&gt;I found this bad bug. Please let me help you fix it.&lt;/i&gt;" If you go in guns blazing and attacking the service team with comments about how crappy the software is and how great of a hacker you are, then you are unlikely to have a good response with the team (we've all made this mistake before). Keep this in mind when reporting to companies or people without a formal bug disclosure program especially. Yes, I know testing on these sites is technically illegal; I hope that people see the good in us though, as the testing is done in good faith. In this particular case, the company had the best response I have ever received!
         1069 &lt;/p&gt;
         1070 
         1071 &lt;p&gt;
         1072 My initial communication with the company was to a senior engineer over LinkedIn. The company did not have a security email so this was my best course of action.  Eventually, a support ticket from the &lt;code&gt;support@company.com&lt;/code&gt; got back to me as well but hours after the initial contact with the engineer on LinkedIn.
         1073 &lt;/p&gt;
         1074 
         1075 &lt;p&gt;
         1076 Since the initial LinkedIn message only allows for only 300 characters, after the initial connection I sent a longer message explaining the details of the bug with a few screenshots. In particular, I sent a screenshot with the overall rating for the location being &lt;b&gt;0 stars&lt;/b&gt; and the next one being &lt;b&gt;9 stars&lt;/b&gt;, even though the limit is 5 stars. At this point, the engineer replied &lt;i&gt;Oh wow, that's pretty bad. we are on it. &lt;/i&gt;" The engineering team fixed the bug immediately.  
         1077 &lt;/p&gt;
         1078 
         1079 &lt;p&gt;
         1080 After this, the CTO of the company added me on LinkedIn and thanked me for the finding and responsible disclosure. The CTO let me know that a security engineering position would be opening up soon; they wanted me on the short list for the job once the position opened up. Additionally, they offered me a lifetime membership to the application! Considering I use the application quite a lot, this was very exciting for me :) A huge shoutout to the engineer and CTO for the amazing response to the finding. This makes me happy to find bugs and report them to make the internet a safer place. 
         1081 &lt;/p&gt;
         1082 
         1083 &lt;h2&gt;
         1084 Conclusion
         1085 &lt;/h2&gt;
         1086 
         1087 &lt;p&gt;
         1088 Vulnerabilities are not always complicated injection attacks. Commonly, they are centered around how the logic of the site; these bugs are undetectable by scanners. Although throwing &lt;code&gt;&amp;lt;script&amp;gt;alert(1)&amp;lt;/script&amp;gt; &lt;/code&gt; may find some XSS, lots of bugs require an understanding of the applications logic and expected functionality. Prior to throwing random inputs everywhere, ensure that you understanding the business-logic of the application in test. 
         1089 &lt;/p&gt;
         1090 
         1091 &lt;p&gt;
         1092 Feel free to reach out to me (contact information is in the footer) if you have any questions or comments about this article. Cheers from &lt;b&gt;Maxwell "ꓘ"Dulin&lt;/b&gt;. 
         1093 &lt;/p&gt;</description><guid isPermaLink="false">https://maxwelldulin.com/BlogPost?post=7676291072</guid><pubDate>Wed, 25 Aug 2021 00:00:00 +0000</pubDate></item><item><title>Finding Number Related Memory Corruption Vulns</title><link>https://maxwelldulin.com/BlogPost?post=9715056640</link><description>&lt;p&gt;
         1094 The root cause of many vulnerabilities are from the mishandling of numbers. The standard &lt;code&gt;int&lt;/code&gt; type can go from &lt;code&gt;0x7FFFFFFF&lt;/code&gt; all the way to &lt;code&gt;-0x80000000&lt;/code&gt; (notice the negative) with an integer overflow. Or, it can be truncated and change the number from positive to negative. Integers can be a nightmare in C and have caused many memory corruption vulnerabilities over the years. 
         1095 &lt;/p&gt;
         1096 
         1097 &lt;p&gt;
         1098 Recently quite a few findings have caught my attention that fall into the integer bug classes. A few to call out are  the &lt;a href="https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-local-privilege-escalation-linux.txt"&gt;integer truncation bug&lt;/a&gt; in the Linux kernel found by Qualys, the &lt;a href="https://securitylab.github.com/advisories/GHSL-2021-088_093-freebsd-bhyve/"&gt;signedness conversion&lt;/a&gt; bug (issue 2) in the BSD hypervisor by GHSL and an &lt;a href="https://research.checkpoint.com/2021/i-can-take-over-your-kindle/"&gt;integer overflow&lt;/a&gt; in the Kindle on a buffer allocation size found by Checkpoint. Then, my hacking buddy &lt;a href="https://twitter.com/seiranib"&gt;seiraib&lt;/a&gt; found an integer overflow bug fuzzing but we could not find where the overflow actually occurred at. All of this got me wondering: "&lt;i&gt;Can these bug classes be discovered at compilation or immediately crash at runtime?&lt;/i&gt;"
         1099 &lt;/p&gt;
         1100 
         1101 &lt;p&gt;
         1102 Yes, yes they can! GCC and Clang have compilation flags to find several bug classes at compile time. Additionally, there are some runtime protections that can cause crashes to make root causing MUCH easier. This blog post is about &lt;b&gt;finding vulnerabilities via compiler warnings and dynamic instrumentation&lt;/b&gt;. All of the source code snippets with extra examples can be found at &lt;a href="https://github.com/mdulin2/integer_compilation_flags"&gt;mdulin2/integer_ compilation_flags&lt;/a&gt;.
         1103 &lt;/p&gt;
         1104 
         1105 &lt;h2&gt;
         1106 Bug Classes
         1107 &lt;/h2&gt;
         1108 &lt;p&gt;
         1109 The goal is to change a number in a way that the program does not expect to cause memory corruption down the road. There are three number (but mainly integer) vulnerability classes in C that will be focused on: 
         1110 &lt;ul&gt; 
         1111 &lt;li&gt;&lt;b&gt;Overflow/underflow&lt;/b&gt;: Integers will simply wrap around if you go past the maximum or minimum value of the type in C. For instance, an overflow of a signed integer would go from &lt;code&gt;0x7FFFFFFF&lt;/code&gt; all the way to &lt;code&gt;-0x80000000&lt;/code&gt;. The underflow goes in the opposite direction and happens when subtracting values instead. &lt;/li&gt;
         1112 &lt;li&gt;&lt;b&gt;Truncation&lt;/b&gt;: Shrinking the storage capacity of a number. For instance, going from &lt;code&gt;uint64_t&lt;/code&gt; to &lt;code&gt;uint32_t&lt;/code&gt; would cut the storage capacity of the number in half. This has the potential to drastically change the value and signedness of the number. &lt;/li&gt;  
         1113 &lt;li&gt;&lt;b&gt;Signedness conversion&lt;/b&gt;: Numbers are either signed and unsigned (&lt;code&gt;unsigned int&lt;/code&gt; and &lt;code&gt;int&lt;/code&gt; for example). Going between these can have terrible consequences when converting from a negative signed number to an unsigned number or a very large unsigned number to a signed number. For instance, an unsigned integer of &lt;code&gt;0xFFFFFFFF&lt;/code&gt; converted to a signed integer would be -1 instead of a very large number. &lt;/li&gt; 
         1114 &lt;/ul&gt;
         1115 &lt;/p&gt;
         1116 
         1117 &lt;!-break--&gt;
         1118 
         1119 &lt;h2&gt;
         1120 Static Analysis
         1121 &lt;/h2&gt;
         1122 
         1123 &lt;p&gt;
         1124 Two of these bug classes can be determined at &lt;i&gt;compile time&lt;/i&gt; via specific compilation flags. Although there will likely be an exceptional amount of unexploitable occurrences of this, there are wonderful leads for finding vulnerabilities. 
         1125 &lt;/p&gt;
         1126 
         1127 &lt;h3&gt;
         1128 Truncation
         1129 &lt;/h3&gt;
         1130 
         1131 &lt;p&gt;
         1132 
         1133 &lt;div style="width:100%; box-sizing: border-box; display: flex; border: 1px solid black; border-radius: 10px"&gt;
         1134 &lt;div style = "flex: 45%; margin: 6px"
         1135 &gt;&lt;img src="https://live.staticflickr.com/65535/51444718168_8df5903730_o.png" style="width:98%;" alt="Truncation Warning Source Code WConversion"&gt;&lt;center&gt;Figure 1 - Truncation code &lt;/center&gt;&lt;/div&gt;
         1136 &lt;br/&gt;
         1137 &lt;div style = "flex: 45%; margin: 6px"&gt;&lt;img src="https://live.staticflickr.com/65535/51444476571_f84db04862_o.png" style="width:98%; border-left: 1px;" alt="Signedness conversion Warning Source Code WConversion"&gt;&lt;center&gt;Figure 2 - Signedness Conversion Code &lt;/center&gt;&lt;/div&gt;
         1138 &lt;/div&gt;
         1139 &lt;/p&gt;
         1140 
         1141 &lt;p&gt;
         1142 Using the &lt;code&gt;Wconversion&lt;/code&gt; flag during compilation will output the warning "&lt;i&gt;implicit conversions that may alter a value&lt;/i&gt;". This is directly referencing &lt;a href="https://github.com/mdulin2/integer_compilation_flags/blob/main/gcc/truncation.c"&gt;truncation&lt;/a&gt; and &lt;a href="https://github.com/mdulin2/integer_compilation_flags/blob/main/gcc/conversion.c"&gt;conversion&lt;/a&gt; bugs!
         1143 &lt;/p&gt;
         1144 
         1145 &lt;p&gt;
         1146 For example, code for the &lt;i&gt;truncation &lt;/i&gt; case can seen in &lt;i&gt;Figure 1&lt;/i&gt;. This code has a type of &lt;code&gt;long long&lt;/code&gt; that is being converted to an &lt;code&gt;int&lt;/code&gt;. Because this changes the storage capacity from 64-bit to 32-bit, this has the potential to cause corruption. When this code is compiled with the &lt;code&gt;Wconversion&lt;/code&gt; flag, a warning message will appear mentioning a truncation issue! This warning can be seen in Figure 3. This exact error message could have been used to find the &lt;a href="https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-local-privilege-escalation-linux.txt"&gt;Linux Kernel&lt;/a&gt; kernel bug mentioned above, when the conversion from &lt;code&gt;size_t&lt;/code&gt; (unsigned long long) to &lt;code&gt;int&lt;/code&gt; was performed.
         1147 &lt;br/&gt;&lt;br/&gt;&lt;br/&gt;
         1148 &lt;/p&gt;
         1149 
         1150 &lt;p&gt;
         1151 &lt;center&gt;
         1152 &lt;div style="border: 1px solid black; margin: 10px; border-radius: 10px;"&gt;
         1153 &lt;img src="https://live.staticflickr.com/65535/51444209760_44eca2b1ff_h.jpg" width="95%" alt="Truncation warning message" style="border-radius: 0px;"/&gt;
         1154 &lt;center&gt;Figure 3 - Truncation warning message&lt;/center&gt;&lt;/div&gt;
         1155 &lt;/center&gt;
         1156 &lt;/p&gt;
         1157 
         1158 &lt;p&gt;
         1159 Another interesting item to consider is the case with &lt;code&gt;float&lt;/code&gt; and &lt;code&gt;double&lt;/code&gt;. Since a &lt;code&gt;double&lt;/code&gt; is 2x the size of a float, the same type of truncation can be detected by the same compilation flag. An example of this in code is shown &lt;a href="https://github.com/mdulin2/integer_compilation_flags/blob/main/gcc/float_truncation.c"&gt;here&lt;/a&gt;. 
         1160 &lt;/p&gt;
         1161 
         1162 &lt;h3&gt;
         1163 Signedness
         1164 &lt;/h3&gt;
         1165 &lt;p&gt;
         1166 The &lt;code&gt;Wconversion&lt;/code&gt; flag can also be used in the detection of &lt;a href="https://github.com/mdulin2/integer_compilation_flags/blob/main/gcc/conversion.c"&gt;signedness conversion&lt;/a&gt; bugs. This happens when converting from a signed to an unsigned or converting from an unsigned integer to a signed integer; both of these issues are shown in Figure 2 above. An example of the compile time error message is shown in Figure 4 below. 
         1167 
         1168 &lt;center&gt;
         1169 &lt;div style="border: 1px solid black; margin: 10px; border-radius: 10px;"&gt;
         1170 &lt;img src="https://live.staticflickr.com/65535/51442547757_542b8beab9_h.jpg" width="95%" alt="Signedness conversion warning message" style="border-radius: 0px;" /&gt;
         1171 &lt;center&gt;Figure 4 - Signedness conversion warning message &lt;/center&gt;&lt;/div&gt;
         1172 &lt;/center&gt;
         1173 &lt;/p&gt;
         1174 
         1175 &lt;h3&gt;
         1176 Static Analysis Wrap Up
         1177 &lt;/h3&gt;
         1178 &lt;p&gt;
         1179 These flags only check for &lt;i&gt;implicit&lt;/i&gt; conversions. Sometimes, a value needs to be converted from an unsigned integer to a signed integer in order to do some math, which is valid and expected C. When a number is casted explicitly, these error messages will not show up, as a result. In order to find explicit casts, using something like CodeQL, manual review or dynamic testing is the way to go.
         1180 &lt;/p&gt;
         1181 
         1182 &lt;p&gt;
         1183 Although we have only been using &lt;code&gt;Wconversion&lt;/code&gt; for the static analysis so far, there are a plethora of flags that actually make up this single flag. For instance, &lt;code&gt;Wsign-conversion&lt;/code&gt; flag warns for implicit conversions that may change the sign of an integer value. For more information on these, visit the &lt;a href="https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html"&gt;GCC documentation&lt;/a&gt;. But, the tldr; is to just use &lt;code&gt;Wconversion&lt;/code&gt; to catch all of these issues at compilation time. 
         1184 &lt;/p&gt;
         1185 
         1186 &lt;h2&gt;
         1187 Dynamic Instrumentation
         1188 &lt;/h2&gt;
         1189 &lt;p&gt;
         1190 The static analysis is likely to pull up mostly false positives with a few real bugs. However, dynamic analysis, will always find real bugs, if the code path can be triggered. Below, we will show instrumentation options to crash/notify on integer related bugs. Instead of discussing bug classes, we are going to talk about a few specific flags in GCC and Clang. 
         1191 &lt;/p&gt;
         1192 
         1193 &lt;h3&gt;
         1194 ftrapv
         1195 &lt;/h3&gt;
         1196 &lt;p&gt;
         1197 This option generates traps for signed overflows on addition, subtraction and multiplication operations. Again, since this is dynamic testing, this will cause the program to crash whenever this occurs! An example of this code can be seen below: 
         1198 &lt;pre&gt;
         1199 int main(){
         1200         int a = 0x7FFFFFFF; 
         1201         a = a + 1; 
         1202         printf("Value: %d\n", a);
         1203 }
         1204 &lt;/pre&gt;
         1205 &lt;/p&gt;
         1206 
         1207 &lt;p&gt;
         1208 The code above will cause an integer overflow when the line &lt;code&gt;a = a + 1;&lt;/code&gt; is executed since the maximum size of an integer in C is 0x7FFFFFFF. What happens? The program is aborted and never reaches the print statement. By forcing the crash when the overflow occurs, we guarantee that the bug is detected and the cause of the overflow is much easier to find. This is extremely useful when fuzzing and trying to root cause a crash!
         1209 &lt;/p&gt;
         1210 
         1211 &lt;p&gt;
         1212 It should also be noted that this flag detects &lt;a href="https://github.com/mdulin2/integer_compilation_flags/blob/main/gcc/underflow.c"&gt;signed integer underflows&lt;/a&gt; as well. 
         1213 &lt;/p&gt;
         1214 
         1215 &lt;h3&gt;
         1216 fsanitize=integer
         1217 &lt;/h3&gt;
         1218 &lt;p&gt;
         1219 The &lt;a href="https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html"&gt;UBSAN&lt;/a&gt; (Uninitialized Behavior Sanitizer) for finding integer bugs is amazing! This flag is specific to Clang, for the integer related bugs. 
         1220 &lt;/p&gt;
         1221 
         1222 &lt;p&gt;
         1223 While the &lt;code&gt;ftrapv&lt;/code&gt; catches only &lt;i&gt;signed&lt;/i&gt; integer overflows, &lt;code&gt;fsanitize=integer&lt;/code&gt; will crash on unsigned and signed integer overflows (&lt;code&gt;signed-integer-overflow&lt;/code&gt; and &lt;code&gt;unsigned-integer-overflow&lt;/code&gt;). This means that all integer overflows, regardless of sign, via addition, subtraction or multiplication will be caught at runtime! Damn, this is a major improvement.
         1224 &lt;/p&gt;
         1225 
         1226 &lt;p&gt;
         1227 Besides the discovering of overflow/underflows in programs, we can find the two other bug classes mentioned with this flag: truncation (&lt;code&gt;implicit-signed-integer-truncation&lt;/code&gt; &amp; &lt;code&gt;implicit-unsigned-integer-truncation&lt;/code&gt;) and conversion (&lt;code&gt;implicit-integer-sign-change&lt;/code&gt;). Unlike the &lt;i&gt;static&lt;/i&gt; method above, a bad math operation must occur to trigger UBSAN to crash the program. 
         1228 &lt;/p&gt;
         1229 
         1230 &lt;p&gt;
         1231 Let's see this in action though! We will use the original signedness issue  (Figure 1). When we run the code, the &lt;code&gt;long long&lt;/code&gt; with the value &lt;code&gt;LONG_MAX&lt;/code&gt; ( 0x7FFFFFFFFFFFFFFF) will be cut in half (truncated)  because of the conversion to an integer. As a result, this will be &lt;code&gt;0xFFFFFFFF&lt;/code&gt; or -1 as a signed integer. Because of the extra instrumentation added, the program crashes upon this truncation happening! Nice for us, the instrumentation does not require a sign change; it checks that the value inside of the &lt;code&gt;long long&lt;/code&gt; will not fit into the &lt;code&gt;int&lt;/code&gt;. This crash can be seen in Figure 5 below.  
         1232 &lt;/p&gt;
         1233 
         1234 &lt;p&gt;
         1235 &lt;center&gt;
         1236 &lt;div style="border: 1px solid black; margin: 10px; border-radius: 10px;"&gt;
         1237 &lt;img src="
         1238 https://live.staticflickr.com/65535/51444688718_88c594fa3e_b.jpg" width="95%" alt="Truncation Crash Clang" style="border-radius: 0px;" /&gt;
         1239 &lt;center&gt;Figure 5 - Truncation Conversion Crash&lt;/center&gt;&lt;/div&gt;
         1240 &lt;/center&gt;
         1241 &lt;/p&gt;
         1242 
         1243 &lt;h2&gt;
         1244 Are We Missing Anything?
         1245 &lt;/h2&gt;
         1246 &lt;p&gt;
         1247 We have mentioned dynamic and static checks for integer overflows/underflows, integer truncation's and signedness conversion issues. However, there is one thing missing from the dynamic instrumentation: floating point math. 
         1248 &lt;/p&gt;
         1249 
         1250 &lt;p&gt;
         1251 When a float is overflowed in C, it goes to &lt;a href="https://github.com/mdulin2/integer_compilation_flags/blob/main/NaN_inf.c"&gt;infinity&lt;/a&gt; or &lt;code&gt;inf&lt;/code&gt;. Oddly enough, the float never truly wraps around because of how floating point math handles precision; it simply just goes to infinity! An example of this overflow can be seen at &lt;a href="https://github.com/mdulin2/integer_compilation_flags/blob/main/clang/float_overflow.c"&gt;here&lt;/a&gt;. 
         1252 &lt;/p&gt;
         1253 
         1254 &lt;p&gt;
         1255 An additional uncaught bug is float truncation. For instance, the conversion from a &lt;code&gt;double&lt;/code&gt; to a &lt;code&gt;float&lt;/code&gt; is not caught at runtime. There is a misleading UBSAN flag (&lt;code&gt;-fsanitize=float-cast-overflow&lt;/code&gt;) that only finds bad double/float to integer conversions but NOT truncation bugs between floating point numbers. An example of this can be seen &lt;a href="https://github.com/mdulin2/integer_compilation_flags/blob/main/clang/float_truncation.c"&gt;here&lt;/a&gt;.
         1256 &lt;/p&gt;
         1257 
         1258 &lt;p&gt;Knowing about floats becoming  &lt;code&gt;inf&lt;/code&gt; and &lt;code&gt;NaN&lt;/code&gt; may be useful to know since some crazy issues, such as Jack Bakers  &lt;a href="https://www.youtube.com/watch?v=4weoWSzuCxs"&gt;NaN propagation&lt;/a&gt; bug in the Unreal Gaming Engine do happen. However, there is currently no detection on the overflowing, underflowing, truncation or &lt;a href="https://github.com/mdulin2/integer_compilation_flags/blob/main/NaN_inf.c"&gt;NaN/Inf&lt;/a&gt; usage of floating point numbers in C at runtime. A deep dive into the craziness of floating point math in C is out of the scope for this article but it is really interesting and worth an afternoon of learning about, as it is easy to make mistakes with.
         1259 &lt;/p&gt;
         1260 
         1261 &lt;h2&gt;
         1262 Conclusion
         1263 &lt;/h2&gt;
         1264 &lt;p&gt;
         1265 When trying to find vulnerabilities, any help from automated tools or instrumentation is a huge win. Besides the integer vulnerability classes mentioned above, there are loads of other interesting flags and instrumentation, such as the well known ASAN (Address Sanitizer) to help find use after free bugs or the lesser known &lt;a href="https://docs.microsoft.com/en-us/cpp/sanitizers/error-stack-use-after-scope?view=msvc-160"&gt;use after scope&lt;/a&gt; vulnerability on stack memory. There are many other compilation flags and instrumentation options to help find specific bugs classes as well; this article only focuses on finding integer related vulnerability classes. 
         1266 &lt;/p&gt;
         1267 
         1268 &lt;p&gt;
         1269 I hope the knowledge of these compilation warnings and dynamic instrumentation helps you find many bugs in the future! Feel free to reach out to me (contact information is in the footer) if you have any questions or comments about this article. Cheers from &lt;b&gt;Maxwell "ꓘ" Dulin&lt;/b&gt;. 
         1270