├── .gitignore ├── LICENSE ├── README.org ├── beavtex.cls ├── images ├── bounds-check.png ├── buffer-overflow.png ├── categorization-of-vulns-old.png ├── categorization-of-vulns.png ├── cvss-distribution.pdf ├── format-string.png ├── integer-overflow.png ├── kernel.png ├── privilege-rings.png ├── vma.png ├── vuln-types.png ├── vulns-disto-x.pdf ├── vulns-distro.png └── vulns-trends.pdf ├── thesis.bib ├── thesis.org └── thesis.pdf /.gitignore: -------------------------------------------------------------------------------- 1 | /*.bbl 2 | /*.blg 3 | /*.fdb_latexmk 4 | /thesis.fls 5 | /thesis.loaf 6 | /thesis.loap 7 | /thesis.loat 8 | /thesis.lof 9 | /thesis.lot 10 | /*.tex 11 | /thesis.aux 12 | /thesis.log 13 | /thesis.out 14 | /thesis.toc 15 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | 307 | including for purposes of Section 3(b); and 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public 411 | licenses. Notwithstanding, Creative Commons may elect to apply one of 412 | its public licenses to material it publishes and in those instances 413 | will be considered the “Licensor.” The text of the Creative Commons 414 | public licenses is dedicated to the public domain under the CC0 Public 415 | Domain Dedication. Except for the limited purpose of indicating that 416 | material is shared under a Creative Commons public license or as 417 | otherwise permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the 425 | public licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. 428 | 429 | -------------------------------------------------------------------------------- /README.org: -------------------------------------------------------------------------------- 1 | #+TITLE: A Decade of Linux Kernel Vulnerabilities, their Mitigation and Open Problems 2 | 3 | This repository contains source for my Master's Thesis on different types of 4 | Linux Kernel Vulnerabilities that exist today. It consists of a survey of ~10 5 | years of Linux Kernel CVEs (2007-2016), divides them into various broad 6 | categories of Vulnerabilities and includes existing mitigation for them. 7 | 8 | While the mitigation aren't exhaustive, they are sampled from both Research 9 | Literature and industry i.e. existing code in Linux Kernel, out-of-tree patches 10 | etc. It also includes various tools that can be used to analyze and detect 11 | various kind of Vulnerabilities. 12 | 13 | 14 | * How to read this content? 15 | 16 | The entire thesis is divided into 5 chapters, first 3 of which are related to 17 | Linux Kernel Vulnerabilities. 4th chapter talks about Return Oriented 18 | Programming attacks. 5th Chapter concludes with what classes of vulnerabilities 19 | do and don't have any pro-active solution for them. 20 | 21 | You can browse [[thesis.org][a copy in the repository]] or have a look at the [[thesis.pdf][PDF]]. PDF has 22 | slightly better formatting and comes with complete references. 23 | 24 | 25 | * License 26 | 27 | A Decade of Linux Kernel Vulnerabilities, their Mitigation and Open Problems (c) by Abhilash Raj 28 | 29 | The contents of this repository are licensed under a Creative Commons 30 | Attribution-ShareAlike 4.0 International License. 31 | 32 | You should have received a copy of the license along with this work. If not, see 33 | . 34 | -------------------------------------------------------------------------------- /beavtex.cls: -------------------------------------------------------------------------------- 1 | \newcommand{\filename}{beavtex} 2 | \newcommand{\fileversion}{v1.0} 3 | \newcommand{\filedate}{2011/10/01} 4 | 5 | %------------------------------------------------------------------------------- 6 | % BeavTeX 7 | % Oregon State University Thesis Class 8 | % 9 | % Neville Mehta : 10 | % Added algorithm listing 11 | % Fixed appendix listings to only include main headings 12 | % Line breaks for underlined text (e.g., for a long title on the abstract page) 13 | % Minor formatting changes (approved by the Graduate School) 14 | % Compatibility with hyperref 15 | % 16 | % Adapted from the version by Deling Ren (deling_ren@lifetime.oregonstate.edu) 17 | % In accordance (hopefully) to the OSU graduate school thesis guide (referred to 18 | % as T.G.): http://oregonstate.edu/dept/grad_school/current/thesis.html 19 | % Changes from John Metta's version: tons and tons of change. 20 | % Several definition generators are defined. 21 | % Now (mostly) complies LaTeX2e package writer's guide. 22 | % Most commands are LaTeX rather than TeX now. 23 | % Options added. 24 | % 25 | % Adapted from John Metta's BeavTeX class 26 | % John Metta (prev. name: Pennington) 27 | % 28 | % Originally thesis.sty 29 | % ------------------------------------------------------------------------------- 30 | 31 | \NeedsTeXFormat{LaTeX2e} 32 | \ProvidesClass{\filename}[\filedate\space\fileversion\space BeavTeX: OSU thesis class] 33 | 34 | \RequirePackage{setspace} 35 | \RequirePackage{ifthen} 36 | \RequirePackage[normalem]{ulem} 37 | \newcommand{\ulinewithbreaks}[1]{\expandafter\uline\expandafter{#1}} 38 | 39 | % BeavTeX symbol 40 | \newcommand{\beavtex}{$\rm{B^{\kern-.1em\textsc{e}}\ \kern-.6em_{\textsc{a}}\kern-.4em\textsc{v}}$\kern-.3em\TeX} 41 | 42 | % ------------------------------------------------------------------------------- 43 | % beavtex is a modified (default 12pt) book style. it accepts these options: 44 | 45 | % [10pt], [11pt], and [12pt]. These options are passed to book class. The 46 | % default is 12pt. 47 | 48 | % [1.5in], [1.7in]. These two options set the left margin. Default is 1.7 49 | % inches. 50 | 51 | % [onehalf], [double]. These two options set the line spacing. Default is 52 | % double. 53 | 54 | % [preprint], [submission]. When [preprint] is set, it is assumed that the 55 | % thesis is printed double-sided, opens right (so that every chapter begins on 56 | % an odd page). Date is included in the header, along with the word "Draft". In 57 | % the submission version, it is assumed that the document will be printed 58 | % single-sided. Default is submission. 59 | 60 | % [seploa]. When [seploa] is set, the appendices do not appear in the main table 61 | % of contents (except for the entry "appendices" itself). Rather, they are 62 | % listed in the list of appendices. According to T.G., you need this if you have 63 | % more than five appendices. It is not set by default. 64 | % ------------------------------------------------------------------------------- 65 | \newcommand{\bookclass}{book} 66 | 67 | % Font size, this option is passed to book class. T.G. : use regular, 10- to 12- 68 | % point size for text. Default is 12pt. 69 | \newcommand{\@ftsize}{} 70 | \DeclareOption{10pt}{\renewcommand{\@ftsize}{10pt}} 71 | \DeclareOption{11pt}{\renewcommand{\@ftsize}{11pt}} 72 | \DeclareOption{12pt}{\renewcommand{\@ftsize}{12pt}} 73 | 74 | % Left side margin. 75 | % [1.5in], [1.7in] 76 | % T.G. : the left margin must be at least 1.5 inches (recommend 1.7). default is 77 | % 1.7, unless [1.5in] is specified. 78 | \newcommand{\@lmarwidth}{} 79 | \newcommand{\@smarwidth}{} 80 | \newcommand{\@texwidth}{} 81 | 82 | \DeclareOption{1.5in}{% 83 | \renewcommand{\@lmarwidth}{.5in}% 84 | \renewcommand{\@smarwidth}{.0in}% 85 | \renewcommand{\@texwidth}{6.0in}% 86 | } 87 | \DeclareOption{1.7in}{% 88 | \renewcommand{\@lmarwidth}{.7in}% 89 | \renewcommand{\@smarwidth}{.0in}% 90 | \renewcommand{\@texwidth}{5.8in}% 91 | } 92 | 93 | % One and half or double spacing? 94 | % [onehalf], [double] 95 | % T.G. : use either double or 1.5 line spacing for the body of text. default is 96 | % double, unless [onehalf] is specified. 97 | \newcommand{\@spacing}{} 98 | \DeclareOption{onehalf}{\renewcommand{\@spacing}{\onehalfspacing}} 99 | \DeclareOption{double}{\renewcommand{\@spacing}{\doublespacing}} 100 | \AtEndOfClass{\@spacing} 101 | 102 | % Draft or final version? 103 | % [preprint], [submission] 104 | % Default is submission. 105 | \newif\if@preprint 106 | 107 | \DeclareOption{preprint}{\@preprinttrue} 108 | \DeclareOption{submission}{\@preprintfalse} 109 | 110 | % [seploa] 111 | \newif\if@seploa 112 | \@seploafalse 113 | \DeclareOption{seploa}{\@seploatrue} 114 | 115 | % Other options are passed to the book class. 116 | \DeclareOption*{\PassOptionsToClass{\CurrentOption}{\bookclass}} 117 | 118 | % These are the default options. 119 | \ExecuteOptions{12pt,1.7in,double,submission} 120 | \ProcessOptions\relax 121 | 122 | \if@preprint 123 | \PassOptionsToClass{twoside,openright}{\bookclass} 124 | \else 125 | \PassOptionsToClass{oneside,openany}{\bookclass} 126 | \fi 127 | 128 | \PassOptionsToClass{\@ftsize}{\bookclass} 129 | 130 | \LoadClass[letterpaper,onecolumn]{\bookclass} 131 | 132 | % ------------------------------------------------------------------------------- 133 | % Set up page layout. 134 | 135 | % \evensidemargin is used when [twoside] is set (by [preprint]). 136 | \setlength{\oddsidemargin}{\@lmarwidth} 137 | \setlength{\evensidemargin}{\@smarwidth} 138 | \setlength{\textwidth}{\@texwidth} 139 | % Other margins. T.G.: all other margins must be at least 1 inch. 140 | \setlength{\topmargin}{0in} 141 | \setlength{\headheight}{.5in} 142 | \setlength{\headsep}{.3in} 143 | \setlength{\footskip}{.5in} 144 | 145 | % ------------------------------------------------------------------------------- 146 | % Font size for headings. T.G. : headings may be either 14pt only if all 147 | % headings are 14pt. I assume you want them all be 14 pt (at least I do). For 148 | % 12pt headings, you need: 149 | % \renewcommand{\heading}{\fontsize{12}{14.5}\selectfont} 150 | 151 | % Note: commands like \large etc are proportional to normal font size (which can 152 | % be 10, 11 or 12), and should be avoided. Use \heading when you typeset a 153 | % heading. 154 | \newcommand{\heading}{\fontsize{14}{18}\selectfont} 155 | 156 | %------------------------------------------------------------------------------- 157 | % Misc commands 158 | 159 | % Redefine the default (plain) pagestyle 160 | \renewcommand{\ps@plain}{% 161 | \renewcommand{\@oddhead}{% 162 | \ifnum\value{page}=1\else 163 | \if@preprint 164 | \textit{\small Draft}\hfil\@formatdate 165 | \fi 166 | \hfil\thepage 167 | \fi 168 | } 169 | \renewcommand{\@evenhead}{% 170 | \thepage\hfil\@formatdate\hfil\textit{\small Draft}% 171 | } 172 | \renewcommand{\@oddfoot}{} 173 | \renewcommand{\@evenfoot}{} 174 | } 175 | 176 | \newcommand{\@formatdate}{% 177 | \textit{\scriptsize {\number\year/\number\month/\number\day}}% 178 | } 179 | 180 | % To clear completely empty pages. It's not really that necessary. The 181 | % submission version is single-sided and won't need this anyway. 182 | \renewcommand{\cleardoublepage}{% 183 | \clearpage% 184 | \if@twoside% 185 | \ifodd\c@page% 186 | \else\mbox{}\thispagestyle{empty}\newpage% 187 | \if@twocolumn\mbox{}\newpage\fi\fi\fi% 188 | } 189 | 190 | % Authors: use \mainmatter before the main content 191 | \renewcommand{\mainmatter}{% 192 | \cleardoublepage% 193 | \@mainmattertrue% 194 | \pagestyle{plain} 195 | \setcounter{page}{1}% 196 | \pagenumbering{arabic}% 197 | } 198 | 199 | % T.G. : Figures and tables in the appendices should be listed in separate 200 | % lists. So we will put them in separate files (loaf and loat). Use 201 | % \listofappendixfigures and \listofappendixtables to make the listings. 202 | 203 | % Authors: use \appendix before you begin the appendix to generate the appendix 204 | % page and to set up some relevant variables. 205 | 206 | \newif\if@appendix 207 | 208 | \newcommand{\ext@toc}{toc} 209 | 210 | \renewcommand\appendix{% 211 | \cleardoublepage% 212 | \@appendixtrue% 213 | \setcounter{chapter}{0}% 214 | \setcounter{section}{0}% 215 | \gdef\@chapapp{\appendixname}% 216 | \gdef\thechapter{\@Alph\c@chapter}% 217 | \renewcommand{\ext@figure}{loaf}% 218 | \renewcommand{\ext@table}{loat}% 219 | \if@seploa\def\ext@toc{loap}\fi% 220 | \addcontentsline{toc}{chapter}{Appendices}% 221 | \appendixpage% 222 | } 223 | 224 | % T.G. : An appendix page is required before the appendices. 225 | \newcommand{\appendixpage}{% 226 | \vspace*{0.3\textheight} 227 | \begin{center}{\heading APPENDICES}\end{center}% 228 | \clearpage% 229 | } 230 | 231 | % Redefine \@chapter, so that appendices are added in .loap file if [seploa] is 232 | % set. Also, I commented out the lines adding space between figures/tables of 233 | % different chapters. I am not sure yet if it is necessary. The following code 234 | % is pretty much copied from book.cls. If it looks messy, don't blame me :P 235 | \def\@chapter[#1]#2{ 236 | \ifnum \c@secnumdepth >\m@ne 237 | \if@mainmatter 238 | \refstepcounter{chapter} 239 | \typeout{\@chapapp\space\thechapter.} 240 | \addcontentsline{\ext@toc}{\if@appendix app\else chapter\fi}{\protect\numberline{\thechapter}#1} 241 | \else 242 | \addcontentsline{\ext@toc}{chapter}{#1} 243 | \fi 244 | \else 245 | \addcontentsline{\ext@toc}{chapter}{#1} 246 | \fi 247 | \chaptermark{#1} 248 | \addtocontents{\ext@figure}{\protect\addvspace{10\p@}} 249 | \addtocontents{\ext@table}{\protect\addvspace{10\p@}} 250 | \ifthenelse{\isundefined{\listofalgorithms}}{}{ 251 | \addtocontents{\ext@algorithm}{\protect\addvspace{10\p@}} 252 | } 253 | \if@twocolumn 254 | \@topnewpage[\@makechapterhead{#2}] 255 | \else 256 | \@makechapterhead{#2} 257 | \@afterheading 258 | \fi 259 | } 260 | 261 | % T.G. : These elements should be single-spaced: Blocked quotes, bibliography, 262 | % footnotes, endnotes, multiple-line headers, figure titles, listed items 263 | % (optional). 264 | 265 | % Bibliography: Redefine the bibliography to make it single-spaced. 266 | \renewcommand{\bibliography}[1]{% 267 | \if@filesw 268 | \immediate\write\@auxout{\string\bibdata{#1}}% 269 | \fi 270 | \addcontentsline{toc}{chapter}{Bibliography} 271 | \begin{singlespacing} 272 | \@input@{\jobname.bbl} 273 | \end{singlespacing} 274 | } 275 | 276 | % Footnotes: they are not effected by linespacing anyway (always single-spaced). 277 | % Multiple-line headers: as long as we use \heading, it's single-spaced. 278 | % Others: I am not sure yet... 279 | 280 | % User definitions. 281 | % A definition generator for variables. 282 | % #1: optional default value, if missing, the variable is mandatory. Failing to 283 | % define it will raise a latex error. 284 | % #2: command to define the variable 285 | % \define{somevar} will define a new command \somevar with 1 parameter. It 286 | % stores the contents to a variable \@somevar. 287 | 288 | \newcommand{\definevar}[2][-]{% 289 | \expandafter\def\csname #2\endcsname{% 290 | \expandafter\gdef\csname @#2\endcsname 291 | } 292 | \if#1- 293 | \csname #2\endcsname{\@latex@error{No #2 defined}\@ehc} 294 | \else 295 | \csname #2\endcsname{#1} 296 | \fi 297 | } 298 | 299 | \definevar{title} 300 | \definevar{author} 301 | \definevar{doctype} 302 | \definevar{degree} 303 | \definevar{major} 304 | \definevar{department} 305 | \definevar{advisor} 306 | 307 | \definevar[*]{twomajor} 308 | \definevar[*]{twodepartment} 309 | \definevar[*]{coadvisor} 310 | 311 | \definevar[Chair]{depthead} 312 | \definevar[Chair]{twodepthead} 313 | \definevar[Department]{depttype} 314 | \definevar[Department]{twodepttype} 315 | 316 | \definevar[\today]{submitdate} 317 | \definevar[\the\year]{commencementyear} 318 | 319 | \definevar{abstract} 320 | \definevar[*]{nopretext} 321 | 322 | % \xxxcontent commands will be generated when we generate definitions for the 323 | % pretext pages. the following definitions provide backward compatibility and 324 | % nicer names. 325 | \newcommand{\acknowledgements}{\ackcontent} 326 | \newcommand{\contributors}{\contricontent} 327 | \newcommand{\preface}{\prefcontent} 328 | \newcommand{\dedication}{\dedcontent} 329 | 330 | %------------------------------------------------------------------------------- 331 | % Document parts. See T.G. 332 | %------------------------------------------------------------------------------- 333 | \newcommand{\emptyline}{\mbox{}\newline} 334 | 335 | \newcommand{\advisorstring}{% 336 | \hfill 337 | \if\@coadvisor * \@advisor 338 | \else \@advisor\hfill\@coadvisor 339 | \fi 340 | \hfill 341 | } 342 | 343 | % Flyleaf, a blankpage 344 | \newcommand{\flyleaf}{\thispagestyle{empty}\phantom{}\newpage} 345 | 346 | % Abstract page 347 | \newcommand{\abspage}{ 348 | \pagestyle{empty} 349 | \begin{doublespacing} 350 | \begin{center} 351 | {\heading AN ABSTRACT OF THE \MakeUppercase{\@doctype} OF} 352 | \end{center} 353 | \begin{flushleft} 354 | \noindent 355 | \ulinewithbreaks{\@author} for the degree of \ulinewithbreaks{\@degree} in% 356 | \if\@twomajor * \ulinewithbreaks{\@major} 357 | \else 358 | \ulinewithbreaks{\@major} and \ulinewithbreaks{\@twomajor} 359 | \fi 360 | presented on \uline{\@submitdate}.\\ 361 | \emptyline 362 | \noindent Title: \ulinewithbreaks{\@title} 363 | \end{flushleft} 364 | \emptyline 365 | Abstract approved: \hrulefill \\ 366 | \phantom{Abstract approved:\ }\advisorstring 367 | \vspace{1em} 368 | \end{doublespacing} 369 | \noindent 370 | \emptyline 371 | \emptyline 372 | \@abstract 373 | \clearpage 374 | } 375 | 376 | % Copyright page 377 | \newcommand{\copyrightpage}{ 378 | \begin{singlespacing} 379 | \thispagestyle{empty} 380 | \vspace*{10\baselineskip} 381 | \begin{center} 382 | ${}^\copyright$Copyright by \@author\\ 383 | \@submitdate \\ 384 | All Rights Reserved 385 | \end{center} 386 | \end{singlespacing} 387 | \clearpage 388 | } 389 | 390 | % Title page 391 | \renewcommand{\titlepage}{ 392 | \thispagestyle{empty} 393 | \begin{center} 394 | \setlength{\baselineskip}{14.5pt} 395 | {\heading \@title} \\ 396 | \emptyline by\\ \emptyline 397 | \@author\\ 398 | \vfill 399 | A \MakeUppercase{\@doctype}\\ \emptyline 400 | submitted to\\ \emptyline 401 | Oregon State University\\ 402 | \vfill 403 | in partial fulfillment of\\ 404 | the requirements for the\\ 405 | degree of\\ \emptyline 406 | \@degree 407 | \vfill 408 | Presented \@submitdate\\ 409 | Commencement June \@commencementyear 410 | \end{center} 411 | \clearpage 412 | } 413 | 414 | % Approval page 415 | \newcommand{\approvalpage}{ 416 | \thispagestyle{empty} 417 | \begin{singlespacing} 418 | \begin{flushleft} 419 | \noindent 420 | \ulinewithbreaks{\@degree} \MakeLowercase{\@doctype} of \ulinewithbreaks{\@author} 421 | presented on \uline{\@submitdate}. \\ 422 | \vspace{3em} 423 | APPROVED:\\ 424 | \vspace{3em} 425 | \hrulefill \\ 426 | % Major Professor (Co- if there is a coadvisor} 427 | \if\@coadvisor * 428 | \else Co-\fi Major Professor, representing \@major \\ 429 | \vspace{3em} 430 | % Second major professor if exists 431 | \if\@coadvisor * 432 | \else\hrulefill \\ Co-Major Professor, representing \@twomajor \\ 433 | \vspace{3em} 434 | \fi 435 | \hrulefill \\ 436 | % major department head 437 | \@depthead\ of the \@depttype\ of \@department \\ 438 | \vspace{3em} 439 | \if\@twodepartment * 440 | \else 441 | % Here is the second Department 442 | \hrulefill \\ 443 | \@twodepthead\ of the \@twodepttype\ of \@twodepartment \\ 444 | \vspace{3em} 445 | \fi 446 | \hrulefill \\ 447 | Dean of the Graduate School \\ 448 | \vfill 449 | I understand that my \MakeLowercase{\@doctype} will become part of the 450 | permanent collection of Oregon State University libraries. My signature 451 | below authorizes release of my \MakeLowercase{\@doctype} to any reader 452 | upon request. 453 | \vspace{3em} \\ 454 | \hrulefill \\ 455 | \makebox[\textwidth]{\hfill \@author, Author \hfill} 456 | \end{flushleft} 457 | \end{singlespacing} 458 | \clearpage 459 | } 460 | 461 | \definevar[*]{dedcontent} 462 | \newcommand{\dedpage}{ 463 | \if \@dedcontent * 464 | \else 465 | \thispagestyle{empty} 466 | \vspace*{10\baselineskip} 467 | \begin{center} 468 | \@dedcontent 469 | \end{center} 470 | \clearpage 471 | \fi 472 | } 473 | 474 | % A definition generator for general pretext pages. 475 | % #1: short name 476 | % #2: page title 477 | % \definepretextpage{name}{title} generates a command \namepage, \namecontent, 478 | % a internal variable \@namecontent, and an environment \namepageenv. 479 | % Authors: Use \namecontent to define the contents to be displayed. If it is not 480 | % specified, the page will not be produced. You can also change the environment 481 | % by using \renewenvironment{namepageenv}. 482 | 483 | \newcommand{\definepretextpage}[2]{% 484 | \definevar[*]{#1content} 485 | \expandafter\newcommand\csname #1page\endcsname{% 486 | \if\csname @#1content\endcsname * 487 | \else 488 | \thispagestyle{empty} 489 | \begin{center} 490 | {\heading #2} 491 | \end{center} 492 | \noindent 493 | \emptyline 494 | \csname @#1content\endcsname 495 | \clearpage 496 | \fi 497 | } 498 | } 499 | 500 | % Acknowledgements, contribution, dedication, and preface. 501 | \definepretextpage{ack}{ACKNOWLEDGEMENTS} 502 | \definepretextpage{contri}{CONTRIBUTION OF AUTHORS} 503 | \definepretextpage{pref}{PREFACE} 504 | 505 | % Format all of the frontmatter 506 | % The commands for optional pages will check if the content is defined. If not, 507 | % the page will not be produced. There is no need to check here. 508 | \newcommand{\pretext}{% 509 | \pagenumbering{roman} 510 | 511 | % Mandatory pages 512 | \flyleaf % A. Flyleaf 513 | \abspage % B. Abstract 514 | \copyrightpage % C. Copyright page 515 | \titlepage % D. Title page 516 | \approvalpage % E. Approval page 517 | 518 | % Optional pages 519 | \ackpage % F. Acknowledgments 520 | \contripage % G. Contribution of authors 521 | 522 | % Listings 523 | \tableofcontents % H. 524 | \listoffigures % I. 525 | \listoftables % J 526 | 527 | % Algorithm listing 528 | \ifthenelse{\isundefined{\listofalgorithms}}{}{ 529 | \expandafter\newcommand\csname ps@loaa\endcsname{ 530 | \renewcommand{\@oddhead}{% 531 | \parbox{\textwidth}{% 532 | \centering {\heading LIST OF ALGORITHMS} \\ 533 | \uline{Algorithm}\hfill\uline{Page}}} 534 | \renewcommand{\@oddfoot}{} 535 | \renewcommand{\@evenfoot}{}} 536 | \expandafter\newcommand\csname ps@loab\endcsname{% 537 | \renewcommand{\@oddhead}{% 538 | \parbox{\textwidth}{% 539 | \centering {\heading LIST OF ALGORITHMS\ (Continued)} \\ 540 | \uline{Algorithm}\hfill\uline{Page}}} 541 | \renewcommand{\@evenhead}{\@oddhead} 542 | \renewcommand{\@oddfoot}{} 543 | \renewcommand{\@evenfoot}{}} 544 | \renewcommand{\listalgorithmname}{\pagestyle{loab}\thispagestyle{loaa}\vspace{-1.28in}} 545 | \listofalgorithms 546 | } 547 | 548 | \listofappendices % K. 549 | \listofappendixfigures % L. 550 | \listofappendixtables % M. 551 | 552 | % Optional pages 553 | \dedpage % O. Dedication 554 | \prefpage % P. Preface 555 | } 556 | 557 | \renewcommand{\maketitle}{\if\@nopretext \else\pretext\fi} 558 | 559 | % T.G. : A flyleaf is needed at the end of the thesis. 560 | \AtEndDocument{\clearpage \flyleaf} 561 | 562 | % Chapter heading. T.G. : all title must be the same size (14 or normal). 563 | \renewcommand{\@makechapterhead}[1]{% 564 | \vspace*{10\p@}% 565 | { 566 | \begin{center} 567 | \normalfont\heading 568 | \ifnum \c@secnumdepth >\m@ne 569 | \if@mainmatter\heading\@chapapp\ \thechapter:\ \fi 570 | \fi 571 | \heading #1\par\nobreak 572 | \vskip 20\p@ 573 | \end{center} 574 | } 575 | } 576 | 577 | % Silent chapter heading (\chapter*). 578 | \renewcommand{\@makeschapterhead}[1]{% 579 | \vspace*{10\p@}% 580 | { 581 | \begin{center} 582 | \normalfont\heading 583 | \heading #1\par\nobreak 584 | \vskip 20\p@ 585 | \end{center} 586 | } 587 | } 588 | 589 | \def\@sect#1#2#3#4#5#6[#7]#8{% 590 | \ifnum #2>\c@secnumdepth 591 | \let\@svsec\@empty 592 | \else 593 | \refstepcounter{#1}% 594 | \protected@edef\@svsec{\@seccntformat{#1}\relax}% 595 | \fi 596 | \@tempskipa #5\relax 597 | \ifdim \@tempskipa>\z@ 598 | \begingroup 599 | #6{% 600 | \@hangfrom{\hskip #3\relax\@svsec}% 601 | \interlinepenalty \@M #8\@@par}% 602 | \endgroup 603 | \csname #1mark\endcsname{#7}% 604 | \if@appendix \else 605 | \addcontentsline{\ext@toc}{#1}{% 606 | \ifnum #2>\c@secnumdepth \else 607 | \protect\numberline{\csname the#1\endcsname}% 608 | \fi 609 | #7}% 610 | \fi 611 | \else 612 | \def\@svsechd{% 613 | #6{\hskip #3\relax 614 | \@svsec #8}% 615 | \csname #1mark\endcsname{#7}% 616 | \if@appendix \else 617 | \addcontentsline{\ext@toc}{#1}{% 618 | \ifnum #2>\c@secnumdepth \else 619 | \protect\numberline{\csname the#1\endcsname}% 620 | \fi 621 | #7}% 622 | \fi}% 623 | \fi 624 | \@xsect{#5}} 625 | 626 | \renewcommand{\section}{\@startsection 627 | {section}% % the name 628 | {1}% % the level 629 | {0mm}% % the indent 630 | {-\baselineskip}% % the before skip 631 | {0.5\baselineskip}% % the after skip 632 | {\normalfont\heading}} % the style 633 | 634 | \renewcommand{\subsection}{\@startsection 635 | {subsection}% % the name 636 | {1}% % the level 637 | {0mm}% % the indent 638 | {-\baselineskip}% % the before skip 639 | {0.5\baselineskip}% % the after skip 640 | {\normalfont\heading}} % the style 641 | 642 | \renewcommand{\subsubsection}{\@startsection 643 | {subsubsection}% % the name 644 | {1}% % the level 645 | {0mm}% % the indent 646 | {-\baselineskip}% % the before skip 647 | {0.5\baselineskip}% % the after skip 648 | {\normalfont\heading}} % the style 649 | 650 | % Listings. l@kind handles an entry of a "kind" in the listing 651 | % T.G. : No bold faces should appear in the pretext (including the listings, of 652 | % course). This is why l@chapter is being redefined here. 653 | \def\l@chapter#1#2{% 654 | \ifnum \c@tocdepth >\m@ne 655 | \addpenalty{-\@highpenalty}% 656 | \vskip 1.0em \@plus\p@ 657 | \setlength\@tempdima{1.5em}% 658 | \begingroup 659 | \parindent \z@ \rightskip \@pnumwidth 660 | \parfillskip -\@pnumwidth 661 | \leavevmode %\large 662 | \advance\leftskip\@tempdima 663 | \hskip -\leftskip 664 | #1\nobreak\hfil \nobreak\hb@xt@\@pnumwidth{\hss #2}\par 665 | \penalty\@highpenalty 666 | \endgroup 667 | \fi} 668 | 669 | % For separate listings of appendices ([seploa] is set), every appendix is 670 | % listed the same as a chapter, otherwise it is like a section. not sure if it's 671 | % the optimal solution. but it looks nice for now. 672 | \def\l@app#1#2{% 673 | \if@seploa\l@chapter{#1}{#2} 674 | \else 675 | {\vskip 4pt {\baselineskip 14.5pt% 676 | \@dottedtocline{1}{1pc}{2em}{#1}{#2}}} 677 | \fi 678 | } 679 | 680 | \def\l@section#1#2{\vskip 4pt {\baselineskip 14.5pt% 681 | \@dottedtocline{1}{1pc}{2em}{#1}{#2}} } 682 | \def\l@subsection#1#2{ {\baselineskip 14.5pt% 683 | \@dottedtocline{2}{4pc}{2.8em}{#1}{#2}}} 684 | \def\l@subsubsection#1#2{{\baselineskip 14.5pt% 685 | \@dottedtocline{3}{7pc}{3.4em}{#1}{#2}}} 686 | \def\l@figure#1#2{\vskip 9.5pt {\baselineskip 14.5pt% 687 | \@dottedtocline{1}{1.5em}{2.3em}{#1}{#2}}} 688 | \let\l@table\l@figure 689 | 690 | % We want to ignore footnotes in any listing. If this is not what you want, 691 | % change the line starting with \let\footnote in \definelisting 692 | \newcommand{\@ignore}[1]{} 693 | 694 | % There are these kinds of listings: 695 | % Table of contents (toc) 696 | % List of figures (lof) 697 | % List of tables (lot) 698 | % List of appendices (loap) 699 | % List of appendix tables (loat) 700 | % List of appendix figures (loaf) 701 | 702 | % A definition generator for listings. It generates two page styles (one for the 703 | % first page, one for the rest) and a command. 704 | % #1 : file extension name 705 | % #2 : full name (to appear as the heading of the listing) 706 | % #3 : short name (to appear as the heading on the top of the left column) 707 | % #4 : command name (to be used to make the listing) 708 | \newcommand{\definelisting}[4]{ 709 | % Page style for the first page. If twoside is set, the page is an 710 | % oddpage. Otherwise, \evenhead is not used anyway. 711 | \expandafter\newcommand\csname ps@#1a\endcsname{% 712 | \renewcommand{\@oddhead}{% 713 | \parbox{\textwidth}{% 714 | \centering {\heading #2} \\ 715 | \uline{#3}\hfill\uline{Page} 716 | } 717 | } 718 | \renewcommand{\@oddfoot}{} 719 | \renewcommand{\@evenfoot}{} 720 | } 721 | % Page style for the following pages 722 | \expandafter\newcommand\csname ps@#1b\endcsname{% 723 | \renewcommand{\@oddhead}{% 724 | \parbox{\textwidth}{% 725 | \centering {\heading #2\ (Continued)} \\ 726 | \uline{#3}\hfill\uline{Page} 727 | } 728 | } 729 | \renewcommand{\@evenhead}{\@oddhead} 730 | \renewcommand{\@oddfoot}{} 731 | \renewcommand{\@evenfoot}{} 732 | } 733 | % The command itself. I had to use \def rather than \newcommand because we 734 | % might be redefining \tableofcontents. 735 | \expandafter\def\csname #4\endcsname{% 736 | \cleardoublepage 737 | \pagestyle{#1b} 738 | \thispagestyle{#1a} 739 | {\let\footnote\@ignore\@starttoc{#1}} 740 | } 741 | } 742 | 743 | \definelisting{toc}{TABLE OF CONTENTS}{}{tableofcontents} 744 | \definelisting{lof}{LIST OF FIGURES}{Figure}{listoffigures} 745 | \definelisting{lot}{LIST OF TABLES}{Table}{listoftables} 746 | \definelisting{loap}{LIST OF APPENDICES}{}{listofappendices} 747 | \definelisting{loaf}{LIST OF APPENDIX FIGURES}{Figure}{listofappendixfigures} 748 | \definelisting{loat}{LIST OF APPENDIX TABLES}{Table}{listofappendixtables} 749 | 750 | \endinput 751 | -------------------------------------------------------------------------------- /images/bounds-check.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/bounds-check.png -------------------------------------------------------------------------------- /images/buffer-overflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/buffer-overflow.png -------------------------------------------------------------------------------- /images/categorization-of-vulns-old.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/categorization-of-vulns-old.png -------------------------------------------------------------------------------- /images/categorization-of-vulns.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/categorization-of-vulns.png -------------------------------------------------------------------------------- /images/cvss-distribution.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/cvss-distribution.pdf -------------------------------------------------------------------------------- /images/format-string.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/format-string.png -------------------------------------------------------------------------------- /images/integer-overflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/integer-overflow.png -------------------------------------------------------------------------------- /images/kernel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/kernel.png -------------------------------------------------------------------------------- /images/privilege-rings.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/privilege-rings.png -------------------------------------------------------------------------------- /images/vma.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/vma.png -------------------------------------------------------------------------------- /images/vuln-types.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/vuln-types.png -------------------------------------------------------------------------------- /images/vulns-disto-x.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/vulns-disto-x.pdf -------------------------------------------------------------------------------- /images/vulns-distro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/vulns-distro.png -------------------------------------------------------------------------------- /images/vulns-trends.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/images/vulns-trends.pdf -------------------------------------------------------------------------------- /thesis.bib: -------------------------------------------------------------------------------- 1 | @misc{GNUGener72:online, 2 | author = {}, 3 | title = {GNU General Public License v2.0 - GNU Project - Free Software Foundation}, 4 | howpublished = {\url{https://www.gnu.org/licenses/gpl-2.0.html}}, 5 | month = {}, 6 | year = {}, 7 | note = {(Accessed on 09/02/2017)} 8 | } 9 | 10 | @misc{DistroWa62:online, 11 | author = {}, 12 | title = {DistroWatch.com: Put the fun back into computing. Use Linux, BSD.}, 13 | howpublished = {\url{http://distrowatch.com/search.php?ostype=Linux#simple}}, 14 | month = {}, 15 | year = {}, 16 | note = {(Accessed on 09/02/2017)} 17 | } 18 | 19 | @misc{TheMITRE0:online, 20 | author = {}, 21 | title = {The MITRE Corporation}, 22 | howpublished = {\url{https://www.mitre.org/}}, 23 | month = {}, 24 | year = {}, 25 | note = {(Accessed on 09/02/2017)} 26 | } 27 | 28 | @misc{CVECommo56:online, 29 | author = {}, 30 | title = {CVE - Common Vulnerabilities and Exposures (CVE)}, 31 | howpublished = {\url{https://cve.mitre.org/}}, 32 | month = {}, 33 | year = {}, 34 | note = {(Accessed on 09/02/2017)} 35 | } 36 | 37 | @misc{SELinuxW93:online, 38 | author = {}, 39 | title = {SELinux Wiki}, 40 | howpublished = {\url{https://selinuxproject.org/page/Main_Page}}, 41 | month = {}, 42 | year = {}, 43 | note = {(Accessed on 09/02/2017)} 44 | } 45 | 46 | @misc{AppArmor89:online, 47 | author = {}, 48 | title = {AppArmor}, 49 | howpublished = {\url{http://wiki.apparmor.net/index.php/Main_Page}}, 50 | month = {}, 51 | year = {}, 52 | note = {(Accessed on 09/02/2017)} 53 | } 54 | 55 | @misc{Homepage39:online, 56 | author = {}, 57 | title = {Homepage of PaX}, 58 | howpublished = {\url{https://pax.grsecurity.net/}}, 59 | month = {}, 60 | year = {}, 61 | note = {(Accessed on 09/02/2017)} 62 | } 63 | 64 | @misc{grsecuri84:online, 65 | author = {}, 66 | title = {grsecurity}, 67 | howpublished = {\url{https://grsecurity.net/}}, 68 | month = {}, 69 | year = {}, 70 | note = {(Accessed on 09/02/2017)} 71 | } 72 | 73 | @misc{grsecuri28:online, 74 | author = {}, 75 | title = {grsecurity - Passing the Baton}, 76 | howpublished = {\url{https://grsecurity.net/passing_the_baton.php}}, 77 | month = {}, 78 | year = {}, 79 | note = {(Accessed on 09/02/2017)} 80 | } 81 | 82 | @misc{CVEsecur92:online, 83 | author = {}, 84 | title = {CVE security vulnerability database. Security vulnerabilities, exploits, references and more}, 85 | howpublished = {\url{https://www.cvedetails.com/}}, 86 | month = {}, 87 | year = {}, 88 | note = {(Accessed on 09/02/2017)} 89 | } 90 | 91 | @misc{CVECVE2033:online, 92 | author = {}, 93 | title = {CVE - CVE-2013-2852}, 94 | howpublished = {\url{https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2852}}, 95 | month = {}, 96 | year = {}, 97 | note = {(Accessed on 09/02/2017)} 98 | } 99 | 100 | @misc{kernelgit82:online, 101 | author = {}, 102 | title = {Linux kernel source tree}, 103 | howpublished = {\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=708d96fd060bd1e729fc93048cea8901f8bacb7c}}, 104 | month = {}, 105 | year = {}, 106 | note = {(Accessed on 09/02/2017)} 107 | } 108 | 109 | @misc{CVECVE2084:online, 110 | author = {}, 111 | title = {CVE - CVE-2016-0728}, 112 | howpublished = {\url{http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2016-0728}}, 113 | month = {}, 114 | year = {}, 115 | note = {(Accessed on 09/03/2017)} 116 | } 117 | 118 | @misc{grsecuri58:online, 119 | author = {}, 120 | title = {PAX\_REFCOUNT Documentation}, 121 | howpublished = {\url{https://forums.grsecurity.net/viewtopic.php?f=7&t=4173&sid=413d82eb6e90b14534ef069fd8f2cb63}}, 122 | month = {}, 123 | year = {}, 124 | note = {(Accessed on 09/03/2017)} 125 | } 126 | 127 | @misc{Coccinel90:online, 128 | author = {}, 129 | title = {Coccinelle: A Program Matching and Transformation Tool for Systems Code}, 130 | howpublished = {\url{http://coccinelle.lip6.fr/}}, 131 | month = {}, 132 | year = {}, 133 | note = {(Accessed on 09/04/2017)} 134 | } 135 | 136 | @misc{Smatchth54:online, 137 | author = {}, 138 | title = {Smatch the Source Matcher}, 139 | howpublished = {\url{http://smatch.sourceforge.net/}}, 140 | month = {}, 141 | year = {}, 142 | note = {(Accessed on 09/04/2017)} 143 | } 144 | 145 | @misc{Usingthe29:online, 146 | author = {}, 147 | title = {GCC Documentation}, 148 | howpublished = {\url{https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Instrumentation-Options.html#index-fstack-protector}}, 149 | month = {}, 150 | year = {}, 151 | note = {(Accessed on 09/05/2017)} 152 | } 153 | 154 | @misc{Introduc76:online, 155 | author = {}, 156 | title = {Introduction to Intel® Memory Protection Extensions | Intel® Software}, 157 | howpublished = {\url{https://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions}}, 158 | month = {}, 159 | year = {}, 160 | note = {(Accessed on 09/05/2017)} 161 | } 162 | 163 | @article{DBLP:Oleksenko, 164 | author = {Oleksii Oleksenko and 165 | Dmitrii Kuvaiskii and 166 | Pramod Bhatotia and 167 | Pascal Felber and 168 | Christof Fetzer}, 169 | title = {Intel {MPX} Explained: An Empirical Study of Intel {MPX} and Software-based 170 | Bounds Checking Approaches}, 171 | journal = {CoRR}, 172 | volume = {abs/1702.00719}, 173 | year = {2017}, 174 | url = {http://arxiv.org/abs/1702.00719}, 175 | timestamp = {Wed, 07 Jun 2017 14:41:44 +0200}, 176 | biburl = {http://dblp.uni-trier.de/rec/bib/journals/corr/OleksenkoKBFF17}, 177 | bibsource = {dblp computer science bibliography, http://dblp.org} 178 | } 179 | 180 | @misc{gccdocs:online, 181 | author = {}, 182 | title = {Using the GNU Compiler Collection (GCC): Integer Overflow Builtins}, 183 | howpublished = {\url{https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html}}, 184 | month = {}, 185 | year = {}, 186 | note = {(Accessed on 09/06/2017)} 187 | } 188 | 189 | @misc{kernelgi67:online, 190 | author = {}, 191 | title = {Linux kernel source tree - RandStruct plugin}, 192 | howpublished = {\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=313dd1b629219db50cad532dba6a3b3b22ffe622}}, 193 | month = {}, 194 | year = {}, 195 | note = {(Accessed on 09/06/2017)} 196 | } 197 | 198 | @inproceedings{Abadi:2005:CI:1102120.1102165, 199 | author = {Abadi, Mart\'{\i}n and Budiu, Mihai and Erlingsson, \'{U}lfar and Ligatti, Jay}, 200 | title = {Control-flow Integrity}, 201 | booktitle = {Proceedings of the 12th ACM Conference on Computer and Communications Security}, 202 | series = {CCS '05}, 203 | year = {2005}, 204 | isbn = {1-59593-226-7}, 205 | location = {Alexandria, VA, USA}, 206 | pages = {340--353}, 207 | numpages = {14}, 208 | url = {http://doi.acm.org/10.1145/1102120.1102165}, 209 | doi = {10.1145/1102120.1102165}, 210 | acmid = {1102165}, 211 | publisher = {ACM}, 212 | address = {New York, NY, USA}, 213 | keywords = {binary rewriting, control-flow graph, inlined reference monitors, vulnerabilities}, 214 | } 215 | 216 | @misc{StackShi26:online, 217 | author = {}, 218 | title = {Stack Shield}, 219 | howpublished = {\url{http://www.angelfire.com/sk/stackshield/}}, 220 | month = {}, 221 | year = {}, 222 | note = {(Accessed on 09/06/2017)} 223 | } 224 | 225 | @misc{Controlf71:online, 226 | author = {}, 227 | title = {Control-flow Enforcement Technology Preview}, 228 | howpublished = {\url{https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf}}, 229 | month = {}, 230 | year = {}, 231 | note = {(Accessed on 09/07/2017)} 232 | } 233 | 234 | @misc{NVDCVSS22:online, 235 | author = {}, 236 | title = {NVD - CVSS}, 237 | howpublished = {\url{https://nvd.nist.gov/vuln-metrics/cvss}}, 238 | month = {}, 239 | year = {}, 240 | note = {(Accessed on 09/09/2017)} 241 | } 242 | 243 | @misc{RouterEx31:online, 244 | author = {}, 245 | title = {Router Exploitation Cisco}, 246 | howpublished = {\url{https://www.blackhat.com/presentations/bh-usa-09/LINDNER/BHUSA09-Lindner-RouterExploit-PAPER.pdf}}, 247 | month = {}, 248 | year = {}, 249 | note = {(Accessed on 09/11/2017)} 250 | } 251 | 252 | @misc{GitHubgo15:online, 253 | author = {}, 254 | title = {GitHub - google/syzkaller: syzkaller is an unsupervised, coverage-guided Linux system call fuzzer}, 255 | howpublished = {\url{https://github.com/google/syzkaller}}, 256 | month = {}, 257 | year = {}, 258 | note = {(Accessed on 09/12/2017)} 259 | } 260 | 261 | @misc{CVELi79:online, 262 | author = {}, 263 | title = {CVE - CVE List Master Copy}, 264 | howpublished = {\url{https://cve.mitre.org/cve/cve.html}}, 265 | month = {}, 266 | year = {}, 267 | note = {(Accessed on 09/12/2017)} 268 | } 269 | 270 | @misc{kernelgi23:online, 271 | author = {}, 272 | title = {Linux kernel source tree - kptr\_restrict}, 273 | howpublished = {\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=455cd5ab305c90ffc422dd2e0fb634730942b257}}, 274 | month = {}, 275 | year = {}, 276 | note = {(Accessed on 10/09/2017)} 277 | } 278 | 279 | @misc{LinuxKer21:online, 280 | author = {}, 281 | title = {Linux-Kernel Archive: Linux 2.0 really is released}, 282 | howpublished = {\url{http://lkml.iu.edu/hypermail/linux/kernel/9606.1/0056.html}}, 283 | month = {}, 284 | year = {}, 285 | note = {(Accessed on 11/14/2017)} 286 | } 287 | 288 | @misc{GitHubgo91:online, 289 | author = {}, 290 | title = {GitHub - google/syzkaller: syzkaller is an unsupervised, coverage-guided kernel fuzzer}, 291 | howpublished = {\url{https://github.com/google/syzkaller}}, 292 | month = {}, 293 | year = {}, 294 | note = {(Accessed on 11/14/2017)} 295 | } 296 | 297 | @misc{GitHubke85:online, 298 | author = {}, 299 | title = {GitHub - kernelslacker/trinity: Linux system call fuzzer}, 300 | howpublished = {\url{https://github.com/kernelslacker/trinity}}, 301 | month = {}, 302 | year = {}, 303 | note = {(Accessed on 11/14/2017)} 304 | } 305 | 306 | 307 | 308 | @inproceedings{Xu:2015:CEU:2810103.2813637, 309 | author = {Xu, Wen and Li, Juanru and Shu, Junliang and Yang, Wenbo and Xie, Tianyi and Zhang, Yuanyuan and Gu, Dawu}, 310 | title = {From Collision To Exploitation: Unleashing Use-After-Free Vulnerabilities in Linux Kernel}, 311 | booktitle = {Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security}, 312 | series = {CCS '15}, 313 | year = {2015}, 314 | isbn = {978-1-4503-3832-5}, 315 | location = {Denver, Colorado, USA}, 316 | pages = {414--425}, 317 | numpages = {12}, 318 | url = {http://doi.acm.org/10.1145/2810103.2813637}, 319 | doi = {10.1145/2810103.2813637}, 320 | acmid = {2813637}, 321 | publisher = {ACM}, 322 | address = {New York, NY, USA}, 323 | keywords = {linux kernel exploit, memory collision, user-after-free vulnerability}, 324 | } 325 | 326 | @misc{httpswww44:online, 327 | author = {}, 328 | title = {Intel Reference Manual}, 329 | howpublished = {\url{https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf}}, 330 | month = {}, 331 | year = {}, 332 | note = {(Accessed on 12/09/2017)} 333 | } 334 | 335 | 336 | @inproceedings{Shacham:2007:GIF:1315245.1315313, 337 | author = {Shacham, Hovav}, 338 | title = {The Geometry of Innocent Flesh on the Bone: Return-into-libc Without Function Calls (on the x86)}, 339 | booktitle = {Proceedings of the 14th ACM Conference on Computer and Communications Security}, 340 | series = {CCS '07}, 341 | year = {2007}, 342 | isbn = {978-1-59593-703-2}, 343 | location = {Alexandria, Virginia, USA}, 344 | pages = {552--561}, 345 | numpages = {10}, 346 | url = {http://doi.acm.org/10.1145/1315245.1315313}, 347 | doi = {10.1145/1315245.1315313}, 348 | acmid = {1315313}, 349 | publisher = {ACM}, 350 | address = {New York, NY, USA}, 351 | keywords = {instruction set, return-into-libc, turing completeness}, 352 | } 353 | 354 | 355 | @misc{RFC2828I29:online, 356 | author = {}, 357 | title = {RFC 2828 - Internet Security Glossary}, 358 | howpublished = {\url{https://tools.ietf.org/html/rfc2828}}, 359 | month = {}, 360 | year = {}, 361 | note = {(Accessed on 12/10/2017)} 362 | } 363 | -------------------------------------------------------------------------------- /thesis.org: -------------------------------------------------------------------------------- 1 | #+TITLE: A Decade of Linux Kernel Vulnerabilities, their Mitigation and Open Problems 2 | #+LANGUAGE: en 3 | #+OPTIONS: H:5 num:3 author:nil email:nil creator:nil timestamp:nil skip:nil 4 | #+EXPORT_SELECT_TAGS: export 5 | #+EXPORT_EXCLUDE_TAGS: noexport 6 | #+LaTeX_CLASS: beavtex-thesis 7 | #+LaTeX_HEADER: \usepackage{hyperref} 8 | #+LATEX_HEADER: \usepackage{graphicx} 9 | #+LATEX_HEADER: \usepackage{tabularx} 10 | #+LATEX_HEADER: \usepackage{caption} 11 | #+LATEX_HEADER: \usepackage{multicol} 12 | #+LATEX_HEADER: \newcommand{\source}[1]{\caption*{Source: {#1}} } 13 | #+LATEX_HEADER: \usepackage[colorinlistoftodos,prependcaption,textsize=footnotesize,disable]{todonotes} 14 | #+LATEX_HEADER: \usepackage{floatrow} 15 | #+LATEX_HEADER: \DeclareFloatFont{tiny}{\footnotesize} 16 | #+LATEX_HEADER: \floatsetup[table]{font=tiny} 17 | #+LaTeX_HEADER: \author{Abhilash Raj} 18 | #+LaTeX_HEADER: \degree{Master of Science} 19 | #+LaTeX_HEADER: \doctype{Thesis} 20 | #+LaTeX_HEADER: \department{Electrical Engineering and Computer Science} 21 | #+LaTeX_HEADER: \depttype{School} 22 | #+LaTeX_HEADER: \depthead{Director} 23 | #+LaTeX_HEADER: \major{Computer Science} 24 | #+LaTeX_HEADER: \advisor{Rakesh Bobba} 25 | #+LaTeX_HEADER: \submitdate{December 15, 2017} 26 | #+LaTeX_HEADER: \commencementyear{2018} 27 | #+LaTeX_HEADER: \abstract{ 28 | #+LaTeX_HEADER: The aim of this thesis is to study past 10 years of security vulnerabilities reported against Linux Kernel and all existing mitigation techniques that prevent the exploitation of those vulnerabilities. To systematically study the security vulnerabilities, they were categorized into classes and sub-classes based on their type. \\ 29 | #+LaTeX_HEADER: This thesis first examines over 1100 Common Vulnerabilities and Exposures (CVEs) reported against Linux Kernel in the period of past 10 years. It then presents a survey of techniques that exist today to prevent exploitation or mitigate impact of these vulnerabilities. Techniques surveyed include those added to Linux kernel in past few years, notable patches and those proposed in research papers but not yet adopted. 30 | #+LaTeX_HEADER: Finally, based on the above analysis, this thesis discusses the gaps in the security of Linux Kernel that cannot be efficiently mitigated using the existing techniques and explores open problems for future research. 31 | #+LaTeX_HEADER: } 32 | #+LaTeX_HEADER: 33 | #+STARTUP: latexpreview 34 | 35 | #+BEGIN_LaTeX 36 | \mainmatter 37 | #+END_LaTEX 38 | 39 | * Introduction 40 | 41 | #+BEGIN_LaTeX 42 | \todo[inline]{- History and Popularity of Linux; Why is it important? \newline 43 | - Why is Linux security important? What is CVE? \newline 44 | - What is included in this survey? Why? \newline 45 | - With existing defenses it is hard to say how many vulns are still relevant. 46 | } 47 | #+END_LaTeX 48 | 49 | GNU/Linux is one of the most popular general purpose operating system used today 50 | because of its robust performance, free availability and open nature of 51 | development. All discussions on development and direction of the project happens 52 | in public mailing lists and open for anyone to participate. Today, there are 53 | well over 1 billion devices running GNU/Linux including smartphones (e.g. Android), 54 | embedded devices, autonomous cars, robots (e.g. ROS) and most of the servers 55 | running the Internet. 56 | 57 | There are over 18 million lines of code in last release of Linux, licensed 58 | under GNU General Public License, version 2 cite:GNUGener72:online. According 59 | to Distrowatch cite:DistroWa62:online , a popular website tracking Linux 60 | distributions, there are 275 GNU/Linux distributions including special purpose 61 | distributions built to work on old hardware, embedded devices, desktops, 62 | special servers etc. Henceforth, any mention of the term /Linux/ corresponds to 63 | the Linux Kernel unless explicitly specified. 64 | 65 | ** Linux and Security 66 | 67 | Security is an important aspect of any operating system and a large number of 68 | critical infrastructures today runs on Linux, it is important to asses its 69 | current state of security. There are over 1100 CVEs[fn::CVE database 70 | cite:CVECommo56:online is a common database of all the security vulnerabilities 71 | reported against softwares, maintained by a non-profit organization called 72 | MITRE Foundation cite:TheMITRE0:online.] reported against Linux in past 10 73 | years (2007-2016). 74 | 75 | 76 | While this number is alarmingly high for a project on which a lot of critical 77 | infrastructure depends today, by itself, it's a poor metric to measure Linux's 78 | security. Vulnerabilities are simply bugs in a software that have security 79 | implications. Measuring the security impact for each bug may not be trivial in 80 | case of a system software like Linux. Vulnerabilities found via testing 81 | techniques like fuzzing, static analysis, regression testing are often not 82 | exploitable. 83 | 84 | ** Problem to be addressed by this thesis 85 | 86 | #+NAME: fig:yearly-distribution-of-vulns 87 | #+CAPTION: Yearly distribution of CVEs for the past decade 88 | [[./images/vulns-trends.pdf]] 89 | 90 | Most vulnerabilities, or software bugs in general, often follow a pattern that 91 | is repeated. Multiple variants of a vulnerability can be found in the different 92 | parts of the code. These types of vulnerabilities have been known to us for a 93 | long time, but, they are still show up frequently in Linux. If we look at the 94 | frequency of these vulnerabilities over past 10 years, we see that they have 95 | always been on rise. It can safely be assumed that unless there is a 96 | groundbreaking change in the process of how Linux is developed, these 97 | vulnerabilities will continue to show up. 98 | 99 | #+NAME: fig:cvss-distribution 100 | #+CAPTION: Relative distribution of Common Vulnerability Score (v2.0) for past 10 years of Linux kernel CVEs. 101 | [[./images/cvss-distribution.pdf]] 102 | 103 | So, what can be done to make Linux more secure, beyond fixing the 104 | vulnerabilities as they are found? To answer this question, we take a step back 105 | and notice exactly what a vulnerability is. According to RFC2828 106 | cite:RFC2828I29:online, a vulnerability is 107 | 108 | #+LATEX: \textit{ 109 | #+BEGIN_QUOTE 110 | A flaw or weakness in a system's design, implementation, or 111 | operation and management that could be exploited to violate the system's 112 | security policy. 113 | #+END_QUOTE 114 | #+LATEX: } 115 | 116 | Being exploitable is what differentiates vulnerabilities from other software 117 | bugs. /Proactive defenses/ prevent the exploitation of known kind of 118 | vulnerabilities, thus rendering them harmless from a security standpoint. 119 | 120 | Something important to note here that CVEs are assigned to bugs that may or may 121 | not be exploitable. The rationale behind this is based on the fact that whether 122 | or not a bug is exploitable (and thus has security related consequences in real 123 | world) is dependent on environment and configuration. Given that there are huge 124 | number of permutations in which a Linux system can be configured, it is 125 | extremely difficult to predict if a bug can be exploited or not. 126 | 127 | ** Importance of this thesis 128 | 129 | A large number of proactive defenses have been proposed both in research 130 | community and industry. /The PaX project/ cite:Homepage39:online, first launched 131 | in the year 2000, hardens Linux against majority of memory corruption bugs 132 | discussed in Chapter [[Vulnerabilities and Defenses]]. /grsecurity/ provides 133 | defenses against some memory corruption vulnerabilities, a Role Based Access 134 | Control (RBAC) system and strict policies for access control in user-space. Over 135 | the years, The PaX Team and grsecurity have teamed up to maintain patches for 136 | stable version of Linux which includes defenses from both projects. Since April 137 | 2017, PaX/gesecurity patches are only available to paying customers of Open 138 | Source Security, Inc. 139 | 140 | Research community has also produced countless research papers targeted to 141 | specific kinds of vulnerabilities and attacks with varied amount of success in 142 | terms of industry adoption, performance and security coverage. 143 | 144 | This thesis tries to bring together the ideas from research community and 145 | industry to present a coherent view of the current state of the art defenses and 146 | techniques. It tries to compare security coverage and guarantees along with 147 | their performance to understand the practical usability of these defenses. 148 | 149 | It also includes a quantitative survey of security vulnerabilities reported 150 | against Linux kernel in past decade and categorizes them into various classes 151 | and sub-classes based on identifiable patterns in them. Figure 152 | [[fig:distribution-of-types]] shows the relative number of vulnerabilities of 153 | different types that we identified. Each of these vulnerabilities are discussed 154 | in detail in Chapter 3. The final goal of this thesis is to analyze which of 155 | these classes do not have efficient and practical proactive defenses in use 156 | today. 157 | 158 | #+NAME: fig:distribution-of-types 159 | #+CAPTION: Relative occurrences of different types of vulnerabilities 160 | [[./images/vulns-distro.png]] 161 | 162 | ** Thesis structure 163 | 164 | This thesis is organized as follows: 165 | 166 | - Chapter 2 provides background for relevant topics covered in this thesis. 167 | - Chapter 3 provides detailed overview of different classes of vulnerabilities, 168 | their sub-types, how can they be exploited and lists all their defenses. 169 | - Chapter 4 describes attack strategies and defenses of 170 | Return-Oriented-Programming attacks, which are based on multiple types of 171 | vulnerabilities that are discussed in Chapter 3. 172 | - Chapter 5 concludes this thesis 173 | 174 | * Background 175 | 176 | ** What is a CVE? 177 | 178 | Common Vulnerabilities and Exposures (CVE) is a central database of publicly 179 | known cyber-security vulnerabilities cite:CVECommo56:online. Unique identifiers 180 | for each vulnerability is assigned by a CVE Numbering Authority (CNA), 181 | organizations authorized to identify and assign CVE IDs to vulnerabilities, and 182 | published by the primary CNA, The MITRE Corporation. To request a CVE number, 183 | one needs to contact one of the CNAs along with the bug report and other 184 | relevant information related to fixes. The MITRE Corporation publishes a list of 185 | CVEs on the CVE Website cite:CVELi79:online after it has been disclosed and 186 | fixed. To prevent disclosing a vulnerability before it has been fixed, The MITRE 187 | Corporations coordinates with the original projects on the release date. 188 | 189 | For Linux kernel, security fixes are often coordinated among the major 190 | distributions like RedHat, Debian, OpenSUSE etc. and the vulnerability is 191 | published on the CVE Website only after the relevant security patches have been 192 | made available. 193 | 194 | Common Vulnerability Scoring System (CVSS) is an open industry standard 195 | cite:NVDCVSS22:online for scoring vulnerabilities based on factors like access 196 | complexity, access vector, authentication requirements and impact on 197 | confidentiality, availability and integrity. 198 | 199 | ** What is a Kernel? 200 | 201 | #+NAME: fig:image 202 | #+ATTR_LATEX: :width 0.6\textwidth 203 | #+CAPTION: An Operating System Kernel 204 | [[./images/kernel.png]] 205 | 206 | A kernel is a system software that manages hardware and facilitate its access to 207 | application software. Linux is an operating system kernel written in C. The code 208 | for kernel is loaded in a special memory area called /kernel-space/ and is 209 | mediated through support of privileges from hardware. Loading the kernel in a 210 | privileged space prevents it from being overwritten by other programs. A kernel 211 | provides an abstraction layer over hardware functionalities through /system 212 | calls/. 213 | 214 | Linux is a monolithic kernel, which means everything runs in the same address 215 | space for performance reasons. Microkernels, run only minimally required 216 | services in kernel space and the rest of the services run in a separate address 217 | space for non-privileged processes. This makes Microkernels lean reducing their 218 | startup time and the size of the computing base that needs to be trusted. 219 | 220 | #+NAME: fig:privilege-rings 221 | #+ATTR_LATEX: :width 0.5\textwidth 222 | #+CAPTION: Privilege rings in x86 architecture. 223 | [[./images/privilege-rings.png]] 224 | 225 | Privilege rings are heirarchial In x86 systems, there are four privilege rings from 0-3 with 0 being the most 226 | privielged and 3 being the least privileged ring (see fig [[fig:privilege-rings]] 227 | ). Linux however uses only two of these rings, ring 0 for kernel (also called as 228 | supervisor mode) and ring 3 for application software. 229 | 230 | *** Virtual Memory 231 | 232 | Virtual Memory is a technique used by modern operating systems for memory 233 | management that presents a large contiguous range of (virtual) address space to 234 | an application. Modern hardware include an /address translation unit/ (a.k.a 235 | /Memory Management Unit/ (MMU)) which automatically translates virtual addresses 236 | (corresponding to location in virtual memory area) to physical addresses 237 | (corresponding to actual address in hardware) in the CPU. The range of Virtual 238 | Memory Area (VMA) can exceed the capacity of the physical memory, which allows 239 | application to address more memory than the physical capacity. 240 | 241 | #+NAME: fig:vma 242 | #+ATTR_LATEX: :width 0.5\textwidth 243 | #+CAPTION[Virtual Memory]: Virtual Memory Area. The green regions are portions of VMA that are mapped to physical memory. The red regions denote the physical memory that belong to other processes and are not-accessible to current process. The remaining grey regions in VMA denote the memory regions that are not currently in physical memory and are either present on the disk or empty. 244 | [[./images/vma.png]] 245 | 246 | *** Memory Management and Paging in Linux 247 | 248 | Paging is a mechanism that translates a linear memory address to a physical 249 | memory address. Entire memory of an operating system is divided into small 250 | chunks, which makes it easy to addresses them. These chunks are called 251 | /pages/. In Linux, pages are commonly 4Kb in size, however, /huge pages/ are 252 | bigger in size and can be either 4Mb or 1Gb in size. 253 | 254 | Each page has an associated metadata, which includes information about the 255 | current status of the page, if the page is currently in the memory or is it 256 | swapped to disk, the current permission level etc. 257 | 258 | *** Memory Allocators in Linux 259 | 260 | Some portion of the RAM is permanently reserved for kernel to use and stores 261 | both the kernel code and the static kernel data structures. The remaining part 262 | is called dynamic memory and is managed and allocated by kernel to user-space 263 | and kernel-space processes. 264 | 265 | **** Zone Allocators 266 | 267 | The /zone page frame allocator/ takes care of memory allocation requests for 268 | groups of contiguous page frames. /Zones/ are specific regions of physical 269 | memory allocated for specific purposes, for example ~ZONE_DMA~ is for direct 270 | memory access, ~ZONE_HIGHMEM~ is used for higher range in memory, ~ZONE_NORMAL~ 271 | is used for other normal requests. Each zone also has a /per-CPU page frame 272 | cache/ that is a cache of single pages for frequent use. 273 | 274 | **** Buddy Allocators 275 | 276 | Inside each zone, /buddy allocator/ manages individual pages. Buddy allocator 277 | handles requests for contiguous page frames grouped into sizes of 1, 2, 4, 8, 278 | 16, 32, 64, 128, 256, 512 and 1024 contiguous pages. These pages have a 279 | contiguous linear address but can possible be fragmented in physical 280 | memory. Buddy allocators prevent fragmentation of linear addresses and are 281 | efficient as they deal with only page-sized chunks of memory. 282 | 283 | **** Slab Allocators 284 | 285 | While buddy allocators are efficient as they deal with only large chunks of 286 | memory, it is quite wasteful to request an entire page to store only a few 287 | bytes. Slab allocators act as memory caches with reserved pages based on the 288 | type of data to be stored, resulting in very fast memory allocations. 289 | 290 | Various parts of kernel tend to request a similar sized chunk of memory very 291 | frequently. Instead of un-allocating those memory regions, Slab allocator 292 | re-uses the free'd memory region for next request, essentially recycling the 293 | memory region. This results in much faster memory allocation as memory region is 294 | never de-allocated and re-allocated. 295 | 296 | Linux includes three Slab allocators: 297 | 298 | - *SLOB allocator*: This is the first type of Slab allocator, built with focus 299 | on compact memory storage 300 | - *SLAB allocator*: This allocator is confusingly also named as SLAB and is 301 | built with cache-friendliness in mind by aligning objects to cache-boundaries 302 | - *SLUB allocators*: This is newest type of Slab allocator and is built with 303 | focus on simple instruction counts, better support for debugging and 304 | defragmentation 305 | 306 | * Vulnerabilities and Defenses 307 | 308 | #+BEGIN_LaTeX 309 | \todo[inline]{- How were the categories identified? \newline 310 | - Distribution and number of vulns in each class? \newline 311 | - Source of CVEs, Papers, Patches?} 312 | #+END_LaTeX 313 | 314 | To study the vulnerabilities, a list of all the CVEs reported against Linux 315 | Kernel was collected from CVE Details website cite:CVEsecur92:online which 316 | includes CVSS score along with each CVE and it's report. 317 | 318 | A total of 1109 vulnerabilities were collected and studied as a part of this 319 | study. Fig [[fig:categorization]] presents the categorization of vulnerabilities 320 | into classes and sub-classes. Here is a brief introduction of all the classes: 321 | 322 | 323 | #+CAPTION: No. of CVEs reported in each of the categories. 324 | #+NAME: table:all-vulns 325 | #+ATTR_LATEX: :align |l|p{4cm}|p{2.5cm}|p{2cm}| 326 | |--------------------------+-------------------------+---------------+--------------| 327 | | *Vulnerability Class* | *Type* | *No. of CVEs* | *% of Total* | 328 | |--------------------------+-------------------------+---------------+--------------| 329 | | Un-initialized Data | | 128 | 11.54% | 330 | |--------------------------+-------------------------+---------------+--------------| 331 | | Use-after-free | | 47 | 4.24% | 332 | |--------------------------+-------------------------+---------------+--------------| 333 | | Bounds Check | Heap Overflow | 87 | 7.84% | 334 | | | Stack Overflow | 30 | 2.71% | 335 | | | Buffer Over-read | 28 | 2.52% | 336 | | | Integer Overflow | 57 | 5.14% | 337 | | | Refcount Overflow | 11 | 0.99% | 338 | | | Integer Underflow | 10 | 0.90% | 339 | | | Integer Signedness | 14 | 1.26% | 340 | | | Array Index Errors | 19 | 1.71% | 341 | |--------------------------+-------------------------+---------------+--------------| 342 | | Null Derference | | 149 | 13.44% | 343 | |--------------------------+-------------------------+---------------+--------------| 344 | | Format String | | 3 | 0.27% | 345 | |--------------------------+-------------------------+---------------+--------------| 346 | | Missing Permission Check | | 133 | 11.99% | 347 | |--------------------------+-------------------------+---------------+--------------| 348 | | Race Conditions | | 56 | 5.05% | 349 | |--------------------------+-------------------------+---------------+--------------| 350 | | | Infinite Loop | 12 | 1.08% | 351 | | | Memory Leak | 17 | 1.53% | 352 | | | Divide-by-zero | 10 | 0.90% | 353 | | Miscelleanous | Cryptography | 8 | 0.72% | 354 | | | Length Calculation Bugs | 19 | 1.71% | 355 | | | Other | 224 | 20.19% | 356 | |--------------------------+-------------------------+---------------+--------------| 357 | | Total | | 1109 | | 358 | |--------------------------+-------------------------+---------------+--------------| 359 | 360 | #+CAPTION: Categorization of Vulnerabilities 361 | #+NAME: fig:categorization 362 | #+ATTR_LATEX: :placement [p] 363 | [[./images/categorization-of-vulns.png]] 364 | 365 | - *Un-initialized data* vulnerabilities are a result of missing initialization 366 | of data structures before they are exposed outside of kernel-space memory. 367 | 368 | - *Use-after-free* vulnerabilities happen when there exists a reference to a 369 | freed memory region which can be exploited by placing a valid new object at 370 | the same memory region. 371 | 372 | - *Bounds* vulnerabilities happen because of missing or wrong bounds checks on 373 | data moved between kernel-space and user-space memory. It also includes wrong 374 | length calculations and array index errors vulnerabilities. 375 | 376 | - *Null derference* vulnerabilities are result of NULL pointers being 377 | dereferenced before null-check in kernel. 378 | 379 | - *Format String* vulnerabilities happen when un-trusted format strings find 380 | their way into string formatting functions leading to information disclosure. 381 | 382 | - *Race conditions* occur because of poor handling of locks around critical 383 | sections of memory when accessed by multiple threads or processes. 384 | 385 | - *Miscellaneous* includes all the other vulnerabilities that do not fall into 386 | any of the categories mentioned above and while these do have some 387 | commonality in their types, no proactive defenses are known for these. 388 | 389 | 390 | Following sections explore each of the above mentioned classes, their 391 | exploitation methodology and existing defenses against them. Defenses were 392 | collected from the last public release of PaX/grsecurity (April 2017), 393 | proactive defenses added to Linux in past few years and research papers 394 | published in past 6 years. 395 | 396 | ** Un-Initialized Data 397 | #+BEGIN_LATEX 398 | \todo[inline]{- What does un-initialized data mean? Why are they a security concern? \newline 399 | - How do they happen? (compiler added padding, missed initializations) \newline 400 | - What are the consequences of un-initialized data?(info leaks) \newline 401 | - In what ways can they be exploited?(Predictable memory allocations) \newline 402 | - How to identify and fix?(static analysis to find, binary/compiler instrumentation to fix) \newline 403 | - Are they a solved problem? No, solutions that cover all data structures have high overheads.} 404 | #+END_LATEX 405 | 406 | An un-initialized object can leak sensitive information from kernel memory when 407 | it's moved across privilege boundaries like user-space memory, network, 408 | filesystem etc. This happens when a region of memory allocated to an object 409 | contains sensitive information and because of the missing initialization, the 410 | sensitive data continues to persist in the object. Such object, when copied to 411 | user-space memory for example, leaks information previously stored in kernel 412 | memory. Missing initialization of function pointers can cause NULL 413 | pointer dereference leading to OOPS[fn::OOPS is a Linux terminilogy for 414 | deviation from normal behavior of the kernel. It may result in a Kernel panic 415 | or crash but can also result in continued operation with reduced 416 | reliability. OOPS often results in an error log which can help administrators 417 | debug the actual cause of crash.] (CVE-2011-2184), privilege escalation 418 | (CVE-2009-2692, CVE-2008-2812) and other potential attacks discussed in section 419 | [[Null Dereference]]. 420 | 421 | A total 128 vulnerabilities of this kind were reported against Linux in past 10 422 | years, which accounts for 11.54% of total vulnerabilities. Information obtained 423 | by exploiting them is useful in building attacks that break other defenses like 424 | Address Space Layout Randomization (ASLR). ASLR is a technique used to randomize 425 | the base address of various sections in the Kernel memory in order to thwart the 426 | attacks that re-use the code segments by indirect call transfers. They are 427 | called code-reuse attacks or return-oriented programming attacks and are 428 | discussed in section [[Return-Oriented Programming attacks]]. 429 | 430 | Another source of un-initialized data vulnerabilities is padding added to /word/ 431 | align [fn::A /word/ length is a specific property of CPUs and is defined by it's 432 | architecture. Majority of the registers in a CPU can hold data of /word/ size. ] 433 | the data structures at compile time. This padding is often[fn::This varies from 434 | compiler-to-compiler and depends on data structure and type of 435 | initialization(e.g. initialized with constants or variables).] un-initialized 436 | memory and is out of programmer's control since they are added at compile time. 437 | 438 | *** Mitigation Techniques 439 | 440 | There are several defense techniques proposed to defend against un-initialized 441 | data related attacks. Table [[table:null-dereference]] provides a brief summary of 442 | all the defense techniques ordered by the year they were first published in 443 | public domain. Each of the defenses are then mentioned in detail along with 444 | their defense strategy, performance overheads and coverage. 445 | 446 | #+NAME: table:null-dereference 447 | #+CAPTION: Mitigation Techniques for Un-initialized data errors. 448 | #+ATTR_LATEX: :align |p{3.5cm}|p{1cm}|p{5cm}|p{3cm}|p{1.5cm}| 449 | |------------------------------+------+----------------------------------------------------------+---------------------------------------------------+------------| 450 | | Name | Year | Coverage | Bypassable | Cost | 451 | |------------------------------+------+----------------------------------------------------------+---------------------------------------------------+------------| 452 | | Chow et. al cite:Chow | 2005 | pages un-used for fixed time | yes | N/A | 453 | | ~PAX_MEMORY_STACKLEAK~ | 2011 | Kernel stack leakages | yes, in current system call | 2.6-200% | 454 | | ~PAX_MEMORY_STRUCTLEAK~ | 2013 | structures with ~__user~ fields | no | < 1% | 455 | | ~PAX_MEMORY_SANITIZE~ | 2013 | memory allocated by slab allocators & buddy allocator | no | 9-12% | 456 | | Peiro et. al. cite:Peiro2014 | 2014 | Kernel stack, single function boundary, compiler padding | yes, with 0.8% probability | N/A | 457 | | Unisan cite:Lu2016 | 2016 | security sensitive un-initialized data | no | 1.5% | 458 | | Memory Sanitization in Linux | 2017 | memory allocated by slab allocators | yes, by large memory allocated by buddy allocator | 3-20% | 459 | | SafeInit cite:milburn2017 | 2017 | security sensitive un-initialized data | no | -3% - 5.9% | 460 | |------------------------------+------+----------------------------------------------------------+---------------------------------------------------+------------| 461 | 462 | **** PaX 463 | 464 | *PaX* patchsets are a collection of security enhancements to Linux that defend 465 | against several vulnerability classes that lead to memory corruption. 466 | 467 | ***** PAX MEMORY STACKLEAK 468 | is a GCC plugin from PaX which clears the kernel stack before a function returns 469 | to the user-space. While this can prevent leakages from any previous system 470 | call, data from current system call will still leak. According to the analysis 471 | performed by Lu. et. al. cite:Lu2016, its performance overhead is high and can 472 | rage from 2.6% to 200% depending on the workload. 473 | 474 | ***** PAX MEMORY STRUCTLEAK 475 | is a GCC plugin, also a part of PaX, which zero initializes local structures 476 | that can be copied to the user-space in future as a preventive measure for 477 | missing initializations. The performance impact of this is less as compared to 478 | ~PAX_MEMORY_STACKLEAK~ but it offers less coverage. The fields to be 479 | zero-initialized are determined based of ~__user~ annotations of the 480 | fields. However, ~__uesr~ doesn't cover all the structures that will be copied 481 | to user-space and isn't explicitly used only for the structures that will be 482 | copied to user-space in future. It also doesn't recognize all the different 483 | types of initializers leading to some false positives. 484 | 485 | ***** PAX MEMORY SANITIZE 486 | erases memory pages (allocated using /buddy allocator/) and slab objects 487 | (allocated using /slab allocator/) as soon as they are freed by writing NULL 488 | values to them. This technique is called *memory sanitization*, by erasing the 489 | memory pages when they are /freed/, the lifetime of sensitive data can be 490 | reduced preventing future leaks. For better performance, one can disable erasing 491 | of Slab objects at the cost of lesser coverage. 492 | 493 | **** Protections added to Linux 494 | 495 | ***** Memory Sanitization 496 | Linux v4.6 gained partial support for memory sanitization, a port of 497 | ~PAX_MEMORY_SANITIZE~. Sanitization happens at both slab allocator level and 498 | page allocator level by writing a magic value to the freed regions. It includes 499 | an additional /sanity check/ which would verify that nothing was written to the 500 | memory by checking for magic value during allocation time. Because of the high 501 | performance overhead, this feature is disabled by default. 502 | 503 | ***** STRUCTLEAK 504 | ~PAX_MEMORY_STRUCTLEAK~ GCC plugin was ported over to Linux 4.11 which 505 | zero-initializes all the local variables containing ~__user~ annotations. 506 | ~GCC_PLUGIN_STRUCTLEAK~ is the configuration option that enables this feature. 507 | 508 | Expanding on this coverage is ~GCC_PLUGIN_STRUCTLEAK_BYREF_ALL~ in Linux 4.14, 509 | which zero-initializes all the local variables which are passed by reference. 510 | 511 | **** Proposed Defenses in Research 512 | 513 | One of the oldest technique to detect un-initialized data at compile-time is 514 | static analysis of the source code. Peiro et. al. cite:Peiro2014 use taint 515 | analysis to track memory regions from source (i.e. allocation) to their sink 516 | (e.g. copy to user-space, sent over network) to make sure that no un-initialized 517 | data structures leak. Their implementation can only detect allocations on the 518 | stack and can only track memory within a single function boundary. 519 | 520 | Lu et. al. cite:Lu2016 proposed UniSan to detect unsafe allocations and 521 | automatically initialize variables using binary instrumentation 522 | techniques. UniSan is built as a tool that takes LLVM IR (intermediate 523 | representation i.e. bitcode files) as input and returns instrumented 524 | binary. Because initializing all variables would incur a high performance 525 | overhead, it uses static data flow analysis to initialize only those variables 526 | which can leak to user-space. 527 | 528 | Milburn et. al. cite:Milburn2017 proposed SafeInit, as a plugin to LLVM compiler 529 | toolchain, which initializes all variables unconditionally and then optimizes 530 | their code to remove initialization for certain variables that are never used in 531 | any context that they can be exposed. They claim to fix a wider range of 532 | un-initialized data vulnerabilities than UniSan. 533 | 534 | Chow et. al. cite:Chow proposed a strategy in year 2005 called /secure 535 | de-allocation/, which involves writing /zero/ values to the memory pages after 536 | they are freed. Kernel pages are marked /dirty/ when they are freed and can only 537 | be used after they have been cleaned (zeroed) by a long running kernel daemon 538 | thread. This thread periodically scans dirty pages and zeroes them if they have 539 | been dirty for a certain fixed time. A downside to this scheme is that it 540 | doesn't seem to cover slub allocators like SLUB, SLAB or SLOB which can re-use 541 | the same pages for different objects without freeing them. 542 | 543 | One thing to note here is that all the memory sanitization techniques mentioned 544 | above, that sanitize memory region when they are freed, do not provide absolute 545 | safety against information disclosure. Memory leaks when the memory is never 546 | freed cannot be covered by these methods in long running daemon processes for 547 | example. 548 | 549 | *** Analysis 550 | 551 | Un-initialized data vulnerabilities make up for 11.54% of all the 552 | vulnerabilities found (see Table [[table:all-vulns]]). Defense mechanisms from 553 | PaX/grsecurity (~PAX_STACKLEAK~, ~PAX_STRUCTLEAK~, ~PAX_MEMORY_SANITIZE~) have 554 | very high overheads as mentioned in Table 555 | [[table:null-dereference]]. ~PAX_STACKLEAK~ also doesn't prevent from leaks in the 556 | current system call as it clears the stack for all previous system calls. Linux 557 | gained support for memory sanitization, a port of ~PAX_MEMORY_SANITIZE~, but it 558 | also suffers from same problem of high performance overhead and is thus 559 | disabled by default. 560 | 561 | Research papers like UniSan cite:Lu2016 and SafeInit cite:milburn2017 can 562 | achieve acceptable performance and show promising guarantees. They 563 | zero-initialize only the data structures that are ever exposed outside of 564 | kernel. According to their analysis, they are able prevent all the 565 | un-initialized data vulnerabilities reported against Linux from being 566 | exploited. Both of them can also detect leaks caused by paddings added by 567 | compiler to optimize the size of data structures by aligning them with processor 568 | /word length/. These paddings can also reveal sensitive information and is 569 | beyond the control of a programmer since they are added during compile 570 | time. 571 | 572 | ** Use-After-Free 573 | 574 | #+BEGIN_LATEX 575 | \todo[inline]{- What is a use-after-free vuln? \newline 576 | - How can UAF be exploited? 3 steps involved in exploitation, common techniques for exploitation \newline 577 | - What defense mechanisms exist for prevention of each of 3 steps 578 | + invalidate pointers when objects are freed \newline 579 | + randomize placement of new objects \newline 580 | + prevent de-referencing of pointers to freed objects. 581 | - Is it a solved problem? No, most of the solutions only prevent refcount overflow for step 1.} 582 | #+END_LATEX 583 | 584 | Use-after-free (UAF) vulnerability occurs when an object in memory is accessed 585 | after it has been destroyed (freed). These are also termed as /temporal memory 586 | errors/ or /dangling pointers/ [fn::A pointer pointing to a deleted object is 587 | called /dangling pointer/.]. Most of the UAF vulnerabilities target heap 588 | allocations as they are managed manually, but sometimes a local variable can 589 | escape from local scope if they are assigned to a global pointer causing a 590 | temporal memory error after the function returns and stack frame is 591 | cleared. Stack based UAF vulnerabilities haven't been reported for Linux in past 592 | 10 years. 593 | 594 | A total of 47 UAF vulnerabilities were reported against Linux in past 10 years 595 | which accounts for 4.24% of total vulnerabilities reported. /Double free/ 596 | vulnerabilities are a special case of UAF when the memory region is freed twice 597 | leading to panic (denial of service) (CVE-2012-1853, CVE-2010-3080). 598 | 599 | Most cases of UAF vulnerabilities end up with a Kernel OOPS or panic as the 600 | pointer being used often points to invalid memory. But, in some cases, the 601 | pointer could be valid if a new object was allocated on the same memory region 602 | the pointer points to. This can be used to point a legitimate pointer to an 603 | attacker controlled object. Exploiting a UAF vulnerability commonly involves 604 | three steps: 605 | 606 | 1. An object is freed while a pointer to it exists, 607 | 2. Second object is allocated on the memory pointed by the pointer in (1), 608 | 3. Kernel de-references the pointer to get attacker controlled data, 609 | 610 | **** Step 1 611 | 612 | Executing all these three steps in correct order is important for a successful 613 | exploitation. CVE-2016-0728 cite:CVECVE2084:online allowed local users to gain 614 | privileges by controlling a kernel keyring object due to use-after-free 615 | vulnerability. This particular vulnerability was a result of reference counter 616 | overflow, which allowed the object to be freed when its reference counter 617 | reached zero. Reference counters are implemented as integers in Linux, which 618 | makes them vulnerable to overflows [[Integer defects]]. A total of 11 reference 619 | counter related vulnerabilities were reported in our analysis of past 10 years. 620 | 621 | A mis-management of reference count causes an object to be freed, even when 622 | there are valid references to the object(CVE-2009-3624, CVE-2014-2851). Bugs in 623 | the memory management code which allows objects to be freed pre-maturely is the 624 | single largest cause of UAF vulnerabilities. Often this happens due to corner 625 | cases and un-common errors which are not handled properly. 626 | 627 | **** Step 2 628 | 629 | Linux uses /freelist/ [fn::Freelists are linked lists of pre-allocated memory 630 | regions for object(s) of a particular size for faster allocation.] based memory 631 | allocators for objects called /Slab allocators/. There are three Slab 632 | allocators in Linux , SLAB, SLUB and SLOB. Each Slab allocator is built upon a 633 | different philosophy and use-case, but they are often predictable when 634 | allocating objects. By allocating multiple objects of same size, an attacker 635 | can reliably control the allocation of one of the objects over the same memory 636 | region as the previously freed object cite:Xu:2015:CEU:2810103.2813637. This is 637 | *step 2* in the attack. 638 | 639 | **** Step 3 640 | 641 | After Step 1 and 2, the setup for UAF vulnerability is complete and the only 642 | thing remaining is the final execution. When the kernel de-references the 643 | pointer, which now is pointing to an attacker controlled object, it 644 | inadvertently gets the attack controlled data. If the object consisted of 645 | function pointers, the attacker can replace entire functions to execute 646 | arbitrary code. 647 | 648 | *** Mitigation Techniques 649 | 650 | To systematize the study of mitigation techniques, they are grouped under the 651 | step that they try to prevent in the attack scenario mentioned in previous 652 | section. Table [[table:uaf]] provides a summary of all the defensive techniques 653 | ordered by the year that they were first published. 654 | 655 | #+NAME: table:uaf 656 | #+CAPTION: Mitigation Techniques for Use-after-free vulnerabilities. 657 | #+ATTR_LATEX: :align |p{3cm}|p{0.7cm}|p{0.5cm}|p{3cm}|p{5cm}|p{1cm}| 658 | |---------------------------+------+------+-----------------------+------------------------------------+-------------------------------------| 659 | | Name | Year | Step | Coverage | Bypassable | Cost | 660 | |---------------------------+------+------+-----------------------+------------------------------------+-------------------------------------| 661 | | KASAN | - | 3 | All memory regions | yes, re-allocated memory | n/a[fn::KASAN is a debugging tool.] | 662 | | TaintTrace cite:Cheng2006 | 2006 | 3 | All memory regions | no | 5.53% | 663 | | DieHard cite:Berger2007 | 2007 | 2 | Heap allocations | yes, probabilistic protection only | ~6% | 664 | | CETS cite:Nagarakatte2010 | 2010 | 3 | All memory regions | yes, re-allocated memory | ~48% | 665 | | ~PAX_REFCOUNT~ | 2015 | 1 | all ~atomic_t~ | no | ~0% | 666 | | Randomized Freelists | 2016 | 3 | Slab Allocators | yes, heap spraying attacks | ~0% | 667 | | ~refcount_t~, Linux | 2017 | 1 | only objects using it | no | ~0% | 668 | | Oscar cite:Dang2017 | 2017 | 2-3 | All memory regions | no | 4% | 669 | |---------------------------+------+------+-----------------------+------------------------------------+-------------------------------------| 670 | 671 | 672 | **** Prevention of Step 1 673 | 674 | To prevent *step 1*, pointers should not be allowed to point to freed 675 | objects. In other words, all references to a freed object should invalidated. In 676 | Kernel, often refcount[fn::Short for /reference count/, often used verbatim in 677 | the source code] (mis)calculations can provide an easy way to free an object 678 | which is still in use. 679 | 680 | ~PAX_REFCOUNT~, a part of PaX, adds checks around increment of ~atomic_t~ data 681 | type in Linux such that its value can never overflow beyond ~INT_MAX~ [fn::INT 682 | MAX is the theoretical maximum value of an integer data type in C, it is 683 | determined by the processor architecture]. Other uses of ~atomic\_t~, which are 684 | not related to reference counts, are renamed to ~atomic\_unchecked\_t~ 685 | throughout the source. This feature was ported over to Linux in v4.11 to protect 686 | against reference counters overflows, however instead of preventing overflows in 687 | all ~atomic_t~ types, a new type ~refcount_t~ was added to Linux and all the 688 | reference counters will eventually be ported to use this type. 689 | 690 | **** Prevention of Step 2 691 | 692 | To prevent *step 2*, an adversary should not be allowed to reliably predict 693 | memory allocations. Since Linux v4.8, freelists in the Slab allocators like 694 | SLAB, SLUB are randomized[fn::i.e. objects allocated do not follow a simple 695 | pattern of allocated-first-free-block] making it hard to reliably predict the 696 | memory allocations. However, by repeated memory allocations of object of one 697 | size, it will ultimately result in the previously freed object memory being 698 | reused, making the attack only slightly more difficult. 699 | 700 | DieHard by Berger et. al. cite:Berger2007 emulates the semantics of a 701 | probabilistic infinite virtual memory[fn::Having an infinite amount of memory 702 | would mean a memory region would never have to be reused thus thwarting UAF.] 703 | using a bitmap based fully-randomized memory manager. It uses over-sized heap 704 | allocations and randomization to pick free memory regions for new 705 | allocations. DieHard was motivated by the idea of preventing memory errors. 706 | Novark et. al. extended this idea to provide better security and performance 707 | and proposed DieHarder cite:Novark2010, which is also a probabilistic memory 708 | allocator designed with security in mind. DieHarder uses sparse pages layout to 709 | randomly allocate pages in virtual memory, provides support for ASLR by 710 | randomizing the address of small object pages and fills freed memory with random 711 | data to prevent it's misuse. 712 | 713 | **** Prevention of Step 3 714 | 715 | To prevent *step 3*, code paths that lead to dangling pointers should be 716 | avoided. Kernel Address Sanitizer (KASAN) is GCC plugin that tracks dynamic 717 | memory allocations in Kernel using compiler instrumentation techniques to 718 | prevent pointers to invalid memory regions. KASAN uses /shadow memory/ [fn::A 719 | seperate managed region of memory that is protected with other mechanisms to 720 | prevent un-authorized write.] to track the usage of each byte and can detect 721 | its unsafe usage. It incurs a significant performance and memory overhead. 722 | However, it can be used to find use-after-free and out-of-bounds 723 | read[fn::Out-of-bounds bugs happen when the length of buffer being read-from 724 | doesn't match the length of the data being-written to.] bugs during testing, 725 | which can then be fixed. 726 | 727 | 728 | ***** Shadow Memory 729 | has also been used in previous works like TaintTrace by Cheng 730 | et. al. cite:Cheng2006 and Compiler Enforced Temporal Safety for C (CETS) by 731 | Nagarkatte et. al. cite:Nagarakatte2010 to track memory allocations in a tree, 732 | hash table or trie. A downside of tracking memory regions is that they can only 733 | detect un-safe usage of freed memory and not the memory that has been 734 | re-allocated. 735 | 736 | CETS by Nagarkatte et. al. cite:Nagarakatte2010 uses shadow memory to track 737 | information about the validity of each pointer. By associating this information 738 | with pointer instead of the memory regions, a pointer can be invalidated when 739 | the memory is re-allocated by changing the value of a flag. This method is 740 | called lock-and-key mechanism where the pointer is a given a key to open the 741 | lock in the memory region. When the memory is re-allocated, the lock changes and 742 | the pointer can no longer access it. CETS can provide complete temporal safety, 743 | but only if complete spatial safety[fn::Spatial memory errors happen when 744 | pointers become invalid by pointing to out-of-bounds objects due to array index 745 | errors or are overwritten using buffer-overflow techniques] is also guaranteed 746 | by some other mechanism. 747 | 748 | Oscar by Dang et. al. cite:Dang2017 uses permissions on shadow virtual pages to 749 | prevent danging pointer attacks. By using a shadow virtual page, each object is 750 | allocated it's own virtual page which is then destroyed when the object is 751 | freed. Oscar presents an improved model with lower performance and memory 752 | overheads compared to the works previous to it. 753 | 754 | *** Analysis 755 | 756 | Use-after-free vulnerabilities constitute for 4.24% of all the vulnerabilities 757 | along with around 1% of refcount overflow/mis-management related vulnerabilities 758 | which enable the first step in exploitation of a use-after-free 759 | vulnerability. By preventing reference counter overflows using ~refcount_t~ or 760 | ~PAX_REFCOUNT_~, it is possible to prevent about 11 (about 1% of all 761 | vulnerabilities) of the use-after-free vulnerabilities. Randomized Slab 762 | freelists do provide probabilistic defense against them by making it hard to 763 | predict the memory allocations from allocators, theoretically, it is possible to 764 | bypass them using heap-spraying attacks cite:Ding. 765 | 766 | Work done by Dang et. al in Oscar cite:Dang2017 and Cheng et. al. in TaintTrace 767 | cite:Cheng2006 shows possible methods to thwart all use-after-free 768 | vulnerabilities by tracking each byte of memory in shadow space for un-safe 769 | usage but their performance overheads (table [[table:uaf]]) are too high to be used 770 | in a production environment. Formalized fuzz testing (using a tool like 771 | syzkaller from Google cite:GitHubgo15:online) of Linux with these features 772 | before release or during development cycles would be the most ideal use-case of 773 | these techniques. 774 | 775 | ** Bounds Check 776 | 777 | #+BEGIN_LATEX 778 | \todo[inline]{- What is a bounds check related vulnerability? How do they happen? Why study each type separately? \newline 779 | - What is the difference between buffer overread and buffer overflow? Why are they important?} 780 | #+END_LATEX 781 | 782 | Any input that a software takes from outside its trusted domain should be 783 | validated. Except for data type, the simplest validation technique is length 784 | check -- input data should not be larger than the size of memory region it 785 | copied to. This is also true for any data that is read i.e. only the amount of 786 | memory required should be copied to the destination, anything extra could reveal 787 | sensitive information outside of trusted domains. The former vulnerability is 788 | called *buffer overflow* and the latter is called *buffer over-read*. Except for 789 | the source and sink of the data, these two vulnerabilities are similar in every 790 | aspect and are collectively addressed here as *bounds check* vulnerabilities. 791 | 792 | Depending on the region of memory the vulnerability corresponds to, like heap or 793 | stack, the effects of the overflow/over-read can vary and hence the mitigation 794 | technique. Hence, bounds check vulnerabilities are further categorized into 795 | three sub-categories: 796 | 797 | - Stack Overflow/Over-read 798 | - Heap Overflow/Over-read 799 | - Integer Defects 800 | 801 | #+NAME: fig:bounds-check 802 | #+CAPTION: Bounds Check vulnerabilities 803 | #+ATTR_LATEX: :placement [H] 804 | [[./images/bounds-check.png]] 805 | 806 | *** Stack Overflow 807 | 808 | #+BEGIN_LATEX 809 | \todo[inline]{ 810 | - What is stack overflow? How does it happen? \newline 811 | - What preventive measures exist to prevent stack overflow? \newline 812 | - canaries, but they are not enough for stack corruption \newline 813 | - PAX patches prevent un-equal sized copies, overflows in stack frame and stack pages \newline 814 | - Is it a solved problem? Not completely, no way to stop overwriting return addresses by dangling pointers. CFI can detect overwritten return address but would result in DOS. \newline 815 | - Intel MPX can help but is still new and not very performant. The changes required for it may never be adopted in kernel.} 816 | #+END_LATEX 817 | 818 | Stack overflow happens when a variable on the stack is written beyond it's 819 | bounds to neighboring memory region. Often, this is used to overwrite the return 820 | address at the bottom of the stack frame, so when the the function returns, 821 | control jumps to an attacker controlled location pointed by the value of the 822 | overwritten return address. These attacks are also called as /control flow 823 | hijacking/ attacks as it changes the usual flow of the program by re-directing 824 | it to a different location in memory. Data or variables which can change the 825 | control flow of a program are termed as /control data/. Apart from compromising 826 | the control flow, a stack overflow can also be used to inject code in the Kernel 827 | and then execute them. 828 | 829 | Stack overflow bugs can sometime overwrite beyond the current stack region to 830 | neighboring page. So, when an attacker is able to overflow a stack buffer, it 831 | can potentially corrupt the entire stack or even overwrite heap memory, which is 832 | generally allocated just below stack region. 833 | 834 | **** Mitigation Techniques 835 | 836 | #+CAPTION: Mitigation Techniques for Stack Overflows 837 | #+ATTR_LATEX: :align |p{5cm}|p{3cm}|p{4cm}|p{1cm}| 838 | |------------------------------------+-------------------------+----------------------------------------+------| 839 | | Name | Coverage | Bypassable | Cost | 840 | |------------------------------------+-------------------------+----------------------------------------+------| 841 | | Stack Canaries by GCC | Return address on stack | yes, direct write using a pointer | ~0% | 842 | | ~PAX_PAGEEXEC~ / ~PAX_SEGMEXEC~ | code injection | no | | 843 | | ~GRKERNSEC_KSTACKOVERFLOW~ | cross-page overflow | no | | 844 | | ~VMAP_STACK~, Linux | cross-page overflow | no | | 845 | | ~PAX_USERCOPY~ / Hardened Usercopy | all overflows | yes, to corrupt stack or current frame | | 846 | |------------------------------------+-------------------------+----------------------------------------+------| 847 | 848 | There are no known ways to completely prevent a buffer overflow at hardware 849 | level, or at programming language level. The best that can be done is to detect 850 | an overflow. Most widely used protection mechanism to detect buffer overflow is 851 | adding a random value called /stack cookie/ or /stack canary/ after the buffer 852 | that can potentially overflow and checking it's value when function 853 | returns. Since it increases the amount of memory used and incurs some 854 | performance overhead on every function return, it is often not added 855 | un-conditionally for every buffer in the stack frame. Generally, a stack canary 856 | is added only before the return address to prevent control flow hijacking 857 | attacks by overwriting the return address. 858 | 859 | To manage the tradeoffs between memory overheads and security, most common 860 | compilers (GCC and LLVM ) have options to enable overflow protection. GCC 861 | includes three options cite:Usingthe29:online : 862 | 863 | - ~-fstack-protector-all~: This adds a stack canary to all functions and thus 864 | has high memory overheads 865 | - ~-fstack-protector~: This adds a stack canary to all the functions that 866 | call ~alloca~ [fn::~alloca~ is used to allocate memory on stack which is 867 | automatically freed] and functions with buffers larger than 8 bytes. 868 | - ~-fstack-protector-strong~: This adds a stack canary to all the functions 869 | covered by ~-fstack-protector~, all functions that use a local variable 870 | or local register references, and all the functions that have local array 871 | definitions. 872 | 873 | Given that enough entropy [fn::Entropy is a measure of randomness and depends on 874 | the source and length of data.] is used for canaries that they cannot be 875 | de-anonymized [fn::Small values can be /guessed/ using brute force techniques in 876 | reasonable time-frames.], they can detect stack overflows. It is still possible 877 | to overwrite the return address by exploiting a dangling array pointer. Dangling 878 | array pointers are arrays on stack that can be made to point to any location by 879 | controlling it's index variable. 880 | 881 | ***** Data Execution Prevention (DEP) 882 | or W \oplus X (write xor execute) is a policy used to prevent any memory region 883 | from being marked writable and executable at the same time to prevent code 884 | injection attacks. A data region which contains attacker controlled data, if 885 | allowed to execute, could be used for code-injection attacks. Recent processors 886 | allow marking memory pages with a No eXecute (NX) bit which is used to 887 | implement W \oplus X policy by removing execute permissions from all data 888 | pages. ~PAX_PAGEEXEC~ and ~PAX_SEGMEXEC~ can emulate W \oplus X and NX 889 | respectively in older architectures that don't have native hardware support for 890 | it. Because they are implemented in software, they have higher performance 891 | overheads than DEP policy using NX support from hardware. 892 | 893 | ***** Guard Pages 894 | are commonly used to make sure any writes that cross the page boundary are 895 | trapped preventing overwrite of any neighboring data structure. Until recently, 896 | the stack region in kernel used to be directly mapped, i.e., the memory was 897 | virtually and physically contiguous. This meant that the guard pages would have 898 | to be mapped in the physical memory too making them very expensive[fn::Memory is 899 | scarce in kernel-space and guard page would waste one page of physical memory 900 | per stack page if the stack is directly mapped..]. In Linux v4.9, 901 | ~CONFIG_VMAP_STACK~ option was added to allow stack to be virtually mapped 902 | without any need for it to be physically contiguous, which allowed the use of 903 | guard pages to prevent overflows across page boundaries. This feature has been a 904 | part of grsecurity patches with a configuration option called 905 | ~GRSECURITY_KSTACKOVERFLOW~. 906 | 907 | ***** PaX USERCOPY 908 | is another feature from PaX which adds bounds checks to any data that is copied 909 | to and from the user-space. It modifies all the functions that copy data from 910 | user-space to verify that the data doesn't write past the stack to prevent 911 | overflows to heap. Depending on the architecture support for stack frame 912 | pointers, it can also prevent the writes past the current stack frame to prevent 913 | stack corruption attacks. 914 | 915 | ***** Hardware Based Techniques 916 | like /Memory Protection eXtensions/ (MPX) cite:Introduc76:online , like 917 | recently introduced by Intel, would allow software to specify pointer bounds 918 | with each memory allocation. Each de-reference of the pointer is then verified 919 | to be within these bounds by the hardware. An initial study by Oleksenko et. al 920 | cite:DBLP:Oleksenko shows promising results as compared to software based 921 | bounds checking mechanism. However, the current iteration of the implementation 922 | has poor support and buggy implementation. Since the software needs to provide 923 | bounds information with each pointer, it requires considerable amount of 924 | invasive change in the source code to support MPX. The performance impact, 925 | though better than software based solutions, is about 50% as per the studies 926 | done by Oleksenko et. al.cite:DBLP:Oleksenko. 927 | 928 | *** Heap Overflow 929 | 930 | #+BEGIN_LATEX 931 | \todo[inline]{- What is heap overflow? Why they need to be studied separately than stack? (Mostly because of manual memory management.) \newline 932 | - What is the main cause? (Un-trusted length values from input leading to copy of extra data from userspace) \newline 933 | - Can it be fully protected? (In objects allocated by Slab, yes, which consists of major regions of heap. For larger memory allocations, no!) \newline 934 | } 935 | #+END_LATEX 936 | 937 | Heap based buffer overflows are similar to stack overflows in mechanism, 938 | however, due to manual memory management in heap region, there exist different 939 | strategies to prevent heap overflows. Heap overflow can overwrite important 940 | data structures like function pointers, object metadata or other objects on the 941 | heap. 942 | 943 | Most objects are allocated on heap by Slab allocators like SLAB, SLUB and 944 | SLOB. These allocators store the metadata along with the objects in the kernel 945 | memory, placement of which can vary depending on the allocator. In most of the 946 | slab allocators, the metadata is stored along with the objects in adjacent 947 | memory regions for fast access and cleaner memory layout. 948 | 949 | A common technique to exploit buffer overflows is by providing incorrect length 950 | values to a function that copies data from user-space to kernel-space memory 951 | (CVE-2013-6381, CVE-2012-2119, CVE-2012-2136). This can also happen if 952 | validation code in-correctly determines the size of data due to wrong 953 | calculations, poor assumptions or other means. 954 | 955 | Similar to stack, heap overflows can also be used to inject code and be 956 | exploited by forcing the control flow to the address of injected code in the heap. 957 | 958 | **** Mitigation Techniques 959 | 960 | #+CAPTION: Mitigation Techniques for Heap Overflow 961 | #+ATTR_LATEX: :align |p{5cm}|p{3cm}|p{4cm}|p{1cm}| 962 | |------------------------------------+-------------------------+-----------------------------------+------| 963 | | Name | Coverage | Bypassable | Cost | 964 | |------------------------------------+-------------------------+-----------------------------------+------| 965 | | Stack Canaries by GCC | Return address on stack | yes, direct write using a pointer | ~0% | 966 | | PaX strict ~mprotect~ | W \oplus X | no | | 967 | | ~PAX_PAGEEXEC~ / ~PAX_SEGMEXEC~ | code injection | no | | 968 | | ~GRKERNSEC_KSTACKOVERFLOW~ | cross-page overflow | no | | 969 | | ~PAX_USERCOPY~ / Hardened Usercopy | all overflows | yes, non-slab allocations | | 970 | |------------------------------------+-------------------------+-----------------------------------+------| 971 | 972 | ***** PaX 973 | Code injection attacks can be prevented by W \oplus X policy over the heap 974 | region. Strict ~mprotect~ from PaX prevents any region of the memory which has 975 | been written to be marked executable in future by an ~mprotect~ system call. 976 | 977 | ~PAX_USERCOPY~ changes the behavior of functions that copy data to or from 978 | user-space to kernel space to check for object bounds on every copy 979 | operation. It adds checks for validity of kernel pointers to make sure that it 980 | points with-in address range of kernel memory, that it is not NULL, and that it 981 | doesn't point to a zero-length memory allocation. If the pointer points to a 982 | memory region managed by one of the Slab allocators, it also checks if the size 983 | of the data being copied is same the size of the object. If the pointer doesn't 984 | point to a slab allocated memory region, it checks that the data doesn't cross 985 | page or /compound page/ [fn::Compound pages are a combination of one or more 986 | page that can be used as a single buffer.] boundaries and doesn't span across 987 | pages that are a part of two separate allocations. 988 | 989 | *** Integer defects 990 | 991 | #+BEGIN_LATEX 992 | \todo[inline]{- What is integer overflow? Why is it dangerous? (Mostly because integer overflows are not defined in standards to it is up to the compiler to implement any behavior they wish. \newline 993 | - Can they be prevented? (In brief no, variables can be checked for overflow by calculations during testing but cannot be detected during runtime.))} 994 | #+END_LATEX 995 | 996 | Integer overflows happen as a result of arithmetic operations that result in 997 | values larger than the allocated region. Often, this happens because registers 998 | in processors are fixed-length. They often lead to undefined behaviors in 999 | programs if not handled properly. According to Hui et. al. cite:Hui2013 there 1000 | are four types of integer overflow related bugs that can happen, as explained 1001 | in Figure [[fig:int-overflow]]: 1002 | 1003 | - Integer overflow defect 1004 | - Integer underflow defect 1005 | - Integer signedness defect 1006 | - Integer truncation defect 1007 | 1008 | #+NAME: fig:int-overflow 1009 | #+CAPTION: Types of Integer defects. 1010 | #+CAPTION: Source: Metamorphic Testing Integer Overflow Faults of Mission Critical Program: A Case Study \cite{Hui2013} 1011 | [[./images/integer-overflow.png]] 1012 | 1013 | One common source of integer related defects is the compatibility layer for 1014 | 32bit binaries to work on 64bit architectures. Integer is represented in 1015 | hardware using fixed width registers which can store maximum up to ~INT_MAX~ in 1016 | a signed integer and ~INT_UMAX~ in an unsigned integer. Integer overflows are 1017 | undefined behavior according to C11 standard [Section 3.4.3, C11 Standard], 1018 | because of which compilers are free to handle it in any way they seem fit. 1019 | 1020 | There are 68 integer overflow vulnerabilities (including 11 reference counter 1021 | overflows, which can lead to Use-After-Free bugs [[Use-After-Free]]), 10 integer 1022 | underflow vulnerabilities and 14 integer signedness vulnerabilities that were 1023 | reported against Linux in past 10 years. Integer defects can lead to various 1024 | different types of vulnerabilities like privilege escalation due to logic error 1025 | (CVE-2011-2022). Overflow of size variables can lead to small buffers being 1026 | allocated, causing an overflow later when the data is copied to the buffer 1027 | (CVE-2014-9904, CVE-2012-6703). Overflow of variables during size calculation of 1028 | data can lead to information disclosure (CVE-2011-2209, CVE-2011-2208). 1029 | 1030 | **** Mitigation Techniques 1031 | 1032 | 1033 | #+CAPTION: Mitigation Techniques for Integer defects 1034 | #+ATTR_LATEX: :align |p{5cm}|p{3cm}|p{4cm}|p{1cm}| 1035 | |---------------------+----------------------------+------------+------| 1036 | | Name | Coverage | Bypassable | Cost | 1037 | |---------------------+----------------------------+------------+------| 1038 | | ~PAX_SIZE_OVERFLOW~ | size of memory allocations | no | | 1039 | |---------------------+----------------------------+------------+------| 1040 | 1041 | 1042 | Because these vulnerabilities result due to the behavior of the hardware, it is 1043 | hard to prevent all occurrences of these vulnerabilities. However, if it is 1044 | known beforehand that a variable can overflow, GCC includes primitives 1045 | cite:gccdocs:online to perform addition, subtraction, multiplication operations 1046 | with overflow checks. 1047 | 1048 | ***** PaX 1049 | 1050 | ~PAX_SIZE_OVERFLOW~ from the PaX patches is a GCC plugin which can detect 1051 | overflows. It does so by using a double sized data structure to compute the 1052 | output of expressions and compares that to the actual output to detect an 1053 | overflow. However, it is not possible to put this check /everywhere/ in the 1054 | source, so, it detects /interesting/ size variables in functions which can have 1055 | security implications like buffer overflow due to wrong sized memory 1056 | allocations. Variables that are intentionally allowed to overflow can be marked 1057 | so that they are not checked for overflow. 1058 | 1059 | ***** Testing Oracles 1060 | Integer defects and their effects on missions critical programs in C 1061 | programming language was studied by Hui et. al cite:Hui2013. The lack of 1062 | /testing oracles/ [fn::Testing oracle is a theoretical machine that can predict 1063 | the /correct/ output of a program or expression for testing.] makes the 1064 | testing of integer defects hard. They use a technique called /mutation testing/ 1065 | [fn:: Testing of programs which do not have any test oracle by mutating data 1066 | types in pre-defined fashion to detect anomalous behavior and thus determine 1067 | the presence of an integer defect.] to replace (1) /int/ with /char/, (2) /int/ 1068 | to /short int/ and (3) /int/ to /long int/ along with replacing /signed/ with 1069 | /unsigned/ data types to introduce mutation. 1070 | 1071 | People have proposed solutions to detect integer defects in softwares also by 1072 | training on signatures of previously known vulnerabilities. These solutions 1073 | inference type information of the variables in binaries to pre-calculate the 1074 | values that can be then compared against actual output, use the /status 1075 | register/ to check for overflows and /carry flag/ or use some other test oracle 1076 | to compare the results against. Wang et. al. cite:Wang2014 proposed /SoupInt/, 1077 | which uses this information to check for memory allocations that are smaller 1078 | than they should be and would probably result in a buffer overflow. They use 1079 | static analysis techniques to track the variables that can potentially overflow 1080 | to functions that perform memory allocations. They also go one step ahead of 1081 | detection and generate patch by binary instrumentation to fix these flaws using 1082 | existing error handlers. 1083 | 1084 | *** Analysis 1085 | 1086 | *Bounds Check* related vulnerabilities account for a total of 20% of all the 1087 | vulnerabilities that are reported. Because C doesn't have any built-in support 1088 | for bounds checking, it is hard to prevent these from happening 1089 | altogether. Integer overflows can be detected (using options in GCC) but it 1090 | would cost a lot of performance to enable it un-conditionally for all integer 1091 | types. 1092 | 1093 | ***** Stack Overflow 1094 | Detecting stack based overflows is possible using stack canaries but only after 1095 | they have already happened and, in the best case, would result in a Denial of 1096 | Service or OOPS. ~PAX_USERCOPY~ prevents overflows past the current stack frame 1097 | preventing compromise of control flow but would still result in loosing return 1098 | address at the bottom of the stack frame causing a crash. By virtually mapping 1099 | stack (~CONFIG_VMAP_STACK~) without any need for it to be physically contiguous, 1100 | it is now possible to detect cross-page overflows in Linux by adding guard 1101 | pages. This feature was a part of grsecurity/PaX as ~PAX_KSTACKOVERFLOW~ before 1102 | it was implemented in Linux. By exploiting an array indexing bug (19 of which 1103 | were reported in past 10 years), it is possible to overwrite the return address 1104 | bypassing canaries and all other protections surveyed. 1105 | 1106 | ***** Heap Overflow 1107 | Heap based overflows are harder to protect because of the manual memory 1108 | management. Often un-trusted length values result in more amount data to be 1109 | copied from user-space resulting in corruption or overwrite of neighboring data 1110 | structures or metadata. ~PAX_USERCOPY~ validates the length of all objects 1111 | managed by Slab allocators preventing overflows of these objects. Features from 1112 | ~PAX_USERCOPY~ are being ported to Linux to prevent these attacks and can be 1113 | assumed to be a solved problem. Buffers not allocated through Slab allocators 1114 | are still susceptible to overflows. 1115 | 1116 | ***** Integer Defects 1117 | Integer defects occur due to fixed width of integers in hardware registers which 1118 | allows values past a certain maximum (~INT_MAX~ or ~INT_UMAX~) to overflow and 1119 | wrap around. ~PAX_SIZE_OVERFLOW~ can detect security sensitive integers, which 1120 | define the length of memory allocations. Static analysis tools like SoupInt can 1121 | detect integer overflow bugs by comparing output from computation in hardware 1122 | with emulated calculation with double length data types in software. 1123 | 1124 | ** Null Dereference 1125 | 1126 | #+BEGIN_LATEX 1127 | \todo[inline]{- What is a NULL dereference vulnerability? (de-reference NULL pointers to acccess page zero) \newline 1128 | - Why are they dangerous? (because userspace can map contents to page zero with relevant permissions) \newline 1129 | - How can it be prevented? (runtime options to prevent mapping, SMAP, SMEP, PXN to prevent de-reference.) \newline 1130 | - Is it a solved problem?( Kind-of, ROP can be used to disable SMAP. SMEP can prevent all code injection but SMAP will enable data attacks.) 1131 | } 1132 | #+END_LATEX 1133 | 1134 | Pointers are variables that store the address of another variable or memory 1135 | region. According to C11 standard, de-referencing a NULL pointer is undefined 1136 | behavior. This means, there is no standard for what happens when a NULL pointer 1137 | is dereferenced, which leaves this decision to compilers. Often compilers use 1138 | this undefined behaviors to optimize the code and sometimes even remove checks 1139 | for NULL pointers after they have been de-referenced (since they can't be NULL 1140 | after being de-referenced.). Wang et. al. cite:Wang2012a studied the effect of 1141 | undefined behavior in C and argue that they lead to tricky real world issues 1142 | which can lead to problems in real world. 1143 | 1144 | Usually, NULL (zero) pointers are considered invalid, in which case any code 1145 | that de-references a NULL pointer in user-space causes a memory error, and the 1146 | kernel will kill the process. But in kernel-space, zero is a technically valid 1147 | pointer and it would point to the /zero page/ in virtual memory. This page is 1148 | mapped with no permission bits set, so any access to it will trap into kernel 1149 | which will decide if the process should be allowed the access or not. Only 1150 | processes with ~CAP_SYS_RAWIO~ are allowed to map to page zero. 1151 | 1152 | 1153 | ~vm.mmap_min_addr_~ is a ~sysctl~ [fn::~sysctl~ is tool used to examine and 1154 | configure parameters for Kernel. Configuration parameters are usually exposed 1155 | through ~procfs~ or ~configfs~ in the virtual file system.] knob to set the 1156 | minimum address that any process can ~mmap~ to, which is set to a non-zero value 1157 | by default in most GNU/Linux distributions. To be able to exploit a NULL pointer 1158 | de-reference, the first step would involve bypassing this protection to map 1159 | adversary controlled code or data in the zero page. 1160 | 1161 | Once, an adversary can add code or data to zero page, they can use a NULL 1162 | pointer de-reference bug to use that. There were a total of 149 NULL pointer 1163 | de-reference vulnerabilities that were found, which account for 13.4% of 1164 | total. Without enough permissions, a NULL pointer de-reference results in an 1165 | OOPS and hence denial of service. 1166 | 1167 | *** Mitigation Techniques 1168 | 1169 | #+CAPTION: Mitigation Techniques for NULL pointer Dereferences. 1170 | #+ATTR_LATEX: :align |p{2.7cm}|p{3cm}|p{3cm}|p{1cm}| 1171 | |----------------+-----------------------------------------+------------------------------------------------------------------------------------------------------------+------| 1172 | | Name | Coverage | Bypassable | Cost | 1173 | |----------------+-----------------------------------------+------------------------------------------------------------------------------------------------------------+------| 1174 | | ~KERNEXEC~ | complete | no | | 1175 | | ~SMEP~ / ~PXN~ | only function pointers | no | | 1176 | | ~SMAP~ | complete | yes, can be disabled by writing to a register | | 1177 | | ~UDEREF~ | complete | no | | 1178 | | Smatch | detect NULL de-reference bugs in source | n/a [fn::Smatch is a static analysis tool and cannot guarantee detecting all vulnerabilities of any kind.] | | 1179 | |----------------+-----------------------------------------+------------------------------------------------------------------------------------------------------------+------| 1180 | 1181 | To prevent a NULL pointer de-reference vulnerability from being exploited, one 1182 | can go about two different ways: 1183 | 1184 | 1. Prevent any user-space application to map anything to page zero 1185 | 2. Prevent any NULL pointer from being de-referenced in kernel 1186 | 1187 | **** Page zero mapping 1188 | 1189 | While ~vm.mmap_min_addr~ prevents any process from mapping to zero page by 1190 | default unless the process has ~CAP_SYS_RAWIO~, in past it could be bypassed by 1191 | compromising a /setuid/ [fn::setuid is a mechanism in Linux where any user 1192 | executing a binary with setuid bit set will execute the process with 1193 | permissions of the owner.] binary with required capability. Since it is allowed 1194 | to map to page zero with certain capabilities, a bug in user-space program can 1195 | be exploited to map contents in page zero. ~PER_CLEAR_ON_SETID~ is a list of 1196 | security critical flags that are cleared when a setuid binary is 1197 | executed. Since Linux v2.6.31, this list of flags includes ~MMAP_PAGE_ZERO~, 1198 | which would make it impossible to use this specific technique to map attacker 1199 | controlled code to page zero by exploiting a setuid process. 1200 | 1201 | **** Page zero access 1202 | 1203 | It is hard to prevent Kernel from de-referencing a NULL pointer as they are 1204 | valid pointers, but it is possible to prevent Kernel from de-referencing a 1205 | user-space pointer[fn::NULL pointer would point to user-space when Kernel is 1206 | executing in the context of a user-space process like in system calls.] when it 1207 | is expecting a Kernel space pointer. Supervisor Mode Exec Prevention (SMEP), 1208 | added to /Ivy Bridge/ [fn::Introduced with 3rd generation of Intel Core i CPUs] 1209 | microarchitecture by Intel, prevents Kernel from fetching instructions to 1210 | execute from user-space (Privilege Level 0 in Linux). In recent ARM 1211 | architectures, a similar feature called Privileged eXecute Never (PXN) was 1212 | added to prevent kernel mode access of user-space memory.. PaX's ~KERNEXEC~ 1213 | uses memory segmentation in older architectures which do not support SMEP or 1214 | PXN to implement similar semantics. This can prevent de-referencing dangling 1215 | pointers controlled by attackers. 1216 | 1217 | Supervisor Mode Access Prevention (SMAP), added to /Broadwell/ [fn::Introduced 1218 | with 5th generation of Intel Core i CPUs] microarchitecture by Intel, prevents 1219 | Kernel from any access to user-space memory. However, unlike SMEP, SMAP cannot 1220 | be enabled un-conditionally since there are legitimate use cases when kernel 1221 | needs access to user-space memory. For this reason, SMAP can be enabled and 1222 | disabled by writing to ~CR4~ register. PaX's ~UDEREF~ , similar to ~KERNEXEC~, 1223 | uses memory segmentation in older architectures to prevent Kernel from accessing 1224 | user-space memory. It patches all user-space accessing functions to change 1225 | segmentation related registers to temporarily allow the access. 1226 | 1227 | **** Static Analysis 1228 | 1229 | Static analysis tools like Smatch cite:Smatchth54:online and Coccinelle 1230 | cite:Coccinel90:online can be used to find potential NULL pointer 1231 | vulnerabilities in the source code by testing at development time. 1232 | 1233 | *** Analysis 1234 | NULL Dereference vulnerabilities account for 13.44% of the total vulnerabilities 1235 | reported, highest of all other types. As discussed before, NULL dereference 1236 | vulnerabilities can be exploited if an attacker can map to page 1237 | zero. ~PAX_KERNEXEC~ and ~PAX_UDEREF~ can potentially prevent these attacks by 1238 | emulating ~SMAP~, ~SMEP~ / ~PXN~ in software, but their reliance on memory 1239 | segmentation and availability to only paying customers makes them less-likely 1240 | to be adopted in future. Static analysis tools like Smatch and Coccinelle 1241 | however can be used to find NULL dereference bugs by testing at development 1242 | time. Since ~SMAP~ can still be disabled by writing to ~CR4~ register (possibly 1243 | using a ROP attack), NULL pointer de-references can still be a security threat, 1244 | even with modern hardware support. 1245 | 1246 | ** Format String Vulnerability 1247 | 1248 | #+BEGIN_LATEX 1249 | \todo[inline]{- What is a format string vuln? \newline 1250 | - How can it be exploited? \newline 1251 | - How many of them exist? \newline 1252 | - What are the defenses against them, if any?} 1253 | #+END_LATEX 1254 | 1255 | String formatting is a common technique in programming languages to use template 1256 | strings with placeholders, which are later replaced by values to generate 1257 | desired strings. In C, functions ~printf~ and ~fprint~ are common examples which 1258 | accept these template strings and variables that represent the value to 1259 | placeholders and return a /formatted string/. 1260 | 1261 | #+NAME: printf-example 1262 | #+BEGIN_SRC 1263 | char *screen = "screen"; 1264 | int number = 10; 1265 | printf("Print the number %d to the %s.", number, screen); 1266 | #+END_SRC 1267 | 1268 | #+CAPTION: Stack frame for a format string function. 1269 | #+NAME: fig:format-string 1270 | #+ATTR_LATEX: :width 0.5\textwidth 1271 | [[./images/format-string.png]] 1272 | 1273 | 1274 | In the above example , ~printf~ is a /format function/, ~%d~ is /format string 1275 | parameter/ which defines the /type/ that the variable ~number~ is, and string 1276 | "~Print the number %d to the %s.~" is /format string/. Fig [[fig:format-string]] 1277 | shows their arrangement in the stack. ~printf~ pops the values from the stack 1278 | depending on the number of format string parameters in the format string. A 1279 | malicious input for the value of variable ~screen~ in the above example like 1280 | "~screen %x~" will make ~printf~ pop the next value from the stack which could 1281 | potentially be some sensitive information. 1282 | 1283 | Format string parameter defines the type of input variable, like ~%d~ expects 1284 | and ~int~ or integer type. Format string parameters can be used to read from or 1285 | write to data in the stack, for example: 1286 | 1287 | - ~%x~: To read bytes from memory 1288 | - ~%s~: To read character strings from memory 1289 | - ~%n~: To write an integer in the memory 1290 | - ~%p~: To print the address a pointer points to 1291 | 1292 | A bug where an adversary can control the format string parameter in a format 1293 | string, can leak arbitrary memory regions (using ~%x~) or write arbitrary 1294 | memory regions (using ~%n~). In CVE-2013-2852 cite:CVECVE2033:online an input 1295 | parameter to the Broadcom driver module (b43), which is controlled by 1296 | user-space, is used in a error message without proper validations. When the 1297 | error message is printed or logged, the format string vulnerability in the 1298 | error message can cause arbitrary memory read/write. A total of only 3 1299 | format-string vulnerabilities were found in our analysis. 1300 | 1301 | *** Mitigation Techniques 1302 | 1303 | **** Compiler Instrumentation 1304 | GNU Compiler Collection or GCC can detect calls to ~printf~ which can 1305 | potentially lead to a format string vulnerability. When option 1306 | ~-Wformat-security~ is enabled, GCC warns about calls to ~printf~ without a 1307 | literal string (i.e. input is a variable pointing to format string) and there 1308 | are no arguments to format string. If an adversary can control this variable, 1309 | they can read data from memory. Due to it's security implications, all uses of 1310 | ~%n~ were removed from Linux source in the year 2014 cite:kernelgit82:online 1311 | and any future use will be ignored during compile time. 1312 | 1313 | **** Strict use of format strings 1314 | Information leak from the format string parameters like ~%p~, which can reveal 1315 | kernel pointers, can only be prevented with careful use of these parameters. A 1316 | new format string specifier ~%pK~ was introduced in 2011 cite:kernelgi23:online 1317 | to hide the kernel pointers from being leaked in the logs or ~/proc~ 1318 | filesystem. Depending on the value of ~/proc/sys/kernel/kptr_restrict~ sysctl's 1319 | value, ~%pK~ will have the following behavior: 1320 | 1321 | - ~kptr_restrict = 0~ : No deviation from the standard ~%p~ behavior 1322 | - ~kptr_restrict = 1~ : If the current user doesn't have ~CAP_SYSLOG~ 1323 | capability, all kernel pointers will be printed as all 0's. 1324 | - ~kptr_restrict = 2~: All the kernel pointers are printed as 0's, regarless of 1325 | the privileges. 1326 | 1327 | *** Analysis 1328 | 1329 | While format string vulnerabilities are not very common, there is no defense 1330 | mechanism that can prevent their exploitation if they somehow find their way 1331 | into the kernel. Removal of ~%n~ would make sure that format strings can't be 1332 | used to write to memory. While ~kptr_restrict~ can prevent information leaks, it 1333 | is an opt-in method, which means that it works only if all uses of ~%p~ are 1334 | carefully removed from Linux. For now, it is a matter of convention to not use 1335 | potentially dangerous format string parameters, which can lead to information 1336 | disclosure. There is nothing preventing the use of ~%x~, which bypasses any 1337 | protection provided by ~kptr_restrict~. 1338 | 1339 | ** Missing permission check 1340 | #+BEGIN_LATEX 1341 | \todo[inline]{- These vulnerabilities are mostly due to improper or entirely missing permission checks which allow privilege escalation, in most cases with little work. \newline 1342 | - Can these be prevented against? No, these are programming errors and it is near to impossible to check which of the data access should be mediated by a permission check} 1343 | #+END_LATEX 1344 | 1345 | Missing or wrong permission check are another class of programming errors which 1346 | is very commonly seen in Linux. There are over 133 vulnerabilities reported in 1347 | Linux which were caused due to missing or wrong permission checks. Depending on 1348 | operation and context, a missing or wrong permission check can lead to variety 1349 | of attacks. 1350 | 1351 | Poor handling or namespaces can lead to privilege escalations in containers 1352 | which are often isolated using namespaces in Linux (CVE-2016-1576). Bugs in 1353 | network stack can allow remote attackers to bypass firewall or other network 1354 | restrictions (CVE-2012-4444). Not clearing permissions when spawning off a low 1355 | privilege process can lead to it having un-intended permissions which it may not 1356 | be prepared to handle (CVE-2009-1895). Missing checks for file permissions can 1357 | allow arbitrary changes to append-only files (CVE-2010-2066). 1358 | 1359 | *** Mitigation Techniques 1360 | 1361 | Missing authorization step in the workflow makes it nearly impossible to 1362 | control the access of resource from users that aren't authorized to access it 1363 | /by design/. This makes missing permission checks vulnerability impossible to 1364 | mitigate. 1365 | 1366 | ** Race conditions 1367 | #+BEGIN_LATEX 1368 | \todo[inline]{- These involve poor locking around ciritical memory sections. \newline 1369 | - Can they be prevented? It is hard to check race conditions by simple testing. However, static analysis of code can detect some of these vulnerabilities. \newline 1370 | - What are the effects of it? It can lead to privilege escalation, read/write arbitrary memory.} 1371 | #+END_LATEX 1372 | 1373 | Race conditions are vulnerabilities related to poor handling of critical 1374 | sections in multi-threaded or multi-process software. Usually, this occurs when 1375 | two processes running in parallel change a shared data structure without proper 1376 | co-ordination among themselves. Consider the example below: 1377 | 1378 | #+NAME: race-condition-ex 1379 | #+BEGIN_SRC 1380 | if (x==10) { // Time of check 1381 | y = x*x; // Time of use 1382 | } 1383 | #+END_SRC 1384 | 1385 | Here, if ~x~ is a shared variable among more than one process, it is possible 1386 | that the value of x could be different when its value is checked and when it is 1387 | used in next line. This is commonly called TOCTTOU (Time Of Check To Time of 1388 | Use) vulnerabilities, and this is a simple example of a possible race 1389 | condition. The part of code operating on a shared variable is termed as 1390 | /critical section/ and it's use is often coordinated using locks to prevent a 1391 | race condition. 1392 | 1393 | There are 56 race condition vulnerabilities that were reported against Linux in 1394 | past 10 years. Linux gained support for Simultaneous Multi-Processing (SMP) in 1395 | v2.0, which was released in May, 1996 cite:LinuxKer21:online . However, a 1396 | preemptive system [fn::In a preemptive system, operating system can take control 1397 | back from processes without their will. This is done to make sure a single 1398 | process doesn't starve other processes.] can suspend a thread when it is 1399 | executing in a critical section and can cause race conditions even on systems 1400 | with no support for SMP. In Linux v.2.6, support for preemption for processes 1401 | running kernel code was added. 1402 | 1403 | Race conditions can result in various types of attacks depending on the shared 1404 | state that was left un-checked. In CVE-2009-1527, a wrong type of lock was used 1405 | in a ~ptrace~ system call when accessing the state of a process, which could 1406 | lead to local privilege escalation when tracing a /setuid/ 1407 | application. CVE-2014-9710 allowed users to gain privileges because of a race 1408 | condition which left access control fields empty for some time which could be 1409 | leveraged to bypass intended privilege checks in Btrfs filesystem. 1410 | 1411 | *** Mitigation Techniques 1412 | 1413 | Race conditions are hard to detect and mitigate. Because of their nature, it is 1414 | impossible to detect them using usual testing methods. No known mitigations 1415 | exist today that can prevent exploitation of an existing race condition in 1416 | Linux. 1417 | 1418 | # TODO: lockdep https://lwn.net/Articles/185666/ https://lwn.net/Articles/321663/ 1419 | ** Denial of Service Vulnerabilities 1420 | #+BEGIN_LATEX 1421 | \todo[inline]{- These attack most a result of poor input validation. 1422 | - DoS can generally be caused by any of the vulns mentioned above but this section only includes the ones that do not fall in any of the above category. \newline 1423 | - Can DoS be detected? Yes, common patterns of DoS can be detected by static analysis tools which can look for signatures of previous vulns. They cannot be prevented at runtime though.} 1424 | #+END_LATEX 1425 | 1426 | The three basic pillars on which security of any system is defined are 1427 | /confidentiality/, /integrity/ and /availability/. There are several reasons as 1428 | to why perfect availability is impossible to achieve. We focus only on factors 1429 | that are controlled by software and ignore the failures caused by external 1430 | factors like hardware or external infrastructure. Availability is a property of 1431 | a software system, that depending on the system being observed, could mean 1432 | different things. For example, in a web service, availability implies that the 1433 | endpoint always accepts requests and returns a valid response. This 1434 | availability is representation of the service as a whole, there could be 1435 | multiple failures of individual services that comprise the web service, but due 1436 | to smart replication and request routing, the web service endpoint is always 1437 | functional. 1438 | 1439 | In the context of Linux kernel, availability is defined with the responsiveness 1440 | of processes. Software bugs and crashes affect the availability of the 1441 | system. These crashes are often due to internal bugs, that can be triggered 1442 | from an un-trusted outside input. Different inputs invoke different code paths 1443 | inside kernel and a bug in any of those code paths could lead to a software 1444 | crash. 1445 | 1446 | *** Mitigation Techniqes 1447 | 1448 | Most denial of system vulnerabilities are simple software bugs that are fixed 1449 | quite easily when found, however, the process of finding these bugs might be 1450 | more challenging. It is hard to find a pattern in denial of service 1451 | vulnerabilities, simply due to the large number and types. /Fuzzing/ is a 1452 | software testing methodology where instead of manually curating testing data, 1453 | which could potentially be a large amount given the combinations of 1454 | environments, configuration and inputs, a tool is made to generate testing 1455 | data. These tools are generally called as /fuzzers/. 1456 | 1457 | **** Fuzzers 1458 | 1459 | Fuzzers are provided with basic templates of the API to be tested and are 1460 | allowed to run against a given system. The response for each request is recorded 1461 | and validated and any inconsistencies in the expected output are reported as 1462 | bugs. Linux expose a vast variety of system calls, it's API, which can be tested 1463 | using these fuzzers. 1464 | 1465 | *Trinity* cite:GitHubke85:online and *Syzkaller* cite:GitHubgo91:online are 1466 | Linux system call fuzzers. Both of them use system call templates for argument 1467 | domain specification. Syzkaller also uses code coverage information for guiding 1468 | the fuzzing. 1469 | 1470 | While fuzzers can be helpful to find out some of the bugs, their coverage is 1471 | very limited. They do not provide any guarantee to find all bugs and can often 1472 | miss complicated bugs. 1473 | 1474 | ** Miscellaneous 1475 | 1476 | While the majority of vulnerabilities are based on repeating patterns, some 1477 | aren't. These vulnerabilities are often simple programming errors that cause 1478 | un-expected side effects sometimes. Some common types include faulty 1479 | cryptographic implementations (CVE-2009-3238, CVE-2007-2451, CVE-2014-7284), 1480 | Information leaks due to various reasons that aren't a part of any of the 1481 | previously mentioned classes (CVE-2011-0710, CVE-2010-4565). 1482 | 1483 | A large part of these vulnerabilities result in denial of service i.e. affect 1484 | the availability of the system. Linux has several essential processes running 1485 | in kernel mode, which when fail, push the kernel in an un-reliable 1486 | state. Several of the bugs that can generally be classified into more specific 1487 | classes of bugs, like NULL Dereference [[Null Dereference]], Buffer Overflow [[Bounds 1488 | Check]] etc, can also cause services to crash. Even simple bugs like a missing 1489 | error handler can cause kernel crashes. Compute intensive code paths, which can 1490 | be invoked from an un-trusted input, can make the system un-available to other 1491 | requests, even without a failure. 1492 | 1493 | CVE-2011-1768 allowed remote attackers to cause an OOPS by sending a packet 1494 | while the ~ip_gre~ module is being loaded. CVE-2009-0747 allowed local users to 1495 | cause CPU consumption and error-message flood by trying to mount a crafted EXT4 1496 | filesystem. CVE-2015-5307 allowed guest OS users to hang host OS by raising 1497 | many Alignment Check exceptions. 1498 | 1499 | CVE-2016-4440 allowed guest OS users to access APIC MSR on host OS due to poor 1500 | handling of the APICv on/off state. CVE-2013-0311, caused by a bug in 1501 | translation of cross-region descriptor, can cause guest OS to attain host OS 1502 | privileges by leveraging KVM guest OS privileges. CVE-2015-0274, caused by a 1503 | bug in XFS filesystem implementation, uses a wrong size value during attribute 1504 | replacement allowing local users to cause a denial of service or gain 1505 | privileges. 1506 | 1507 | 1508 | Some of these vulnerabilities can be sorted into logical groups, though, these 1509 | groups don't particularly have any good proactive defenses known yet. These 1510 | groups include: 1511 | 1512 | - *Infinite Loop*: These vulnerabilities can cause loops to run indefinitely 1513 | making a system un-responsive and un-available to perform actual work. 1514 | - *Memory Leaks*: Memory leaks can often result in huge memory consumption and 1515 | un-availability of memory, thus starving them out. 1516 | - *Divide-by-zero*: Dividing any number by zero is an undefined operation and 1517 | depending on the situation, it can result in a system crash. These 1518 | vulnerabilities often happen when the variable in the denominator becomes 1519 | zero unexpectedly. 1520 | - *Cryptography*: Several bugs in cryptographic protocol implementations can 1521 | result in exploits as cryptography is often the basis of security in a lot of 1522 | protocols. 1523 | - *Length Calculation Bugs*: These bugs are often caused by mis-calculating the 1524 | size or length of a data or wrong arithmetic. It can often result in either 1525 | too big or too small memory region being allocated and sometimes may or 1526 | may-not result in buffer-overflow or buffer-overread. 1527 | 1528 | 1529 | *** Mitigation Techniques 1530 | 1531 | Since these vulnerabilities don't show any common pattern in their type, it is 1532 | hard to actually prevent them from being exploited. Proactive defenses are 1533 | based on the idea of predictable behavior of vulnerabilities, which can't be 1534 | found in these vulnerabilities. 1535 | 1536 | Most vulnerabilities that result in denial of service are simple software bugs 1537 | that are fixed quite easily when found, however, the process of finding these 1538 | bugs is more challenging. /Fuzzing/ is a software testing methodology where 1539 | instead of manually curating testing data, which could potentially be a large 1540 | amount given the combinations of environments, configuration and inputs, a tool 1541 | is made to generate testing data. These tools are generally called as 1542 | /fuzzers/. 1543 | 1544 | **** Fuzzers 1545 | 1546 | Fuzzers are provided with basic templates of the API to be tested and are 1547 | allowed to run against a given system. The response for each request is recorded 1548 | and validated and any inconsistencies in the expected output are reported as 1549 | bugs. Linux expose a vast variety of system calls, it's API, which can be tested 1550 | using these fuzzers. 1551 | 1552 | *Trinity* cite:GitHubke85:online and *Syzkaller* cite:GitHubgo91:online are 1553 | Linux system call fuzzers. Both of them use system call templates for argument 1554 | domain specification. Syzkaller also uses code coverage information for guiding 1555 | the fuzzing. 1556 | 1557 | While fuzzers can be helpful to find out some of the bugs, their coverage is 1558 | very limited. They do not provide any guarantee to find all bugs and can often 1559 | miss complicated bugs. 1560 | 1561 | * ROP Attacks and Protections 1562 | 1563 | ** Return-Oriented Programming attacks 1564 | 1565 | #+BEGIN_LATEX 1566 | \todo[inline]{- What are code-reuse attacks? Why are they still dangerous? (mostly because all protection mechanisms assume a perfect kernel with no other vulns.) \newline 1567 | - Are existing solutions enough to prevent all ROP? (No, most solutions both in research and industry can be broken by information leakages.) \newline 1568 | - What else can be done? CFI enforced by a higher privielged hypervisor can enforce complete safety but this study only includes protection mechanisms within Kernel.} 1569 | #+END_LATEX 1570 | 1571 | Return-oriented-programming (ROP) or code-reuse attacks are based on a 1572 | combination of vulnerabilities and have been shown to bypass modern defenses 1573 | for various types of vulnerabilities discussed in Chapter [[Vulnerabilities and 1574 | Defenses]]. Given that these are attacks and not vulnerabilities, they aren't 1575 | assigned CVE numbers to quantify their frequency. Hence, they are studied 1576 | separately from other types of vulnerabilities. 1577 | 1578 | ROP attacks hijack the control flow of a program by exploiting a memory 1579 | corruption vulnerability and then using existing code in memory to perform 1580 | un-intended operations cite:Skowyra2013,Li2010,Checkoway2010 . Previously 1581 | called return-to-libc cite:Shacham:2007:GIF:1315245.1315313, these attacks use 1582 | the existing code fragments in shared libraries or program binary to implement 1583 | arbitrary program logic. As these attacks got more sophisticated, their 1584 | dependence on shared libraries reduced and code fragments could be generated 1585 | using JIT compiler and within the program binary. Code fragments, also called 1586 | /gadgets/, which end in a ~ret~ statement can be chained together to perform 1587 | turing-commplete [fn:: Turing-completeness implies that any arbitrary operation 1588 | can be performed using any random combination of system calls.] 1589 | cite:Checkoway2010 set of operations. There are typically three steps in a 1590 | successful ROP attack: 1591 | 1592 | 1. Exploit a memory corruption vulnerability to change a return address or 1593 | function pointer 1594 | 2. Jump to the user-controlled code using the above vulnerability and to the 1595 | next gadget from their in a chain 1596 | 3. Return to the correct location that was supposed to run in step 1 1597 | 1598 | The first and most important requirement to launch a ROP attack is a memory 1599 | corruption vulnerability. If there is one thing that analysis of past 10 years 1600 | of vulnerabilities has revealed, it is that they are available in plenty. By 1601 | exploiting a spatial memory vulnerability, as discussed in Bounds Check 1602 | vulnerabilities, section [[Bounds Check]], it is possible to overwrite the return 1603 | address of a function to jump to an arbitrary location. A NULL pointer 1604 | deference, discussed in section [[Null Dereference]], can be used to redirect 1605 | program flow to page zero. Use-after-free vulnerabilities, discussed in section 1606 | [[Use-After-Free]], allow hijacking control flow by compromising function pointer 1607 | tables. To redirect the control flow, it is also important to know the correct 1608 | address of gadgets in memory which may not always be trivial as Linux 1609 | randomizes the base address of various memory segments (ASLR). 1610 | 1611 | In second step, the control jumps from the location of memory corruption bug to 1612 | a user controlled location. It is important that this location be mapped in 1613 | virtual memory area and be accessible at the call site. If this condition is not 1614 | met, any access to un-mapped region would crash the kernel or cause an OOPS 1615 | leading to an un-successful attack. 1616 | 1617 | Finally, to successfully evade detection, the attack should be able to return 1618 | the control back to the program for it proceed under compromised 1619 | conditions. 1620 | 1621 | ***** Information Leakage 1622 | Research community has also shown that some defenses like ASLR [[Address Space 1623 | Layout Randomization]], mentioned later in defenses, can be broken using 1624 | information obtained from hardware side-channel attacks which are based on 1625 | micro-architectural features. Gruss et. al. cite:Gruss2016 use software 1626 | pre-fetching instructions to obtain sensitive information from various caches 1627 | in x86 system, Hund et. al. cite:Hund used timing channel attacks against 1628 | double page faults to discover valid memory locations, Jang et. al. cite:Jang 1629 | use Intel Transactional Synchronization Extension (TSX) from recent Intel 1630 | processors to perform timing channel using similar methods. Information 1631 | revealed from vulnerabilities in Linux can also be used to weaken the 1632 | guarantees offered by ASLR (CVE-2013-0914, CVE-2016-3672, 2015-8575, 2015-8569, 1633 | 2014-9585, 2014-9419). Oikonomopoulos et. al. cite:Oikonomopoulos2016 later 1634 | showed that it is possible to determine the location of code fragments without 1635 | complicated side-channel attacks and instead relying on allocation oracles, 1636 | which repeatedly allocated chunks of memory to determine the holes in 1637 | address-space where the possible code-targets could be. 1638 | 1639 | *** Mitigation Techniques 1640 | 1641 | To systematize the study of all the mitigation techniques, they are grouped 1642 | based on the step that they prevent in above mentioned ROP attack. We skip over 1643 | mitigation techniques for memory corruption vulnerabilities as they have been 1644 | discussed in detail in sections [[Use-After-Free]], [[Bounds Check]], and [[Null 1645 | Dereference]]. 1646 | 1647 | **** Prevention of Step 1 1648 | 1649 | In order to execute *step 1*, an attacker requires the address of gadgets in 1650 | memory to jump to. Memory address for a particular instruction in memory can be 1651 | calculated by adding it's offset from the start of the program to the base 1652 | address of the memory segment where the program is mapped. Address Space Layout 1653 | Randomization (ASLR) is a technique to randomize the base address of different 1654 | section in virtual memory area. Depending on the implementation, each chosen 1655 | section could have some entropy in it's base address making it hard to guess its 1656 | value reliably. There are 256 and 512 random positions possible for 32bit and 1657 | 64bit x86 Linux in current implementation of ASLR. 1658 | 1659 | ***** grsecurity 1660 | ~GRKERNSEC_RANDSTRUCT~ is a GCC plugin from grsecurity which randomizes the 1661 | layout of all the structures comprised of function pointers (a.k.a /ops/ 1662 | structures) to make it harder to overwrite them using spatial memory 1663 | errors. Because it has a high performance overhead, another option 1664 | ~GRKERNSEC_RANDSTRUCT_PERFORMANCE~ is provided which takes into account the size 1665 | of cache-line to randomize structures with reduced security guarantees. This 1666 | plugin was ported over to Linux in v4.13 but only randomizes structures that are 1667 | explicitly marked with ~__randomize_layout~ cite:kernelgi67:online. 1668 | 1669 | 1670 | ***** Address Space Layout Randomization 1671 | 32bit implementations of ASLR are vulnerable to de-anonymization attacks by 1672 | means of brute force (cite:Shacham, cite:RouterEx31:online). Randomizing ~mmap~ 1673 | , each shared library, code and data segments separately can increase the 1674 | difficulty of such attacks. Kil et. al. cite:Kil proposed Address Space Layout 1675 | Permutation (/ASLP/) to randomize base address of stack, heap, shared libraries 1676 | and executable to make it harder to guess the address of code in memory, such 1677 | techniques are called fine grained ASLR. Bigelow et. al. cite:Bigelow2015 1678 | proposed re-randomization of memory space as soon as the program gives an 1679 | output to render the data revealed from information leaks useless. Lu 1680 | et. al. cite:Lu encode the code-pointers when they are treated as data so that 1681 | they are of no use when leaked to determine the address of code region. 1682 | 1683 | 1684 | ***** Isolation 1685 | A recent work by Gruss et. al. cite:Gruss, /KAISER/, makes Kernel Address 1686 | Space Layout Randomization (/KASLR/) more promising by proposing stronger 1687 | isolation between kernel-space and user-space memory in order to defend against 1688 | side-channel attacks. They propose removing mapping of kernel in userspace, 1689 | with exception of some portions which would allow context switch to 1690 | kernel-space memory. ARM processors have two separate page tables for mapping 1691 | user-space and kernel-space which allows stronger isolation of user-space and 1692 | kernel-space. 1693 | 1694 | ***** Return-less kernel 1695 | Li et. al. cite:Li2010 proposed removing all the ~ret~ instructions using 1696 | binary instrumentation techniques as an effort to remove all the gadgets that 1697 | can be used in a ROP attack, but Checkoway et. al. cite:Checkoway2010 and 1698 | Bletsch et. al. cite:Bletsch showed that it is possible to perform ROP attacks 1699 | even without ~ret~ instructions by using ~jmp~ instructions which also allow 1700 | jumping to a region in memory like ~ret~. They termed it as jump-oriented 1701 | programming (JOP) attacks. 1702 | 1703 | 1704 | ***** Protected Pointers 1705 | Cowan et. al. proposed /PointGuard/ cite:Cowan2003 which prevents pointers from 1706 | leaking by encrypting them in the memory and decrypting them only before 1707 | dereferencing. One single encryption key is used to encrypt all addresses and is 1708 | stored in a register. It suffered from various problems like use of single key 1709 | (which can be exposed with an information leak) for all encryption and 1710 | incompatibility with existing source and binaries. Bhatkar et. al. cite:Bhatkar 1711 | introduced /Data Space Randomization/ which would extend the idea of PointGuard 1712 | to encrypt all data, pointers as well as other variables, using separate keys 1713 | and instrument binary to support it. While it promises better security than 1714 | PointGuard due to use of different encryption keys, it suffers from other 1715 | problems like binary and source incompatibility, poor performance (15% 1716 | overhead), incompatibility with unmodified libraries etc. 1717 | 1718 | 1719 | **** Prevention of Step 2 1720 | 1721 | To prevent jumping to an attacker controlled address, *step2* of attack, a 1722 | technique called Control Flow Integrity (CFI) was proposed by by Abadi et. al 1723 | cite:Abadi:2005:CI:1102120.1102165 in 2005. It involves static analysis of the 1724 | source code to generate a call flow graph (CFG) and binary instrumentation to 1725 | enforce program flow to strictly adhere to CFG. An indirect jump from the point 1726 | of memory corruption bug to attacker controlled code is called /forward edge/ 1727 | attack since it creates a forward edge in CFG. Ligatti 1728 | et. al. cite:Ligatti2007, Tice et. al. cite:Tice2014 and many others further 1729 | improved forward edge CFI to achieve better performance without compromising the 1730 | security. A new class of CFI techniques called coarse-grained CFI relaxed strict 1731 | restrictions of original (fine grained) CFI to allow for more valid control flow 1732 | jumps like ROPecker by Cheng et. al. cite:Cheng2014 and kBouncer cite:Pappas2012 1733 | by Pappas et. al. But they were soon shown to be in-effective 1734 | cite:Davi2014,Carlini2014 against slight modifications in attack strategy. 1735 | 1736 | ***** GRSecurity 1737 | ~RAP~ from grsecurity is a GCC plugin which implements fine-grained CFI in 1738 | Linux. It infers type information from functions and function pointers and 1739 | checks a hash value of the function type on pointer dereference to make sure 1740 | that the pointer points to the correct place. However, in existing Linux code, 1741 | several pointers have different types than the functions that they point to 1742 | which makes it a lot of work to change and then maintain(enforce it in future). 1743 | 1744 | 1745 | ***** Hardware Techniques 1746 | ~SMEP~, discussed in section [[Null Dereference]], can prevent certain classes of 1747 | ROP attacks called /ret2user/ attacks which redirect the control flow of Linux 1748 | program to user-space for gadgets. Gruss et. al. cite:Gruss2016 recently showed 1749 | that protections that prevent access to user-space like ~SMAP~, ~SMEP~, ~PXN~, 1750 | ~PAX_SEGMEXEC~, ~PAX_PAGEEXEC~ can be bypassed by using ~pysmap~, a mapping of 1751 | entire user-space memory in kernel-space in Linux, to bypass all the protections 1752 | that prevent user-space access from the Kernel. 1753 | 1754 | **** Prevention of Step 3 1755 | 1756 | To execute *step3* in the ROP attack chain, an attacker should be able to return 1757 | back to the site of memory corruption bug in order resume the normal flow of the 1758 | program (in the compromised state.) /Stack Shield/ cite:StackShi26:online is a 1759 | tool which uses /shadow stacks/ to prevent indirect control transfers from stack 1760 | overflow attacks that overwrite return addresses. Return addresses are pushed on 1761 | to a different stack (called shadow stacks), which is protected using other 1762 | mechanisms, and compared against the return address when the function returns to 1763 | make sure it wasn't modified by an attacker. Studies by Carlini 1764 | et. al. cite:Carlini show that shadow stacks are effective in preventing 1765 | arbitrary code execution. Dang et. al. cite:Dang studied the performance 1766 | overheads of different shadow stack implementations to see if they are practical 1767 | and propose lightweight techniques to reduce performance impact of existing 1768 | shadow stack implementations. Intel recently introduced Control-flow Enforcement 1769 | Technology (CET) cite:Controlf71:online which will be a part of future 1770 | generation of Intel processors and will provide hardware support for shadow 1771 | stacks in hardware which will increase the performance of such solutions. 1772 | 1773 | ***** GRSecurity 1774 | ~RAP~, from grsecurity, uses a technique similar to what Cowan 1775 | et. al. cite:Cowan2003 and Bhatkar et. al. cite:Bhatkar proposed previously to 1776 | prevent step 1 of ROP attack. It encrypts the return address on function call 1777 | and stores the encrypted return address and the encryption key in two registers, 1778 | when the function returns, it re-encrypts the address being returned-to and 1779 | halts execution if both of them don't match. The choice of key is not limited to 1780 | a single value for every process, long running threads in Linux like the 1781 | scheduler can use a new key on each iteration. 1782 | 1783 | *** Analysis 1784 | *Code-reuse attacks* or *ROP* attacks are one of the biggest challenges 1785 | today. ASLR based protection schemes can be bypassed with data obtained from 1786 | information leak vulnerabilities, over 200 (includes un-initialized data, buffer 1787 | over-reads, other information leaks) of the which were reported in past 10 1788 | years. ~RAP~ from grsecurity/PaX encrypts return addresses and enforces 1789 | forward-edge CFI by allowing pointers to point to only valid functions that are 1790 | identified by their unique hash. However, since it uses encryption to prevent 1791 | return-addresses from being corrupted, it is susceptible to information leaks 1792 | which can reveal the encryption keys. Forward-edge CFI in ~RAP~ also depends on 1793 | the fact that function pointers can only point to specific function types which 1794 | is not enforced in C. This would require a lot of change in Linux source code to 1795 | function correctly. 1796 | 1797 | Research papers that prevent pointer corruption by encrypting them in memory 1798 | suffer from a high overhead and binary-incompatibility. Coarse grained CFI 1799 | techniques improved the performance but can be easily bypassed with slight 1800 | modification in the attack strategy. Intel CET will provide support for shadow 1801 | stacks in hardware for better performance of CFI techniques in future, but would 1802 | leave others without latest hardware susceptible to ROP attacks. If these 1803 | techniques will be able to offer complete remediation against ROP, even with 1804 | support from hardware, still remains a question. ASLR and related techniques, 1805 | based on randomization of addresses have shown to be weak, but research 1806 | community hasn't given up on it yet. Newer works promise better implementation 1807 | and ideas that can possible render information leaks useless. 1808 | 1809 | One point to note here is that some solutions to prevent ROP by leveraging 1810 | virtualization techniques have also been proposed. They however haven't been 1811 | covered in this survey, which studies the current security capabilities of Linux 1812 | kernel itself, as it requires an outside agent to prevent these attacks. 1813 | 1814 | * Discussion and Conclusion 1815 | 1816 | #+BEGIN_LATEX 1817 | \todo[inline]{- Threat model for future research based on this analysis. \newline 1818 | - Performance and Compatibility vs Security argument for a general purpose operating system \newline 1819 | - CI and testing process before release? \newline 1820 | - Analysis of the survey and results mentioned in the previous two sections. \newline 1821 | - What are the best and most promising ideas from research papers that help with better security at low cost.} 1822 | #+END_LATEX 1823 | 1824 | ** Discussions 1825 | 1826 | #+CAPTION: Summary of Current State of Defense Techniques 1827 | #+NAME: table:summary-all-defenses 1828 | #+ATTR_LATEX: :align |p{2.5cm}|p{6cm}|p{6cm}| 1829 | #+ATTR_LATEX: :placement [hp!] 1830 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1831 | | *Vulnerability Class* | *Defenses* | *Research* | 1832 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1833 | | Un-initialized Data | - Defense exists for different memory allocators but not general case | - Better coverage | 1834 | | | - Limited coverage, does not prevent against un-marked fields | - Better performance available | 1835 | | | - Poor performance | - Solved with acceptable performance | 1836 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1837 | | Use-after-free | - Defenses available for special cases like reference counters | - Full coverage | 1838 | | | - Randomization techniques makes attacks harder | - Solved with acceptable performance | 1839 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1840 | | Bounds Check/ Stack Overflow | - Detection tools available to cover most cases except direct memory overwrite | - Studies based on Hardware extensions show promising results but poor performance | 1841 | | | | | 1842 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1843 | | Bounds Check/ | - Code injection attacks in heap are solved | - | 1844 | | Heap Overflow | - Overflows crossing page boundaries can be prevented | | 1845 | | | - Unsolved for non-slab allocators | | 1846 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1847 | | Bounds Check/ Integer Defects | - Size overflow detection possible with limited coverage and explicit overflow check | - Testing theories to detect overflows based on signatures exist | 1848 | | | | | 1849 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1850 | | Null Derference | - Solved with proper configuration | - | 1851 | | | - Hardware features (SMAP, SMEP) prevent exploitation | | 1852 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1853 | | Format String | - Pointer leaks can be prevented with configuration in some cases | - Not available | 1854 | | | - Compile time checks detection possible with limited coverage | | 1855 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1856 | | Missing Perm. Check | - Impossible to enforce permissions without authorization step | - Not available | 1857 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1858 | | Race Conditions | - Not available | - Not available | 1859 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1860 | | | - Fuzzing tools can find bugs leading to crashes | - Not available | 1861 | | Miscelleanous | - No proactive defenses available as these lack patterns | | 1862 | |-------------------------------+--------------------------------------------------------------------------------------+------------------------------------------------------------------------------------| 1863 | 1864 | 1865 | In Chapter 3 and Chapter 4, we discussed different types of vulnerabilities, 1866 | their exploitation methodologies and finally their defenses. Apart from some 1867 | classes like denial of service, missing permission checks etc. our survey 1868 | reveals that there exists solutions for most range of vulnerabilities that are 1869 | commonly found in Linux with varying amount of coverage and performance. Table 1870 | [[table:summary-all-defenses]] provides a summary of all the defenses discussed in 1871 | Chapter 3. 1872 | 1873 | However, it is very difficult to discretely distinguish these vulnerabilities 1874 | into solved and unsolved groups due to several reasons. The most ideal 1875 | definition of a solved problem would be a defense mechanism that exists in 1876 | Mainline Linux kernel and which is enabled by default. Even though the defenses 1877 | may exist in Linux, their widespread use is seen only if they are enabled by 1878 | default. There are several reasons for why defenses are not enabled by default, 1879 | stability, compatibility with legacy software and performance are the top three 1880 | reasons. 1881 | 1882 | A general feature in Linux is initially disabled by default when introduced in 1883 | the Mainline. Various distributions then configure their kernels to a desired 1884 | state and sometimes enable these features depending on the requirements of 1885 | their users. Slowly and gradually after these features have been tested with a 1886 | subset of users, these features are then enabled by default in Mainline kernel 1887 | with feedback from major distributions. This entire cycle takes a few years to 1888 | complete. Proactive defenses are often considered as features, as compared to 1889 | fixes for a specific CVE. 1890 | 1891 | From here, there are several less-than-ideal states, that these defense 1892 | mechanisms can be in. Depending on the preference, stability and performance 1893 | can be traded off for better security. Various solutions exist that can be 1894 | improved in terms of performance overhead, stability and support for existing 1895 | applications, etc. 1896 | 1897 | In our survey, we found that most vulnerabilities have a defense mechanism that 1898 | works. Some of them are implemented by PaX and GRSecurity patches, others have 1899 | been added to Linux over the past decade. However, the performance impact of 1900 | several of the defenses offered by PaX and GRSecurity patches leave a lot more 1901 | to be desired. 1902 | 1903 | The quantitative study of the vulnerabilities draws a picture about the trends 1904 | in vulnerabilities over the years. According to Figure 1905 | [[fig:yearly-distribution-of-vulns]], the total number of vulnerabilities have been 1906 | on rise in past decade, with occasional lows. Figure [[fig:cvss-distribution]] 1907 | shows the distribution of CVSS for vulnerabilities that we analyzed. It shows 1908 | that high severity issues, while not un-common, are rare. 1909 | 1910 | ** Conclusions 1911 | 1912 | In conclusion, the number of vulnerabilities in Linux has been on rise 1913 | effectively in past 10 years. However, the survey of defenses added to Linux 1914 | and other options that exist outside of Mainline Linux, points to an improved 1915 | overall state of security. Table [[table:summary-all-defenses]] consists of an 1916 | summary of solutions for various categories and open gaps for future research 1917 | work and areas requiring performance improvements. It is impossible to make 1918 | claims about the net-improvement in security of Linux /quantitatively/, but 1919 | theoretically, there are solutions for most of the classes of vulnerabilities 1920 | in Linux. Some of these defenses come at a cost of poor performance, but 1921 | considering the features that have already been added to Linux, it can be 1922 | safely assumed that with significant engineering efforts, these can be 1923 | incorporated in Linux to make it even more resistant. 1924 | 1925 | ** Future Work 1926 | 1927 | Now that we know about the relative occurrences of different classes of 1928 | vulnerabilities, a logical extension of this work is to map the vulnerabilities 1929 | to different parts of Linux. Linux has a huge code base and it would be 1930 | interesting to see which parts of Linux have higher frequency of security 1931 | vulnerabilities. In a typical Linux installation, not all the parts are useful 1932 | since Linux is comprised of a large number of drivers for specific devices. By 1933 | stripping off less or un-used parts of code in Linux, which have high number of 1934 | vulnerabilities, Linux can be made more secure. 1935 | 1936 | 1937 | bibliography:~/Dropbox/Thesis/bibliography/mendeley-export/library.bib,thesis.bib 1938 | bibliographystyle:unsrt 1939 | 1940 | 1941 | #+Latex: \appendix 1942 | 1943 | * List of ALL CVEs 1944 | 1945 | 1946 | ** Un-initialized data 1947 | #+LATEX: \begin{multicols}{3} 1948 | #+LATEX: \noindent 1949 | CVE-2016-9178 \\ 1950 | CVE-2016-5244 \\ 1951 | CVE-2016-5244 \\ 1952 | CVE-2016-4580 \\ 1953 | CVE-2016-4580 \\ 1954 | CVE-2016-4578 \\ 1955 | CVE-2016-4569 \\ 1956 | CVE-2016-4486 \\ 1957 | CVE-2016-4485 \\ 1958 | CVE-2016-4485 \\ 1959 | CVE-2016-4482 \\ 1960 | CVE-2016-4470 \\ 1961 | CVE-2016-0821 \\ 1962 | CVE-2015-8950 \\ 1963 | CVE-2015-8539 \\ 1964 | CVE-2015-7885 \\ 1965 | CVE-2015-7884 \\ 1966 | CVE-2015-5697 \\ 1967 | CVE-2014-9900 \\ 1968 | CVE-2014-9895 \\ 1969 | CVE-2014-9892 \\ 1970 | CVE-2014-1446 \\ 1971 | CVE-2014-1445 \\ 1972 | CVE-2014-1444 \\ 1973 | CVE-2013-7281 \\ 1974 | CVE-2013-7271 \\ 1975 | CVE-2013-7270 \\ 1976 | CVE-2013-7269 \\ 1977 | CVE-2013-7268 \\ 1978 | CVE-2013-7267 \\ 1979 | CVE-2013-7265 \\ 1980 | CVE-2013-7264 \\ 1981 | CVE-2013-7263 \\ 1982 | CVE-2013-4516 \\ 1983 | CVE-2013-4515 \\ 1984 | CVE-2013-4470 \\ 1985 | CVE-2013-3237 \\ 1986 | CVE-2013-3236 \\ 1987 | CVE-2013-3235 \\ 1988 | CVE-2013-3234 \\ 1989 | CVE-2013-3233 \\ 1990 | CVE-2013-3232 \\ 1991 | CVE-2013-3231 \\ 1992 | CVE-2013-3230 \\ 1993 | CVE-2013-3229 \\ 1994 | CVE-2013-3228 \\ 1995 | CVE-2013-3227 \\ 1996 | CVE-2013-3226 \\ 1997 | CVE-2013-3225 \\ 1998 | CVE-2013-3224 \\ 1999 | CVE-2013-3223 \\ 2000 | CVE-2013-3222 \\ 2001 | CVE-2013-3076 \\ 2002 | CVE-2013-2636 \\ 2003 | CVE-2013-2635 \\ 2004 | CVE-2013-2634 \\ 2005 | CVE-2013-2547 \\ 2006 | CVE-2013-2237 \\ 2007 | CVE-2013-2234 \\ 2008 | CVE-2013-2148 \\ 2009 | CVE-2013-2147 \\ 2010 | CVE-2013-2141 \\ 2011 | CVE-2012-6549 \\ 2012 | CVE-2012-6548 \\ 2013 | CVE-2012-6547 \\ 2014 | CVE-2012-6546 \\ 2015 | CVE-2012-6545 \\ 2016 | CVE-2012-6544 \\ 2017 | CVE-2012-6543 \\ 2018 | CVE-2012-6542 \\ 2019 | CVE-2012-6541 \\ 2020 | CVE-2012-6540 \\ 2021 | CVE-2012-6539 \\ 2022 | CVE-2012-6538 \\ 2023 | CVE-2012-6537 \\ 2024 | CVE-2012-3430 \\ 2025 | CVE-2011-4087 \\ 2026 | CVE-2011-2492 \\ 2027 | CVE-2011-2184 \\ 2028 | CVE-2011-1173 \\ 2029 | CVE-2011-1173 \\ 2030 | CVE-2011-1172 \\ 2031 | CVE-2011-1171 \\ 2032 | CVE-2011-1170 \\ 2033 | CVE-2011-1163 \\ 2034 | CVE-2011-1160 \\ 2035 | CVE-2011-1080 \\ 2036 | CVE-2011-1078 \\ 2037 | CVE-2011-1044 \\ 2038 | CVE-2011-0711 \\ 2039 | CVE-2010-4655 \\ 2040 | CVE-2010-4525 \\ 2041 | CVE-2010-4158 \\ 2042 | CVE-2010-4083 \\ 2043 | CVE-2010-4082 \\ 2044 | CVE-2010-4081 \\ 2045 | CVE-2010-4080 \\ 2046 | CVE-2010-4079 \\ 2047 | CVE-2010-4078 \\ 2048 | CVE-2010-4077 \\ 2049 | CVE-2010-4076 \\ 2050 | CVE-2010-4075 \\ 2051 | CVE-2010-4074 \\ 2052 | CVE-2010-4073 \\ 2053 | CVE-2010-4072 \\ 2054 | CVE-2010-3881 \\ 2055 | CVE-2010-3877 \\ 2056 | CVE-2010-3876 \\ 2057 | CVE-2010-3875 \\ 2058 | CVE-2010-3861 \\ 2059 | CVE-2010-3477 \\ 2060 | CVE-2010-3298 \\ 2061 | CVE-2010-3297 \\ 2062 | CVE-2010-3296 \\ 2063 | CVE-2010-2955 \\ 2064 | CVE-2010-2942 \\ 2065 | CVE-2009-3612 \\ 2066 | CVE-2009-3228 \\ 2067 | CVE-2009-3002 \\ 2068 | CVE-2009-3001 \\ 2069 | CVE-2009-2847 \\ 2070 | CVE-2009-2692 \\ 2071 | CVE-2009-1914 \\ 2072 | CVE-2009-1192 \\ 2073 | CVE-2009-0676 \\ 2074 | CVE-2008-2812 \\ 2075 | CVE-2008-0598 \\ 2076 | CVE-2005-4881 \\ 2077 | 2078 | #+LATEX: \end{multicols} 2079 | ** Use-After-Free 2080 | #+LATEX: \begin{multicols}{3} 2081 | #+LATEX: \noindent 2082 | 2083 | CVE-2016-6828 \\ 2084 | CVE-2016-4805 \\ 2085 | CVE-2016-4794 \\ 2086 | CVE-2016-4557 \\ 2087 | CVE-2016-3951 \\ 2088 | CVE-2016-3841 \\ 2089 | CVE-2016-2547 \\ 2090 | CVE-2016-2546 \\ 2091 | CVE-2016-2546 \\ 2092 | CVE-2016-2544 \\ 2093 | CVE-2016-2384 \\ 2094 | CVE-2016-2184 \\ 2095 | CVE-2016-0723 \\ 2096 | CVE-2015-7312 \\ 2097 | CVE-2015-5706 \\ 2098 | CVE-2015-3636 \\ 2099 | CVE-2015-0568 \\ 2100 | CVE-2014-6417 \\ 2101 | CVE-2014-5332 \\ 2102 | CVE-2014-4653 \\ 2103 | CVE-2014-3153 \\ 2104 | CVE-2014-2568 \\ 2105 | CVE-2014-1737 \\ 2106 | CVE-2014-0131 \\ 2107 | CVE-2013-7446 \\ 2108 | CVE-2013-7348 \\ 2109 | CVE-2013-7026 \\ 2110 | CVE-2013-4343 \\ 2111 | CVE-2013-4127 \\ 2112 | CVE-2013-2017 \\ 2113 | CVE-2013-1797 \\ 2114 | CVE-2013-1767 \\ 2115 | CVE-2012-3511 \\ 2116 | CVE-2012-3510 \\ 2117 | CVE-2012-2745 \\ 2118 | CVE-2012-2133 \\ 2119 | CVE-2012-1583 \\ 2120 | CVE-2012-1583 \\ 2121 | CVE-2011-1479 \\ 2122 | CVE-2011-0714 \\ 2123 | CVE-2010-4526 \\ 2124 | CVE-2010-4169 \\ 2125 | CVE-2010-3080 \\ 2126 | CVE-2010-1188 \\ 2127 | CVE-2009-4141 \\ 2128 | CVE-2007-1592 \\ 2129 | CVE-2007-0772 \\ 2130 | 2131 | 2132 | #+LATEX: \end{multicols} 2133 | ** Bounds Check 2134 | 2135 | *** Stack Overflow 2136 | #+LATEX: \begin{multicols}{3} 2137 | 2138 | 2139 | CVE-2016-8658 \\ 2140 | CVE-2016-8650 \\ 2141 | CVE-2016-7042 \\ 2142 | CVE-2016-6187 \\ 2143 | CVE-2015-2666 \\ 2144 | CVE-2014-9410 \\ 2145 | CVE-2014-8884 \\ 2146 | CVE-2014-6184 \\ 2147 | CVE-2014-5471 \\ 2148 | CVE-2014-3181 \\ 2149 | CVE-2014-0049 \\ 2150 | CVE-2013-4588 \\ 2151 | CVE-2013-1928 \\ 2152 | CVE-2012-4530 \\ 2153 | CVE-2012-3364 \\ 2154 | CVE-2011-4913 \\ 2155 | CVE-2011-4330 \\ 2156 | CVE-2011-1180 \\ 2157 | CVE-2010-3858 \\ 2158 | CVE-2010-3848 \\ 2159 | CVE-2010-1451 \\ 2160 | CVE-2009-4020 \\ 2161 | CVE-2009-2584 \\ 2162 | CVE-2009-2406 \\ 2163 | CVE-2008-5025 \\ 2164 | CVE-2008-3911 \\ 2165 | CVE-2007-3105 \\ 2166 | 2167 | #+LATEX: \end{multicols} 2168 | *** Heap Overflow 2169 | #+LATEX: \begin{multicols}{3} 2170 | #+LATEX: \noindent 2171 | 2172 | CVE-2016-7425 \\ 2173 | CVE-2016-6516 \\ 2174 | CVE-2016-5829 \\ 2175 | CVE-2016-5343 \\ 2176 | CVE-2016-5342 \\ 2177 | CVE-2016-4568 \\ 2178 | CVE-2016-3134 \\ 2179 | CVE-2015-5156 \\ 2180 | CVE-2014-6416 \\ 2181 | CVE-2014-4323 \\ 2182 | CVE-2014-4322 \\ 2183 | CVE-2014-3186 \\ 2184 | CVE-2014-3185 \\ 2185 | CVE-2014-3184 \\ 2186 | CVE-2014-3183 \\ 2187 | CVE-2013-6382 \\ 2188 | CVE-2013-6381 \\ 2189 | CVE-2013-4591 \\ 2190 | CVE-2013-4514 \\ 2191 | CVE-2013-4513 \\ 2192 | CVE-2013-4512 \\ 2193 | CVE-2013-4387 \\ 2194 | CVE-2013-2894 \\ 2195 | CVE-2013-2893 \\ 2196 | CVE-2013-2892 \\ 2197 | CVE-2013-2891 \\ 2198 | CVE-2013-2890 \\ 2199 | CVE-2013-2889 \\ 2200 | CVE-2013-2850 \\ 2201 | CVE-2013-1929 \\ 2202 | CVE-2013-1860 \\ 2203 | CVE-2013-1796 \\ 2204 | CVE-2013-1773 \\ 2205 | CVE-2013-1772 \\ 2206 | CVE-2013-0913 \\ 2207 | CVE-2012-3400 \\ 2208 | CVE-2012-2319 \\ 2209 | CVE-2012-2137 \\ 2210 | CVE-2012-2136 \\ 2211 | CVE-2012-2119 \\ 2212 | CVE-2011-4077 \\ 2213 | CVE-2011-3359 \\ 2214 | CVE-2011-3353 \\ 2215 | CVE-2011-2700 \\ 2216 | CVE-2011-2534 \\ 2217 | CVE-2011-2517 \\ 2218 | CVE-2011-2182 \\ 2219 | CVE-2011-1776 \\ 2220 | CVE-2011-1759 \\ 2221 | CVE-2011-1577 \\ 2222 | CVE-2011-1017 \\ 2223 | CVE-2011-1010 \\ 2224 | CVE-2011-0712 \\ 2225 | CVE-2010-4656 \\ 2226 | CVE-2010-4650 \\ 2227 | CVE-2010-4527 \\ 2228 | CVE-2010-3874 \\ 2229 | CVE-2010-3873 \\ 2230 | CVE-2010-3084 \\ 2231 | CVE-2010-2492 \\ 2232 | CVE-2010-1451 \\ 2233 | CVE-2010-1436 \\ 2234 | CVE-2010-1084 \\ 2235 | CVE-2009-4005 \\ 2236 | CVE-2009-4004 \\ 2237 | CVE-2009-3234 \\ 2238 | CVE-2009-2407 \\ 2239 | CVE-2009-1633 \\ 2240 | CVE-2009-1439 \\ 2241 | CVE-2009-1389 \\ 2242 | CVE-2009-0065 \\ 2243 | CVE-2008-5702 \\ 2244 | CVE-2008-5134 \\ 2245 | CVE-2008-4933 \\ 2246 | CVE-2008-4395 \\ 2247 | CVE-2008-3915 \\ 2248 | CVE-2008-3496 \\ 2249 | CVE-2008-3247 \\ 2250 | CVE-2008-2750 \\ 2251 | CVE-2008-0352 \\ 2252 | CVE-2007-6151 \\ 2253 | CVE-2007-6063 \\ 2254 | CVE-2007-5904 \\ 2255 | CVE-2007-1217 \\ 2256 | CVE-2016-4997 \\ 2257 | CVE-2013-4387 \\ 2258 | CVE-2010-1084 \\ 2259 | 2260 | #+LATEX: \end{multicols} 2261 | *** Buffer Overread 2262 | #+LATEX: \begin{multicols}{3} 2263 | #+LATEX: \noindent 2264 | 2265 | CVE-2016-5696 \\ 2266 | CVE-2013-4299 \\ 2267 | CVE-2013-4350 \\ 2268 | CVE-2013-1798 \\ 2269 | CVE-2012-4467 \\ 2270 | CVE-2011-1079 \\ 2271 | CVE-2010-4563 \\ 2272 | CVE-2010-2943 \\ 2273 | CVE-2010-0003 \\ 2274 | CVE-2016-2117 \\ 2275 | CVE-2009-2910 \\ 2276 | CVE-2008-2729 \\ 2277 | CVE-2007-6206 \\ 2278 | CVE-2012-0957 \\ 2279 | CVE-2011-1162 \\ 2280 | CVE-2011-1020 \\ 2281 | CVE-2011-0710 \\ 2282 | CVE-2010-4565 \\ 2283 | CVE-2010-4563 \\ 2284 | CVE-2010-1636 \\ 2285 | CVE-2010-0415 \\ 2286 | CVE-2014-2038 \\ 2287 | CVE-2014-1690 \\ 2288 | CVE-2013-4579 \\ 2289 | CVE-2013-4350 \\ 2290 | CVE-2013-2898 \\ 2291 | CVE-2013-2546 \\ 2292 | CVE-2016-4913 \\ 2293 | CVE-2014-8709 \\ 2294 | CVE-2013-2164 \\ 2295 | CVE-2013-0349 \\ 2296 | CVE-2013-0343 \\ 2297 | CVE-2013-0160 \\ 2298 | CVE-2011-2909 \\ 2299 | CVE-2016-5243 \\ 2300 | CVE-2016-2383 \\ 2301 | CVE-2016-2117 \\ 2302 | CVE-2016-0823 \\ 2303 | CVE-2015-8374 \\ 2304 | CVE-2015-2042 \\ 2305 | CVE-2015-2041 \\ 2306 | CVE-2014-9731 \\ 2307 | CVE-2014-9585 \\ 2308 | CVE-2014-9419 \\ 2309 | CVE-2014-8709 \\ 2310 | CVE-2014-8133 \\ 2311 | CVE-2016-6480 \\ 2312 | CVE-2016-6156 \\ 2313 | CVE-2013-7027 \\ 2314 | CVE-2016-2064 \\ 2315 | CVE-2014-9728 \\ 2316 | CVE-2007-2172 \\ 2317 | CVE-2014-3985 \\ 2318 | CVE-2007-1734 \\ 2319 | CVE-2009-0787 \\ 2320 | CVE-2008-4445 \\ 2321 | CVE-2011-0463 \\ 2322 | CVE-2016-7917 \\ 2323 | CVE-2016-7915 \\ 2324 | CVE-2014-7825 \\ 2325 | CVE-2014-3985 \\ 2326 | CVE-2016-7917 \\ 2327 | CVE-2016-4998 \\ 2328 | CVE-2015-8575 \\ 2329 | CVE-2015-8569 \\ 2330 | CVE-2013-2548 \\ 2331 | CVE-2013-7266 \\ 2332 | CVE-2012-6536 \\ 2333 | CVE-2014-9584 \\ 2334 | CVE-2013-1828 \\ 2335 | CVE-2007-4571 \\ 2336 | CVE-2014-9903 \\ 2337 | CVE-2015-1593 \\ 2338 | CVE-2007-4571 \\ 2339 | 2340 | #+LATEX: \end{multicols} 2341 | *** Integer Overflow 2342 | #+LATEX: \begin{multicols}{3} 2343 | #+LATEX: \noindent 2344 | 2345 | CVE-2016-9084 \\ 2346 | CVE-2016-3135 \\ 2347 | CVE-2016-0758 \\ 2348 | CVE-2015-8830 \\ 2349 | CVE-2015-5707 \\ 2350 | CVE-2015-4167 \\ 2351 | CVE-2015-4167 \\ 2352 | CVE-2014-9904 \\ 2353 | CVE-2014-7975 \\ 2354 | CVE-2014-4656 \\ 2355 | CVE-2014-4656 \\ 2356 | CVE-2014-4655 \\ 2357 | CVE-2014-4655 \\ 2358 | CVE-2014-4611 \\ 2359 | CVE-2014-4611 \\ 2360 | CVE-2014-4611 \\ 2361 | CVE-2014-4608 \\ 2362 | CVE-2014-4608 \\ 2363 | CVE-2014-2889 \\ 2364 | CVE-2013-4511 \\ 2365 | CVE-2013-2596 \\ 2366 | CVE-2012-6703 \\ 2367 | CVE-2012-2383 \\ 2368 | CVE-2012-0044 \\ 2369 | CVE-2012-0038 \\ 2370 | CVE-2011-4611 \\ 2371 | CVE-2011-4097 \\ 2372 | CVE-2011-2496 \\ 2373 | CVE-2011-2022 \\ 2374 | CVE-2011-1759 \\ 2375 | CVE-2011-1746 \\ 2376 | CVE-2011-1745 \\ 2377 | CVE-2011-1593 \\ 2378 | CVE-2011-1494 \\ 2379 | CVE-2010-4649 \\ 2380 | CVE-2010-4175 \\ 2381 | CVE-2010-4162 \\ 2382 | CVE-2010-4160 \\ 2383 | CVE-2010-4157 \\ 2384 | CVE-2010-3865 \\ 2385 | CVE-2010-3442 \\ 2386 | CVE-2010-3081 \\ 2387 | CVE-2010-3067 \\ 2388 | CVE-2010-3015 \\ 2389 | CVE-2010-2959 \\ 2390 | CVE-2010-2538 \\ 2391 | CVE-2010-2478 \\ 2392 | CVE-2009-3638 \\ 2393 | CVE-2009-1265 \\ 2394 | CVE-2009-1265 \\ 2395 | CVE-2008-3526 \\ 2396 | CVE-2008-3276 \\ 2397 | CVE-2008-2826 \\ 2398 | CVE-2008-2358 \\ 2399 | CVE-2007-5966 \\ 2400 | 2401 | 2402 | #+LATEX: \end{multicols} 2403 | *** Integer Underflow 2404 | #+LATEX: \begin{multicols}{3} 2405 | #+LATEX: \noindent 2406 | 2407 | CVE-2011-1770 \\ 2408 | CVE-2010-4164 \\ 2409 | CVE-2009-2846 \\ 2410 | CVE-2009-1385 \\ 2411 | CVE-2007-4997 \\ 2412 | CVE-2011-4913 \\ 2413 | CVE-2007-2875 \\ 2414 | CVE-2011-1476 \\ 2415 | CVE-2010-4529 \\ 2416 | CVE-2014-3144 \\ 2417 | 2418 | #+LATEX: \end{multicols} 2419 | *** Integer Signedness 2420 | #+LATEX: \begin{multicols}{3} 2421 | #+LATEX: \noindent 2422 | 2423 | 2424 | CVE-2011-1013 \\ 2425 | CVE-2011-0521 \\ 2426 | CVE-2010-3859 \\ 2427 | CVE-2010-3437 \\ 2428 | CVE-2010-3301 \\ 2429 | CVE-2009-3280 \\ 2430 | CVE-2007-1730 \\ 2431 | CVE-2007-4573 \\ 2432 | CVE-2009-2909 \\ 2433 | CVE-2011-2906 \\ 2434 | CVE-2011-2209 \\ 2435 | CVE-2011-2208 \\ 2436 | CVE-2010-3310 \\ 2437 | CVE-2009-0029 \\ 2438 | 2439 | #+LATEX: \end{multicols} 2440 | *** Refcount Overflow 2441 | #+LATEX: \begin{multicols}{3} 2442 | #+LATEX: \noindent 2443 | 2444 | CVE-2016-4558 \\ 2445 | CVE-2014-0205 \\ 2446 | CVE-2014-5045 \\ 2447 | CVE-2016-0728 \\ 2448 | CVE-2014-2851 \\ 2449 | CVE-2012-2127 \\ 2450 | CVE-2009-3624 \\ 2451 | CVE-2008-3077 \\ 2452 | CVE-2012-2127 \\ 2453 | CVE-2010-0623 \\ 2454 | CVE-2013-4483 \\ 2455 | 2456 | #+LATEX: \end{multicols} 2457 | *** Array Index Errors 2458 | #+LATEX: \begin{multicols}{3} 2459 | #+LATEX: \noindent 2460 | 2461 | CVE-2009-3080 \\ 2462 | CVE-2013-4587 \\ 2463 | CVE-2013-2888 \\ 2464 | CVE-2011-1477 \\ 2465 | CVE-2011-1493 \\ 2466 | CVE-2016-0774 \\ 2467 | CVE-2016-3713 \\ 2468 | CVE-2013-1763 \\ 2469 | CVE-2011-1169 \\ 2470 | CVE-2014-3182 \\ 2471 | CVE-2008-5701 \\ 2472 | CVE-2015-4036 \\ 2473 | CVE-2011-2695 \\ 2474 | CVE-2008-3535 \\ 2475 | CVE-2013-4247 \\ 2476 | CVE-2008-1673 \\ 2477 | CVE-2009-1046 \\ 2478 | CVE-2014-9683 \\ 2479 | CVE-2015-3214 \\ 2480 | 2481 | #+LATEX: \end{multicols} 2482 | ** NULL Dereference 2483 | #+LATEX: \begin{multicols}{3} 2484 | #+LATEX: \noindent 2485 | 2486 | CVE-2015-8746 \\ 2487 | CVE-2003-1604 \\ 2488 | CVE-2015-8543 \\ 2489 | CVE-2015-7990 \\ 2490 | CVE-2015-6937 \\ 2491 | CVE-2014-8173 \\ 2492 | CVE-2014-7841 \\ 2493 | CVE-2014-7145 \\ 2494 | CVE-2011-2519 \\ 2495 | CVE-2011-0695 \\ 2496 | CVE-2011-0709 \\ 2497 | CVE-2010-4263 \\ 2498 | CVE-2010-4342 \\ 2499 | CVE-2010-2960 \\ 2500 | CVE-2010-2798 \\ 2501 | CVE-2010-1643 \\ 2502 | CVE-2010-0437 \\ 2503 | CVE-2010-0006 \\ 2504 | CVE-2014-3631 \\ 2505 | CVE-2014-3535 \\ 2506 | CVE-2014-5077 \\ 2507 | CVE-2014-0101 \\ 2508 | CVE-2013-4254 \\ 2509 | CVE-2013-1059 \\ 2510 | CVE-2013-2206 \\ 2511 | CVE-2011-2482 \\ 2512 | CVE-2011-2942 \\ 2513 | CVE-2013-3301 \\ 2514 | CVE-2013-1827 \\ 2515 | CVE-2013-1826 \\ 2516 | CVE-2013-0313 \\ 2517 | CVE-2013-0310 \\ 2518 | CVE-2012-2744 \\ 2519 | CVE-2012-1097 \\ 2520 | CVE-2011-2525 \\ 2521 | CVE-2011-1478 \\ 2522 | CVE-2011-1076 \\ 2523 | CVE-2011-1093 \\ 2524 | CVE-2009-4308 \\ 2525 | CVE-2009-3726 \\ 2526 | CVE-2009-3623 \\ 2527 | CVE-2009-2844 \\ 2528 | CVE-2009-2768 \\ 2529 | CVE-2009-2767 \\ 2530 | CVE-2009-2698 \\ 2531 | CVE-2009-2695 \\ 2532 | CVE-2009-1897 \\ 2533 | CVE-2009-1360 \\ 2534 | CVE-2009-1298 \\ 2535 | CVE-2008-5033 \\ 2536 | CVE-2008-3792 \\ 2537 | CVE-2007-6694 \\ 2538 | CVE-2007-5501 \\ 2539 | CVE-2007-4567 \\ 2540 | CVE-2007-3642 \\ 2541 | CVE-2007-2876 \\ 2542 | CVE-2007-1000 \\ 2543 | CVE-2011-1927 \\ 2544 | CVE-2015-8955 \\ 2545 | CVE-2016-4951 \\ 2546 | CVE-2013-2895 \\ 2547 | CVE-2009-4138 \\ 2548 | CVE-2009-4021 \\ 2549 | CVE-2009-3640 \\ 2550 | CVE-2009-3620 \\ 2551 | CVE-2009-3043 \\ 2552 | CVE-2009-2908 \\ 2553 | CVE-2009-2849 \\ 2554 | CVE-2009-2287 \\ 2555 | CVE-2009-0748 \\ 2556 | CVE-2008-3686 \\ 2557 | CVE-2008-1514 \\ 2558 | CVE-2007-3731 \\ 2559 | CVE-2007-3104 \\ 2560 | CVE-2007-1496 \\ 2561 | CVE-2007-1388 \\ 2562 | CVE-2007-0822 \\ 2563 | CVE-2007-0006 \\ 2564 | CVE-2006-7203 \\ 2565 | CVE-2012-5517 \\ 2566 | CVE-2012-1601 \\ 2567 | CVE-2011-4594 \\ 2568 | CVE-2011-4325 \\ 2569 | CVE-2011-4110 \\ 2570 | CVE-2011-4081 \\ 2571 | CVE-2011-2928 \\ 2572 | CVE-2011-2518 \\ 2573 | CVE-2011-2203 \\ 2574 | CVE-2011-2183 \\ 2575 | CVE-2011-1927 \\ 2576 | CVE-2011-1771 \\ 2577 | CVE-2011-1748 \\ 2578 | CVE-2011-1598 \\ 2579 | CVE-2010-4242 \\ 2580 | CVE-2010-3849 \\ 2581 | CVE-2010-3079 \\ 2582 | CVE-2010-3066 \\ 2583 | CVE-2010-2954 \\ 2584 | CVE-2010-1488 \\ 2585 | CVE-2010-1187 \\ 2586 | CVE-2010-1148 \\ 2587 | CVE-2010-0622 \\ 2588 | CVE-2009-4895 \\ 2589 | CVE-2008-7256 \\ 2590 | CVE-2014-2739 \\ 2591 | CVE-2014-2678 \\ 2592 | CVE-2014-1874 \\ 2593 | CVE-2013-7339 \\ 2594 | CVE-2013-6432 \\ 2595 | CVE-2013-6431 \\ 2596 | CVE-2013-6380 \\ 2597 | CVE-2013-5634 \\ 2598 | CVE-2013-3302 \\ 2599 | CVE-2013-2899 \\ 2600 | CVE-2013-2897 \\ 2601 | CVE-2013-2896 \\ 2602 | CVE-2009-3288 \\ 2603 | CVE-2009-3288 \\ 2604 | CVE-2013-1819 \\ 2605 | CVE-2013-1774 \\ 2606 | CVE-2012-6647 \\ 2607 | CVE-2011-3619 \\ 2608 | CVE-2016-6327 \\ 2609 | CVE-2016-4581 \\ 2610 | CVE-2016-3140 \\ 2611 | CVE-2016-3139 \\ 2612 | CVE-2016-3138 \\ 2613 | CVE-2016-3137 \\ 2614 | CVE-2016-3136 \\ 2615 | CVE-2016-3070 \\ 2616 | CVE-2016-2782 \\ 2617 | CVE-2016-2543 \\ 2618 | CVE-2016-2188 \\ 2619 | CVE-2016-2187 \\ 2620 | CVE-2016-2186 \\ 2621 | CVE-2016-2185 \\ 2622 | CVE-2015-8970 \\ 2623 | CVE-2015-8956 \\ 2624 | CVE-2015-8746 \\ 2625 | CVE-2015-8551 \\ 2626 | CVE-2015-8324 \\ 2627 | CVE-2015-5257 \\ 2628 | CVE-2015-4692 \\ 2629 | CVE-2014-9715 \\ 2630 | CVE-2014-8481 \\ 2631 | CVE-2014-8480 \\ 2632 | CVE-2014-7841 \\ 2633 | CVE-2014-7207 \\ 2634 | CVE-2011-5321 \\ 2635 | CVE-2015-7799 \\ 2636 | CVE-2015-7566 \\ 2637 | CVE-2015-7550 \\ 2638 | CVE-2015-7515 \\ 2639 | CVE-2015-3288 \\ 2640 | 2641 | 2642 | #+LATEX: \end{multicols} 2643 | ** Format String 2644 | #+LATEX: \begin{multicols}{3} 2645 | #+LATEX: \noindent 2646 | 2647 | CVE-2013-2851 \\ 2648 | CVE-2013-2852 \\ 2649 | CVE-2013-1848 \\ 2650 | 2651 | 2652 | #+LATEX: \end{multicols} 2653 | ** Missing Permission Check 2654 | #+LATEX: \begin{multicols}{3} 2655 | #+LATEX: \noindent 2656 | 2657 | CVE-2011-2905 \\ 2658 | CVE-2012-2123 \\ 2659 | CVE-2009-4536 \\ 2660 | CVE-2009-4131 \\ 2661 | CVE-2009-3725 \\ 2662 | CVE-2009-3722 \\ 2663 | CVE-2009-3290 \\ 2664 | CVE-2008-3525 \\ 2665 | CVE-2008-2931 \\ 2666 | CVE-2007-4998 \\ 2667 | CVE-2007-3851 \\ 2668 | CVE-2007-1497 \\ 2669 | CVE-2016-3699 \\ 2670 | CVE-2016-5340 \\ 2671 | CVE-2016-1576 \\ 2672 | CVE-2012-6689 \\ 2673 | CVE-2016-1575 \\ 2674 | CVE-2015-8660 \\ 2675 | CVE-2015-2925 \\ 2676 | CVE-2014-8160 \\ 2677 | CVE-2014-5207 \\ 2678 | CVE-2014-5206 \\ 2679 | CVE-2014-3534 \\ 2680 | CVE-2014-4943 \\ 2681 | CVE-2014-4014 \\ 2682 | CVE-2013-6383 \\ 2683 | CVE-2013-4300 \\ 2684 | CVE-2013-2094 \\ 2685 | CVE-2013-1979 \\ 2686 | CVE-2013-1858 \\ 2687 | CVE-2013-0268 \\ 2688 | CVE-2012-4444 \\ 2689 | CVE-2012-0028 \\ 2690 | CVE-2012-0056 \\ 2691 | CVE-2010-4347 \\ 2692 | CVE-2010-2963 \\ 2693 | CVE-2010-2962 \\ 2694 | CVE-2010-2537 \\ 2695 | CVE-2010-1146 \\ 2696 | CVE-2010-0298 \\ 2697 | CVE-2015-1593 \\ 2698 | CVE-2011-1016 \\ 2699 | CVE-2010-4258 \\ 2700 | CVE-2009-1895 \\ 2701 | CVE-2013-1943 \\ 2702 | CVE-2013-0228 \\ 2703 | CVE-2009-3286 \\ 2704 | CVE-2009-2848 \\ 2705 | CVE-2009-1883 \\ 2706 | CVE-2009-1630 \\ 2707 | CVE-2009-1338 \\ 2708 | CVE-2009-1337 \\ 2709 | CVE-2009-1184 \\ 2710 | CVE-2009-1072 \\ 2711 | CVE-2009-0835 \\ 2712 | CVE-2009-0834 \\ 2713 | CVE-2009-0675 \\ 2714 | CVE-2009-0028 \\ 2715 | CVE-2008-4554 \\ 2716 | CVE-2008-4210 \\ 2717 | CVE-2008-4113 \\ 2718 | CVE-2008-3833 \\ 2719 | CVE-2008-3527 \\ 2720 | CVE-2008-1294 \\ 2721 | CVE-2008-0163 \\ 2722 | CVE-2008-0001 \\ 2723 | CVE-2007-6434 \\ 2724 | CVE-2007-3850 \\ 2725 | CVE-2007-3848 \\ 2726 | CVE-2007-3843 \\ 2727 | CVE-2007-3740 \\ 2728 | CVE-2007-2480 \\ 2729 | CVE-2007-1497 \\ 2730 | CVE-2007-0958 \\ 2731 | CVE-2012-5532 \\ 2732 | CVE-2012-4444 \\ 2733 | CVE-2012-3520 \\ 2734 | CVE-2012-2669 \\ 2735 | CVE-2012-2313 \\ 2736 | CVE-2011-4127 \\ 2737 | CVE-2011-4112 \\ 2738 | CVE-2011-4080 \\ 2739 | CVE-2011-2495 \\ 2740 | CVE-2011-2494 \\ 2741 | CVE-2011-2484 \\ 2742 | CVE-2011-0726 \\ 2743 | CVE-2011-0006 \\ 2744 | CVE-2010-4648 \\ 2745 | CVE-2010-4346 \\ 2746 | CVE-2010-3850 \\ 2747 | CVE-2010-3448 \\ 2748 | CVE-2010-2946 \\ 2749 | CVE-2010-2524 \\ 2750 | CVE-2010-2226 \\ 2751 | CVE-2010-2071 \\ 2752 | CVE-2010-2066 \\ 2753 | CVE-2010-1641 \\ 2754 | CVE-2014-1738 \\ 2755 | CVE-2014-0181 \\ 2756 | CVE-2013-4270 \\ 2757 | CVE-2013-2930 \\ 2758 | CVE-2013-2929 \\ 2759 | CVE-2013-1959 \\ 2760 | CVE-2013-1958 \\ 2761 | CVE-2013-1957 \\ 2762 | CVE-2013-1956 \\ 2763 | CVE-2012-4542 \\ 2764 | CVE-2011-4347 \\ 2765 | CVE-2011-1585 \\ 2766 | CVE-2011-1182 \\ 2767 | CVE-2011-1019 \\ 2768 | CVE-2016-7097 \\ 2769 | CVE-2016-3672 \\ 2770 | CVE-2016-2854 \\ 2771 | CVE-2016-2853 \\ 2772 | CVE-2016-2550 \\ 2773 | CVE-2016-1237 \\ 2774 | CVE-2016-0821 \\ 2775 | CVE-2015-8944 \\ 2776 | CVE-2015-4176 \\ 2777 | CVE-2015-2830 \\ 2778 | CVE-2015-0239 \\ 2779 | CVE-2014-9717 \\ 2780 | CVE-2014-8989 \\ 2781 | CVE-2014-8160 \\ 2782 | CVE-2014-7975 \\ 2783 | CVE-2014-4654 \\ 2784 | CVE-2014-3690 \\ 2785 | CVE-2013-7421 \\ 2786 | CVE-2013-6335 \\ 2787 | CVE-2013-4312 \\ 2788 | CVE-2010-1446 \\ 2789 | CVE-2011-1021 \\ 2790 | 2791 | #+LATEX: \end{multicols} 2792 | ** Race Conditions 2793 | #+LATEX: \begin{multicols}{3} 2794 | #+LATEX: \noindent 2795 | 2796 | CVE-2009-1527 \\ 2797 | CVE-2008-5182 \\ 2798 | CVE-2008-1669 \\ 2799 | CVE-2008-1375 \\ 2800 | CVE-2007-0997 \\ 2801 | CVE-2014-0196 \\ 2802 | CVE-2015-3339 \\ 2803 | CVE-2014-4699 \\ 2804 | CVE-2013-0871 \\ 2805 | CVE-2016-5728 \\ 2806 | CVE-2016-2059 \\ 2807 | CVE-2009-3547 \\ 2808 | CVE-2014-9529 \\ 2809 | CVE-2015-0572 \\ 2810 | CVE-2014-2672 \\ 2811 | CVE-2011-4348 \\ 2812 | CVE-2012-3552 \\ 2813 | CVE-2010-2653 \\ 2814 | CVE-2009-4027 \\ 2815 | CVE-2014-9710 \\ 2816 | CVE-2009-2691 \\ 2817 | CVE-2009-1961 \\ 2818 | CVE-2009-1388 \\ 2819 | CVE-2009-1243 \\ 2820 | CVE-2009-0935 \\ 2821 | CVE-2008-4307 \\ 2822 | CVE-2008-4302 \\ 2823 | CVE-2008-2365 \\ 2824 | CVE-2012-4508 \\ 2825 | CVE-2012-2373 \\ 2826 | CVE-2011-1833 \\ 2827 | CVE-2011-1082 \\ 2828 | CVE-2010-4248 \\ 2829 | CVE-2010-4161 \\ 2830 | CVE-2010-1437 \\ 2831 | CVE-2014-2706 \\ 2832 | CVE-2015-7613 \\ 2833 | CVE-2013-1792 \\ 2834 | CVE-2016-7916 \\ 2835 | CVE-2016-6136 \\ 2836 | CVE-2016-6130 \\ 2837 | CVE-2016-2549 \\ 2838 | CVE-2016-2545 \\ 2839 | CVE-2016-2069 \\ 2840 | CVE-2015-8839 \\ 2841 | CVE-2015-8767 \\ 2842 | CVE-2015-4170 \\ 2843 | CVE-2015-3212 \\ 2844 | CVE-2015-1420 \\ 2845 | CVE-2014-8559 \\ 2846 | CVE-2014-8086 \\ 2847 | CVE-2014-7842 \\ 2848 | CVE-2014-4652 \\ 2849 | CVE-2014-3611 \\ 2850 | CVE-2010-5313 \\ 2851 | CVE-2014-3122 \\ 2852 | 2853 | #+LATEX: \end{multicols} 2854 | ** Miscellaneous 2855 | #+LATEX: \begin{multicols}{3} 2856 | 2857 | *** Infinite Loop 2858 | #+LATEX: \noindent 2859 | 2860 | CVE-2008-5079 \\ 2861 | CVE-2007-6712 \\ 2862 | CVE-2007-1861 \\ 2863 | CVE-2011-2213 \\ 2864 | CVE-2010-3880 \\ 2865 | CVE-2013-4348 \\ 2866 | CVE-2013-0290 \\ 2867 | CVE-2015-8785 \\ 2868 | CVE-2015-6526 \\ 2869 | CVE-2014-9420 \\ 2870 | CVE-2014-6410 \\ 2871 | CVE-2008-7316 \\ 2872 | 2873 | 2874 | #+LATEX: \end{multicols} 2875 | *** Memory Leak 2876 | #+LATEX: \begin{multicols}{3} 2877 | #+LATEX: \noindent 2878 | 2879 | CVE-2009-2903 \\ 2880 | CVE-2008-2136 \\ 2881 | CVE-2007-6417 \\ 2882 | CVE-2013-0217 \\ 2883 | CVE-2014-3688 \\ 2884 | CVE-2014-2309 \\ 2885 | CVE-2009-0031 \\ 2886 | CVE-2007-2525 \\ 2887 | CVE-2008-2372 \\ 2888 | CVE-2012-2390 \\ 2889 | CVE-2012-2121 \\ 2890 | CVE-2010-4250 \\ 2891 | CVE-2013-4592 \\ 2892 | CVE-2013-4205 \\ 2893 | CVE-2016-5400 \\ 2894 | CVE-2015-1339 \\ 2895 | CVE-2015-1333 \\ 2896 | 2897 | #+LATEX: \end{multicols} 2898 | *** Divide-by-zero 2899 | #+LATEX: \begin{multicols}{3} 2900 | #+LATEX: \noindent 2901 | 2902 | CVE-2009-4307 \\ 2903 | CVE-2016-2070 \\ 2904 | CVE-2015-4003 \\ 2905 | CVE-2013-6367 \\ 2906 | CVE-2012-0207 \\ 2907 | CVE-2010-1085 \\ 2908 | CVE-2012-4565 \\ 2909 | CVE-2011-1012 \\ 2910 | CVE-2010-4165 \\ 2911 | CVE-2015-7513 \\ 2912 | 2913 | #+LATEX: \end{multicols} 2914 | *** Cryptographic Bugs 2915 | #+LATEX: \begin{multicols}{3} 2916 | #+LATEX: \noindent 2917 | 2918 | CVE-2013-4345 \\ 2919 | CVE-2009-3238 \\ 2920 | CVE-2007-4311 \\ 2921 | CVE-2007-2451 \\ 2922 | CVE-2014-7284 \\ 2923 | CVE-2007-2453 \\ 2924 | CVE-2007-2451 \\ 2925 | CVE-2016-2085 \\ 2926 | 2927 | #+LATEX: \end{multicols} 2928 | *** Length Calculation bugs 2929 | #+LATEX: \begin{multicols}{3} 2930 | #+LATEX: \noindent 2931 | 2932 | CVE-2014-0077 \\ 2933 | CVE-2014-0069 \\ 2934 | CVE-2013-6763 \\ 2935 | CVE-2011-4604 \\ 2936 | CVE-2015-2686 \\ 2937 | CVE-2011-4914 \\ 2938 | CVE-2011-1495 \\ 2939 | CVE-2015-1465 \\ 2940 | CVE-2014-9428 \\ 2941 | CVE-2011-1573 \\ 2942 | CVE-2009-4537 \\ 2943 | CVE-2008-4618 \\ 2944 | CVE-2008-3272 \\ 2945 | CVE-2008-1675 \\ 2946 | CVE-2008-0007 \\ 2947 | CVE-2009-0269 \\ 2948 | CVE-2011-1573 \\ 2949 | CVE-2015-8019 \\ 2950 | CVE-2013-2128 \\ 2951 | 2952 | #+LATEX: \end{multicols} 2953 | *** Other 2954 | #+LATEX: \begin{multicols}{3} 2955 | #+LATEX: \noindent 2956 | 2957 | CVE-2016-8666 \\ 2958 | CVE-2016-7039 \\ 2959 | CVE-2016-5828 \\ 2960 | CVE-2016-2053 \\ 2961 | CVE-2014-3687 \\ 2962 | CVE-2014-3673 \\ 2963 | CVE-2014-6418 \\ 2964 | CVE-2014-4667 \\ 2965 | CVE-2014-0155 \\ 2966 | CVE-2014-0102 \\ 2967 | CVE-2012-6638 \\ 2968 | CVE-2013-6376 \\ 2969 | CVE-2013-4563 \\ 2970 | CVE-2013-4125 \\ 2971 | CVE-2013-0216 \\ 2972 | CVE-2012-3412 \\ 2973 | CVE-2011-1768 \\ 2974 | CVE-2011-1767 \\ 2975 | CVE-2012-1179 \\ 2976 | CVE-2011-4326 \\ 2977 | CVE-2011-2723 \\ 2978 | CVE-2010-4805 \\ 2979 | CVE-2010-4251 \\ 2980 | CVE-2010-3432 \\ 2981 | CVE-2010-2248 \\ 2982 | CVE-2010-1173 \\ 2983 | CVE-2010-1086 \\ 2984 | CVE-2010-0008 \\ 2985 | CVE-2005-4886 \\ 2986 | CVE-2009-4272 \\ 2987 | CVE-2009-4026 \\ 2988 | CVE-2009-0778 \\ 2989 | CVE-2008-4609 \\ 2990 | CVE-2008-4576 \\ 2991 | CVE-2007-3380 \\ 2992 | CVE-2007-2764 \\ 2993 | CVE-2006-6535 \\ 2994 | CVE-2009-4031 \\ 2995 | CVE-2009-3613 \\ 2996 | CVE-2008-4934 \\ 2997 | CVE-2015-8215 \\ 2998 | CVE-2009-4410 \\ 2999 | CVE-2009-3888 \\ 3000 | CVE-2009-3621 \\ 3001 | CVE-2009-1242 \\ 3002 | CVE-2009-0859 \\ 3003 | CVE-2009-0747 \\ 3004 | CVE-2009-0746 \\ 3005 | CVE-2009-0745 \\ 3006 | CVE-2009-0322 \\ 3007 | CVE-2008-6107 \\ 3008 | CVE-2008-5713 \\ 3009 | CVE-2008-5700 \\ 3010 | CVE-2008-5395 \\ 3011 | CVE-2008-5300 \\ 3012 | CVE-2008-5029 \\ 3013 | CVE-2008-4410 \\ 3014 | CVE-2008-3831 \\ 3015 | CVE-2008-3534 \\ 3016 | CVE-2008-3528 \\ 3017 | CVE-2008-3275 \\ 3018 | CVE-2008-2148 \\ 3019 | CVE-2008-2137 \\ 3020 | CVE-2007-6716 \\ 3021 | CVE-2007-5500 \\ 3022 | CVE-2007-5498 \\ 3023 | CVE-2007-5093 \\ 3024 | CVE-2007-5087 \\ 3025 | CVE-2007-4133 \\ 3026 | CVE-2007-3720 \\ 3027 | CVE-2007-3719 \\ 3028 | CVE-2007-3513 \\ 3029 | CVE-2007-3380 \\ 3030 | CVE-2007-3107 \\ 3031 | CVE-2007-2878 \\ 3032 | CVE-2007-0771 \\ 3033 | CVE-2006-7051 \\ 3034 | CVE-2006-6921 \\ 3035 | CVE-2012-3375 \\ 3036 | CVE-2012-2375 \\ 3037 | CVE-2012-1090 \\ 3038 | CVE-2012-0879 \\ 3039 | CVE-2012-0058 \\ 3040 | CVE-2012-0045 \\ 3041 | CVE-2011-4621 \\ 3042 | CVE-2011-4324 \\ 3043 | CVE-2011-4132 \\ 3044 | CVE-2011-4131 \\ 3045 | CVE-2011-4086 \\ 3046 | CVE-2011-3637 \\ 3047 | CVE-2011-3209 \\ 3048 | CVE-2011-2918 \\ 3049 | CVE-2011-2689 \\ 3050 | CVE-2011-2521 \\ 3051 | CVE-2011-2493 \\ 3052 | CVE-2011-1747 \\ 3053 | CVE-2011-1581 \\ 3054 | CVE-2011-1090 \\ 3055 | CVE-2011-1083 \\ 3056 | CVE-2011-1023 \\ 3057 | CVE-2011-0716 \\ 3058 | CVE-2010-4668 \\ 3059 | CVE-2010-4343 \\ 3060 | CVE-2010-4256 \\ 3061 | CVE-2010-4249 \\ 3062 | CVE-2010-4163 \\ 3063 | CVE-2010-3698 \\ 3064 | CVE-2010-3086 \\ 3065 | CVE-2010-2938 \\ 3066 | CVE-2010-0727 \\ 3067 | CVE-2010-0410 \\ 3068 | CVE-2010-0307 \\ 3069 | CVE-2009-4271 \\ 3070 | CVE-2007-6733 \\ 3071 | CVE-2014-3145 \\ 3072 | CVE-2014-2673 \\ 3073 | CVE-2014-2039 \\ 3074 | CVE-2014-1438 \\ 3075 | CVE-2013-6378 \\ 3076 | CVE-2013-4220 \\ 3077 | CVE-2013-4163 \\ 3078 | CVE-2013-4162 \\ 3079 | CVE-2013-4129 \\ 3080 | CVE-2013-2232 \\ 3081 | CVE-2013-2146 \\ 3082 | CVE-2013-2140 \\ 3083 | CVE-2013-2058 \\ 3084 | CVE-2013-2015 \\ 3085 | CVE-2013-0309 \\ 3086 | CVE-2013-0231 \\ 3087 | CVE-2013-0190 \\ 3088 | CVE-2012-5375 \\ 3089 | CVE-2012-5374 \\ 3090 | CVE-2012-4398 \\ 3091 | CVE-2011-4098 \\ 3092 | CVE-2011-3638 \\ 3093 | CVE-2011-2491 \\ 3094 | CVE-2011-2479 \\ 3095 | CVE-2016-9191 \\ 3096 | CVE-2016-8660 \\ 3097 | CVE-2016-8646 \\ 3098 | CVE-2016-8645 \\ 3099 | CVE-2016-8630 \\ 3100 | CVE-2016-6198 \\ 3101 | CVE-2016-6197 \\ 3102 | CVE-2016-6162 \\ 3103 | CVE-2016-5412 \\ 3104 | CVE-2016-3689 \\ 3105 | CVE-2016-3156 \\ 3106 | CVE-2016-2847 \\ 3107 | CVE-2016-2548 \\ 3108 | CVE-2015-8953 \\ 3109 | CVE-2015-8952 \\ 3110 | CVE-2015-8845 \\ 3111 | CVE-2015-8844 \\ 3112 | CVE-2015-8215 \\ 3113 | CVE-2015-8104 \\ 3114 | CVE-2015-7872 \\ 3115 | CVE-2015-7509 \\ 3116 | CVE-2015-6252 \\ 3117 | CVE-2015-5366 \\ 3118 | CVE-2015-5307 \\ 3119 | CVE-2015-5283 \\ 3120 | CVE-2015-4700 \\ 3121 | CVE-2015-4178 \\ 3122 | CVE-2015-4177 \\ 3123 | CVE-2015-3332 \\ 3124 | CVE-2015-3291 \\ 3125 | CVE-2015-2672 \\ 3126 | CVE-2015-2150 \\ 3127 | CVE-2015-1573 \\ 3128 | CVE-2015-1350 \\ 3129 | CVE-2015-0275 \\ 3130 | CVE-2014-9730 \\ 3131 | CVE-2014-9729 \\ 3132 | CVE-2014-9090 \\ 3133 | CVE-2014-8369 \\ 3134 | CVE-2014-8172 \\ 3135 | CVE-2014-7970 \\ 3136 | CVE-2014-7843 \\ 3137 | CVE-2014-7283 \\ 3138 | CVE-2014-5472 \\ 3139 | CVE-2014-4667 \\ 3140 | CVE-2014-3688 \\ 3141 | CVE-2014-3647 \\ 3142 | CVE-2014-3646 \\ 3143 | CVE-2014-3645 \\ 3144 | CVE-2014-3610 \\ 3145 | CVE-2014-3601 \\ 3146 | CVE-2012-6657 \\ 3147 | CVE-2011-0999 \\ 3148 | CVE-2013-6368 \\ 3149 | 3150 | CVE-2016-4440 \\ 3151 | CVE-2016-2143 \\ 3152 | CVE-2015-8816 \\ 3153 | CVE-2015-8767 \\ 3154 | CVE-2015-5366 \\ 3155 | CVE-2015-5364 \\ 3156 | CVE-2013-0311 \\ 3157 | CVE-2011-3188 \\ 3158 | CVE-2011-2699 \\ 3159 | CVE-2011-2189 \\ 3160 | CVE-2010-1162 \\ 3161 | CVE-2010-0741 \\ 3162 | CVE-2010-1087 \\ 3163 | CVE-2011-3363 \\ 3164 | CVE-2015-0274 \\ 3165 | CVE-2009-1336 \\ 3166 | CVE-2014-9888 \\ 3167 | CVE-2015-2922 \\ 3168 | CVE-2014-9644 \\ 3169 | CVE-2009-0024 \\ 3170 | CVE-2010-0291 \\ 3171 | 3172 | #+LATEX: \end{multicols} 3173 | -------------------------------------------------------------------------------- /thesis.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/maxking/linux-vulnerabilities-10-years/215ccb48d506ee332407923cf1001bed16a692ed/thesis.pdf --------------------------------------------------------------------------------