Termin:Chaotic-Congress-Cinema Nr. 20

Aus Attraktor Wiki

Wechseln zu: Navigation, Suche


Chaotic-Congress-Cinema Nr. 20

Beginn:

08.06.2011 20:00

Ende:

08.06.2011 23:00


Needs to be there, but does not need to be seen by a visitor Yes Wir schauen uns die Aufzeichnung von Congress Vorträgen an. Du bist herzlich eingeladen, in den Clubräumen im Mexikoring 21 aufzutauchen und mit uns die Talks anzuschauen und zu diskutieren. Es wird Getränke und Knabberkram zu moderaten Preisen geben. Falls Du kein CCC-, CCCHH- oder Attraktor e.V.-Mitglied bist, macht das überhaupt nichts: Alle Gäste sind gern gesehen. :-)

Weitere Informationen unter Chaotic Congress Cinema.

"Spoilers, Reverse Green, DECEL!" or "What's it doing now?"

Thoughts on the Automation and its Human interfaces on Airplanes

Getting the interfaces right to computers controlling complex and dangerous machines such as commercial airliners is crucial. I will present a successful accident analysis method and talk about interface design problems, ideas for solutions, methods for understanding causal control flow. There will be some spectacular aviation accident videos and stories of bad luck, bad design, bad decisions, and a hero that managed to turn a near-catastrophe into an accident without fatalities.

Getting the Interface right can be crucial.

So does an understanding of the underlying logic, and knowledge of correct procedures when operating complex devices.

Modern airliners are incredibly complex machines, no person can fully understand what is going on. This starts at simple things like fuel systems (e. g. the B777 has only two engines and three fuel tanks, how complicated can that be? Surprisingly so.) and goes on to autopilots, autothrottle systems, FADECs (Full Authority Digital Engine Control), Flight Management, Guidance and Envelope Computers (FMGEC), digital fly-by-wire systems, weight computations etc.

Apart from the largely unsolved problems of how to create software for these systems that is demonstrably extremely reliable (in commercial aviation we're talking about probablities of dangerous failures of 1 in a billion flight hours: testing just won't do), there is the underrated question of getting the interface right.

What to annunciate to the crew and when, and in which form? Some accidents and incidents are directly related to a flight crew being confused by the annunciations, or didn't know how to react properly to seemingly unrelated warnings. At other times, a pertinent and important warning is suppressed because another, ostensibly more important warning inhibited the other one.

I'll be talking about some accidents that we have analysed using Why- Because-Analysis (see http://www.rvs.uni-bielefeld.de/research/WBA/) in which the interface and the automation played a role. I will also be talking about some design principles to guide interface design and interactive safety.


http://events.ccc.de/congress/2010/Fahrplan/events/4145.en.html

http://ftp.ccc.de/congress/27C3/mp4-h264-HQ/27c3-4145-en-spoilers_human_interfaces_airplanes.mp4

I Control Your Code

Attack Vectors Through the Eyes of Software-based Fault Isolation

Unsafe languages and an arms race for new bugs calls for an additional line of defense in software systems. User-space virtualization uses dynamic instrumentation to detect different attack vectors and protects from the execution of malicious code. An additional advantage of these virtualization systems is that they can be used to analyze different exploits step by step and to extract the exploit code from a running program.

This talk explains the concept of different attack vectors (stack buffer overflows, format string attacks, return to libc attacks, race attacks / TOCTTOU, integer overflows, heap buffer overflows, and code anomalies). For each of these attack vectors we show possible exploits and explain how the virtualization system is able to detect and prevent the exploit.

User-space virtualization uses a binary translation framework to instrument all running code. The instrumentation works like an additional virtualization layer and makes it possible to observe any changes to the runtime datastructures (code and data) of a running program. We use fastBT to instrument and analyze different exploitable programs. The added instrumentation detects changes in runtime layout and stops the program whenever exploit code is about to be executed.

This talk presents different classes of exploits that can be observed in a dynamic instrumentation system. The exploits are analyzed and different security strategies are discussed. We then show how the instrumentation framework can implement an online protection mechanism against each class of attack vectors.

Observable Attack Vectors


+ Stack Overflow A limited buffer is (over) flown with user-data and

 over writes data on the stack (e.g., the return instruction pointer).

+ Format String Attack An attack can write to an arbitrary address

 (e.g., the return instruction pointer or the address of a library
 function) if unvalidated user input is passed directly to the printf
 function.

+ Return to libc Attack This attack prepares multiple stack frames

 that execute code sequences in libraries. The stack frame can be
 constructed so that (almost) arbitrary code is executed.

+ Race Attacks / TOCTTOU Time-of-check-to-time-of-use race conditions

 exploit the fact that they can change values on the stack after they
 are checked but before they are used in the program or kernel.

+ Integer Overflow Overflows can be triggered by using a negative

 integer value instead of an unsigned value.

+ Heap Overflow A heap buffer overflow is used to overwrite function

 pointers or data from the memory allocator to trigger execution of
 arbitrary code.

+ Code Anomalies x86_64 code is backward compatible to ia32 and in

 modern operating systems x86_64 and ia32 code can be mixed. The mix of
 different system calls makes it possible to break out of sand boxes
 that are not aware of all possible combinations of system calls.


The exploits are detected generally whenever the program branches to the injected code or to the constructed code fragments. The program is interrupted and a debugger can be attached to analyze the state of the program. TOCTTOU attacks can be detected by observing the threads and using a specific system call architecture.

Conclusion Dynamic instrumentation is an important tool to prohibit, detect, and analyze different attack vectors to running programs. Additional instrumentation guards can be used to better understand exploits. The additional layer of virtualization implemented through dynamic instrumentation can be used to detect and log bugs and is an additional line of defense against new exploits.

Related Work A detailed discussion of related work is in the paper. These references here are for informational purposes only (to show how this talk was inspired) and not complete.


+ fastBT: A fast binary translator that enables different security

 extensions. http://nebelwelt.net/fastBT

+ 26c3 talk: Hacking the Hackers (user space virtualization and

 encapsulation mixed with system call authorization to prevent
 exploits)

+ Watson, R. N. "Exploiting Concurrency Vulnerabilities in System Call

 Wrappers"

+ Levy, Elias. "Smashing the stack for fun and profit" + c0ntex. "Bypassing non-executable-stack during exploitation using

 return-to-libc"

+ Shacham, Hovav; Page, Matthew; Pfaff, Ben; Goh, Eu-Jin; Modadugu,

 Nagendra; and Boneh, Dan. "On the Effectiveness of Address-Space
 Randomization"

+ Borisov, Nikita; Johnson, Rob; Sastry, Naveen; and Wagner, David;

 2005; "Fixing Races for Fun and Profit: How to abuse atime"

+ Phrack #60, Basic Integer Overflows + Seccomp vulnerabilities due to x86_64 and ia32 compatibility issues:

 http://scarybeastsecurity.blogspot.com/2009/02/linux-kernel-minor-
 seccomp.html



http://events.ccc.de/congress/2010/Fahrplan/events/4149.en.html

http://ftp.ccc.de/congress/27C3/mp4-h264-HQ/27c3-4149-en-i_control_your_code.mp4

Diese Seite wurde zuletzt am 23. Mai 2011 um 11:24 Uhr geändert. Diese Seite wurde bisher 3.151 mal abgerufen.