Idag finns 165 Pansarterrängbil 203 (Patgb203) med varianter i tjänst för Sverige. De är framförallt trupptransportörer, men vid behov ska de även kunna ge svarseld. Därför är 203 beväpnad med automatkanonen Hispano-Suiza HS.404, som ursprungligen användes i flygplan. År 1998 upphörde tillverkningen av den tillhörande 20 mm ammunitionen till automatkanonen. Detta innebär att alla Pansarterrängbil 203 med varianter som är bestyckade med 20 mm automatkanonen behöver en ny beväpning innan ammunitionen tar slut. I föregående rapporter av Svensk Konstruktionstjänst AB har utvärderingar till problemet tagits upp där slutsatsen har resulterat att ombeväpna Patgb203 med 12,7 mm Tung kulspruta och behålla den befintliga vapenhuven. Denna rapport avser en konceptstudie vid en ombeväpning av vapenhuven till 20 mm automatkanonen. Rapporten tar systematiskt upp utvecklingen av ett koncept som är väl underbyggt av problemidentifieringar, analys av gränsytor, användarstudie och resultat. Rapporten fokuserar på vapenhållaren i vapenhuven, där låsningen av vapnet, att befintliga funktioner kan bevaras. Även ammunitionsinmatning och tomhyls- och krutgashantering är delsystem av problemet. Pansarterrängbil 203A (Patgb203) är ett 6-hjuligt trupptransportfordon som används av den svenska försvarsmakten för trupptransport, sjuktransport eller reparationsgrupp. En ombeväpning till Tungkulspruta kommer att kunna återge likvärdiga prestanda och ger tillgång till en mer tillgänglig ammunition. Även en större mängd ammunition kan tas med i vagnen vid övning eller strid. En analys av projektilbanan påvisar att det bestrukna området ökar vid en ombeväpning med 34%. Fästhål och fria zoner på grund av in- och utmatning identifieras och lokaliseras. En mängd koncept konstrueras och utvärderas med hjälp av de krav som förstudien har genererat. Delsystem kartläggs och poängsätts för att slutligen rendera i ett slutkoncept. Under konceptutvecklingen var utrymmesbristen i vapenhuven uppenbar. För att kunna få plats med en ny beväpning krävdes att avancerade vinklar togs ut för att undvika de befintliga funktionerna. Att ha en hängande ammunition under vapnet och som följer med i elevationen visades vara den bästa lösningen för att undvika eldavbrott. Slutkonceptet blev Vapenhållare 12.7 för Vapenhuv m/47D. Den kan enkelt integreras i huven med dess befintliga funktioner. Ammunitonen placeras precis under vapnet där en ammunitionshållare är monterad på vapenhållaren. Den kommer på så vis följa med under elevationen och därav minska risken för eldavbrott. Ammunitionshållaren kan vridas i 60 grader för att underlätta hantering av befintliga ammunitionslådor som kan användas i sitt orginalutförande. Tiltningen gör också att de befintliga gränsytorna kan undvikas. Bandlänk tillsammans med tomhylsorna leds ner till hylsuppsamlingslådan med hjälp av en flexibel hylspåse där krutgaserna sugs ut ur Patgb203. Resultatet av den slutliga konceptet är en likvärdig beväpning som ger en mer tillgänglig ammunition. En förbättring är mängden laddad ammunition i vagnen och den mängd ammunition som nu kan medföras. De nya funktionerna är intuitiva och enkla att förstå. Denna konceptstudie är en vidareutvecklings plattform för delsystemen. Med fullskaliga försök och användartester kan trovärdigheten öka för konceptet. / Today there are 165 armored personnel carrier, Patgb 203 with variants, in service for Sweden. They are primarily used as troop carriers, but when required they should be able to return fire. Hence the 203’s have been armed with the automatic gun Hispano-Suiza HS.404, originally used in aircrafts. At the end of the 20th century the production of the special 20 mm ammunition for this weapon was decommissioned. This meant that all the 203’s armed with the 20 mm automatic gun require a new armament. During the last years alternative solution to the problem have been presented while the ammunition slowly starting to run out. In previous reports, from Svensk Konstruktionstjänst AB, a conclusion of the alternatives is to rearming the 203’s with aheavy machine gun (HMG) and keep the existing weapon hood. This report includes a concept study regarding rearmament of the weapon hood for the 20 mm autocannon. This report covers a systematically development process with concepts that are well substantiated with interface and user studies to suggest a final concept for a rearmament of 203’s. The focus of the report is primarily on the weapon holder, which will fasten the weapon to preserve existing features and also subsystems such as ammunition feed, handling of the empty cases and propellant gases. Also fixation holes and free zones on the HMG are located and constructed for the new ammunition feed and ejection. Armored personnel carrier 203A (Patgb203) is a 6-wheeled truck used by the Swedish military for troop transportation, ambulance or repair transportation. The rearmament to a heavy machine gun allows equivalent performance and offers more accessible ammunition. Even a larger amount of ammunition can be included during the exercise/combat in the vehicle. Analyses of the trajectory demonstrate that the coated area increases at a rearmament with 34%. A variety of concepts is developed and evaluated using the requirements that the conducted information retrieval has generated. Subsystems are identified and scored aid a generating final concept. One of the biggest challenges during the concept phase wasthe lack of space. A lot of complicated angles has to be found to avoid all the original features. A hanging ammo concept was shown to be the best solution that prevents unforced firing breaks. The final concept is weapon holder 12.7, which allows a HMG be adapted to a Patgb203. It can easily be integrated into the hood with its existing features. The ammunition can be placed just below the armament where ammunition holder is mounted on the weapon holder. It will thus follow the elevation and reduce the risk for misfiring. The ammunition holder can be rotated 60 degrees to facilitate the ammunition change and let the ammoboxes be used in its original condition. To avoid the existing interfaces the ammo holder can be tilted up. The tilt process also prevents the holder interfering with the existing interface. The empty cases after firing are directed down by a chute to a collector box where the propellant gases are blown outfrom the 203. The result of the final concept is an equivalent armament that allows more available ammunition. The 203’s is now able to return more fire to targets before reloading compared to the existing armament. Also the amount ammunition carried by the vehicle is increased. The new functions are intuitive and easy to understand. This concept study forms a firm base for a further development of the rearmaments subsystems. The concepts credibility can be enhanced with full scale tests and user trials.

It is a fact that software has bugs. These bugs can lead to failures. Especially dependability and security failures are a great threat to software users. This thesis introduces four novel approaches that can be used to automatically harden software at the user's site. Automatic hardening removes bugs from already deployed software. All four approaches are automated, i.e., they require little support from the end-user. However, some support from the software developer is needed for two of these approaches. The presented approaches can be grouped into error toleration and bug removal. The two error toleration approaches are focused primarily on fast detection of security errors. When an error is detected it can be tolerated with well-known existing approaches. The other two approaches are bug removal approaches. They remove dependability bugs from already deployed software. We tested all approaches with existing benchmarks and applications, like the Apache web-server.

It is a fact that software has bugs. These bugs can lead to failures. Especially dependability and security failures are a great threat to software users. This thesis introduces four novel approaches that can be used to automatically harden software at the user's site. Automatic hardening removes bugs from already deployed software. All four approaches are automated, i.e., they require little support from the end-user. However, some support from the software developer is needed for two of these approaches. The presented approaches can be grouped into error toleration and bug removal. The two error toleration approaches are focused primarily on fast detection of security errors. When an error is detected it can be tolerated with well-known existing approaches. The other two approaches are bug removal approaches. They remove dependability bugs from already deployed software. We tested all approaches with existing benchmarks and applications, like the Apache web-server.:1 Introduction 1 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Automatic Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Theses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Enforcing Dynamic Personalized System Call Models 9 2.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 SwitchBlade Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 System Call Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.1 Personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.2 Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4 Model Learner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4.1 Problem: False Positives . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4.2 Data- ow-Based Learner . . . . . . . . . . . . . . . . . . . . . . . . 26 2.5 Taint Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.5.1 TaintCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.5.2 Escaping Valgrind . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.5.3 Replay of Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6 Model Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.1 Loading the System Call Model . . . . . . . . . . . . . . . . . . . . 31 2.6.2 Checking System Calls . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.7 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.7.1 Synthetic Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.7.2 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.7.3 Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.7.4 Micro Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.7.5 Model Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.7.6 Stateful Application . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3 Speculation for Parallelizing Runtime Checks 43 3.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.1.1 Compiler Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 47 3.1.2 Runtime Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3 Deterministic Replay and Speculation . . . . . . . . . . . . . . . . . . . . . 52 3.3.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.4 Switching Code Bases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.4.2 Integration with parexc chkpnt . . . . . . . . . . . . . . . . . . 58 3.4.3 Code Transformations . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.4.4 Stack-local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.5 Speculative Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.5.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.5.2 Deadlock Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.5.3 Storage Back-ends . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.6 Parallelized Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.6.1 Out-of-Bounds Checks . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.6.2 Data Flow Integrity Checks . . . . . . . . . . . . . . . . . . . . . . 71 3.6.3 FastAssert Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.6.4 Runtime Checking in STM-Based Applications . . . . . . . . . . . . 72 3.7 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.7.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.7.2 Checking Already Parallelized Applications . . . . . . . . . . . . . . 77 3.7.3 ParExC Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4 Automatically Finding and Patching Bad Error Handling 83 4.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.3 Learning Library-Level Error Return Values from System Call Error Injection 89 4.3.1 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.3.2 E cient Error Injection . . . . . . . . . . . . . . . . . . . . . . . . 91 4.3.3 Obtain OS Error Specification . . . . . . . . . . . . . . . . . . . . . 92 4.4 Finding Bad Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.4.1 Argument Recording . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.4.2 Systematic Error Injection . . . . . . . . . . . . . . . . . . . . . . . 94 4.4.3 Static Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.5 Fast Error Injection using Virtual Machines . . . . . . . . . . . . . . . . . 99 4.5.1 The fork Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.5.2 Virtual Machines for Fault Injection . . . . . . . . . . . . . . . . . . 101 4.6 Patching Bad Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.6.1 Error Value Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.6.2 Preallocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.6.3 Patch Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.7 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.7.1 Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5 Robustness and Security Hardening of COTS Software Libraries 117 5.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.3 Test Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.3.1 Ballista Type System . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.3.2 Meta Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 5.3.3 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.3.4 Type Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 5.3.5 Type Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . 128 5.3.6 Reducing the Number of Test Cases . . . . . . . . . . . . . . . . . . 128 5.3.7 Other Sources of Test Values . . . . . . . . . . . . . . . . . . . . . . 130 5.4 Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 5.4.1 Check Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 5.4.2 Parameterized Check Templates . . . . . . . . . . . . . . . . . . . . 133 5.5 Protection Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.5.1 Minimizing the Truth Table . . . . . . . . . . . . . . . . . . . . . . 134 5.5.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 5.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.6.1 Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 5.6.2 Autocannon as Dependability Benchmark . . . . . . . . . . . . . . 138 5.6.3 Protection Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . 139 5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6 Conclusion 143 6.1 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 References 147 List of Figures 159 List of Tables 163 Listings 165