Re: [Pharo-project] Trusting Trust
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap. There is nothing you can do against it. It's true for GCC or Java, too. Marcus -- Marcus Denker -- http://marcusdenker.de
On 02/08/2012 10:43 AM, Marcus Denker wrote:
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap.
There is nothing you can do against it. It's true for GCC or Java, too.
Yes, but read the links on how you can use a different, second compiler. Cheers Philippe
Am 08.02.2012 um 11:12 schrieb Philippe Marschall:
On 02/08/2012 10:43 AM, Marcus Denker wrote:
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap.
There is nothing you can do against it. It's true for GCC or Java, too.
Yes, but read the links on how you can use a different, second compiler.
And what if the second compiler is compromised, too? An operating system is also a virtual environment. So what if that environment is rooted, lives in another shell? The "what if"-question in a security context can be played infinitely. The compromisable areas are only defined in opposite where you have put some trust. Or saying it in other words: There is no trust until you put it somewhere. couldn't resist, Norbert
On 8 February 2012 10:33, Norbert Hartl <norbert@hartl.name> wrote:
Am 08.02.2012 um 11:12 schrieb Philippe Marschall:
On 02/08/2012 10:43 AM, Marcus Denker wrote:
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap.
There is nothing you can do against it. It's true for GCC or Java, too.
Yes, but read the links on how you can use a different, second compiler.
And what if the second compiler is compromised, too? An operating system is also a virtual environment. So what if that environment is rooted, lives in another shell? The "what if"-question in a security context can be played infinitely. The compromisable areas are only defined in opposite where you have put some trust. Or saying it in other words: There is no trust until you put it somewhere.
Indeed; that's precisely the point: both compilers need to be subverted in the SAME way in order for you not to notice. The chances of that happening are much lower than not anything at all! Regarding "There is no trust until you put it somewhere", my favourite webcomic (http://www.schlockmercenary.com/) puts it thusly: "A little trust goes a long way. The less you use, the further you'll go." But of course it takes time and effort into removing the trust you've placed in your compiler. It would not be unreasonable for Pharo to say "yes, we know that we're trusting the compiler" simply because there are other, more pressing matters. frank
couldn't resist,
Norbert
Frank Shearar wrote:
On 8 February 2012 10:33, Norbert Hartl <norbert@hartl.name> wrote:
Am 08.02.2012 um 11:12 schrieb Philippe Marschall:
On 02/08/2012 10:43 AM, Marcus Denker wrote:
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap.
There is nothing you can do against it. It's true for GCC or Java, too.
Yes, but read the links on how you can use a different, second compiler.
And what if the second compiler is compromised, too? An operating system is also a virtual environment. So what if that environment is rooted, lives in another shell? The "what if"-question in a security context can be played infinitely. The compromisable areas are only defined in opposite where you have put some trust. Or saying it in other words: There is no trust until you put it somewhere.
Norbert
Indeed; that's precisely the point: both compilers need to be subverted in the SAME way in order for you not to notice. The chances of that happening are much lower than not anything at all!
Regarding "There is no trust until you put it somewhere", my favourite webcomic (http://www.schlockmercenary.com/) puts it thusly: "A little trust goes a long way. The less you use, the further you'll go."
But of course it takes time and effort into removing the trust you've placed in your compiler. It would not be unreasonable for Pharo to say "yes, we know that we're trusting the compiler" simply because there are other, more pressing matters.
frank
Security is not an absolute - it is a spectrum. My usual example is comparing at one extreme keeping all your savings in shoe boxes under you bed. Very simple to use but also easily subverted. At the other extreme you keep all your savings behind several bank vault doors under a mountain. 'Almost' absolutely secure but not very usable. In practice the line is drawn somewhere between by balancing risks, effort and usability. It is useful to consider each extreme to help balancing these conflicting priorities. I like the term "practical paranoia." Think paranoid to be aware of the issues, then decide based on practical matters what to do about them. The Pharo image is a single binary evolving over more than twenty years. At one extreme you implicitly trust _every_ unknown hand that ever had access to the trunk. At the other extreme "most" people _are_ good people. Pharo certainly has more pressing matters, but the aim should be to reduce the surface area of attack/trust where possible. A single bootstrap step without Diverse Double-Compiling goes a long way to achieving this. Stéphane Ducasse wrote:
On Feb 8, 2012, at 9:35 AM, Philippe Marschall wrote:
I think it's worse in Pharo because you're never bootstrapping from source. From all you know the tools could be subverted to show you a different code than is actually running in the system.
well I do not think so since we can all read the code. If you have a bootstrap in C or assembly it does make me more confident.
So the argument while nice at first sight does not hold a second. Now we will get a bootstrapped version of pharo believe me :)
That is good to hear. My contemplation of this stemmed from seeing the stub for bootstrapping in the PharoVision document. This dredged up a memory of reading the articles long ago and was was interested in views of how it applied today. While there are a lot of other benefits from bootstrapping, security provides just one more reason to justify the effort. Thanks for your thought, Cheers, -ben
Do you really think that the compiler is the real Achille heal in an image where everything work by message send? IMO, the compiler is much less central than in other languages. What I would do to fool users and tools would just be to hack a few methods like #methodDict (just like Stephane proposed for example). I would arrange to not answer the true methodDict but a fake for a few classes. Create a class var in Behavior, like FakedBehaviors := Dictionary new. Then modify Behavior>>methodDict ^FakedBehaviors at: self ifAbsent: [methodDict] Then you can start populating FakedBehaviors. Of course, you would begin by faking Behavior itself to not be caught. Then you could also arrange to falsify Smalltalk at: #MethodDictionary, just to avoid a sneaker to try (MethodDictionary allInstances), and let a class var hook in Behavior refer to the TrueMethodDictionary etc... fake instVarAt: to never return the true methodDict, fake the messages concerning Behavior classPool to hide your piracy... Or better, don't use a class var at all, but just hack a literal in the hacked method... Faking the whole IDE is a lot more work (think of inspectors, debuggers, Object tracing etc..), but really is possible, and removing clues is also possible, it's just a bootstrap problem ;) There is no in-image parade, you'd have to use tracing from outside. Nicolas 2012/2/8 Ben Coman <btc@openinworld.com>:
Frank Shearar wrote:
On 8 February 2012 10:33, Norbert Hartl <norbert@hartl.name> wrote:
Am 08.02.2012 um 11:12 schrieb Philippe Marschall:
On 02/08/2012 10:43 AM, Marcus Denker wrote:
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap.
There is nothing you can do against it. It's true for GCC or Java, too.
Yes, but read the links on how you can use a different, second compiler.
And what if the second compiler is compromised, too? An operating system is also a virtual environment. So what if that environment is rooted, lives in another shell? The "what if"-question in a security context can be played infinitely. The compromisable areas are only defined in opposite where you have put some trust. Or saying it in other words: There is no trust until you put it somewhere.
Norbert
Indeed; that's precisely the point: both compilers need to be subverted in the SAME way in order for you not to notice. The chances of that happening are much lower than not anything at all! Â Regarding "There is no trust until you put it somewhere", my favourite webcomic (http://www.schlockmercenary.com/) puts it thusly: "A little trust goes a long way. The less you use, the further you'll go."
But of course it takes time and effort into removing the trust you've placed in your compiler. It would not be unreasonable for Pharo to say "yes, we know that we're trusting the compiler" simply because there are other, more pressing matters.
frank
Security is not an absolute - it is a spectrum. Â My usual example is comparing at one extreme keeping all your savings in shoe boxes under you bed. Â Very simple to use but also easily subverted. Â At the other extreme you keep all your savings behind several bank vault doors under a mountain. Â 'Almost' absolutely secure but not very usable. Â In practice the line is drawn somewhere between by balancing risks, effort and usability. Â It is useful to consider each extreme to help balancing these conflicting priorities.
I like the term "practical paranoia." Â Think paranoid to be aware of the issues, then decide based on practical matters what to do about them. Â The Pharo image is a single binary evolving over more than twenty years. Â At one extreme you implicitly trust _every_ unknown hand that ever had access to the trunk. Â At the other extreme "most" people _are_ good people. Â Pharo certainly has more pressing matters, but the aim should be to reduce the surface area of attack/trust where possible. Â A single bootstrap step without Diverse Double-Compiling goes a long way to achieving this.
Stéphane Ducasse wrote:
On Feb 8, 2012, at 9:35 AM, Philippe Marschall wrote:
I think it's worse in Pharo because you're never bootstrapping from source. From all you know the tools could be subverted to show you a different code than is actually running in the system.
well I do not think so since we can all read the code. If you have a bootstrap in C or assembly it does make me more confident.
So the argument while nice at first sight does not hold a second. Now we will get a bootstrapped version of pharo believe me :)
That is good to hear. Â My contemplation of this stemmed from seeing the stub for bootstrapping in the PharoVision document. Â This dredged up a memory of reading the articles long ago and was was interested in views of how it applied today. Â While there are a lot of other benefits from bootstrapping, security provides just one more reason to justify the effort. Thanks for your thought, Cheers, -ben
You are right. The compiler binary described in the scenario corresponds to the whole of the Smalltalk binary image. Nicolas Cellier wrote:
Do you really think that the compiler is the real Achille heal in an image where everything work by message send? IMO, the compiler is much less central than in other languages.
What I would do to fool users and tools would just be to hack a few methods like #methodDict (just like Stephane proposed for example). I would arrange to not answer the true methodDict but a fake for a few classes. Create a class var in Behavior, like FakedBehaviors := Dictionary new. Then modify Behavior>>methodDict ^FakedBehaviors at: self ifAbsent: [methodDict]
Then you can start populating FakedBehaviors. Of course, you would begin by faking Behavior itself to not be caught.
Then you could also arrange to falsify Smalltalk at: #MethodDictionary, just to avoid a sneaker to try (MethodDictionary allInstances), and let a class var hook in Behavior refer to the TrueMethodDictionary etc... fake instVarAt: to never return the true methodDict, fake the messages concerning Behavior classPool to hide your piracy... Or better, don't use a class var at all, but just hack a literal in the hacked method... Faking the whole IDE is a lot more work (think of inspectors, debuggers, Object tracing etc..), but really is possible, and removing clues is also possible, it's just a bootstrap problem ;)
There is no in-image parade, you'd have to use tracing from outside.
Nicolas
2012/2/8 Ben Coman <btc@openinworld.com>:
Frank Shearar wrote:
On 8 February 2012 10:33, Norbert Hartl <norbert@hartl.name> wrote:
Am 08.02.2012 um 11:12 schrieb Philippe Marschall:
On 02/08/2012 10:43 AM, Marcus Denker wrote:
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap.
There is nothing you can do against it. It's true for GCC or Java, too.
Yes, but read the links on how you can use a different, second compiler.
And what if the second compiler is compromised, too? An operating system is also a virtual environment. So what if that environment is rooted, lives in another shell? The "what if"-question in a security context can be played infinitely. The compromisable areas are only defined in opposite where you have put some trust. Or saying it in other words: There is no trust until you put it somewhere.
Norbert
Indeed; that's precisely the point: both compilers need to be subverted in the SAME way in order for you not to notice. The chances of that happening are much lower than not anything at all! Regarding "There is no trust until you put it somewhere", my favourite webcomic (http://www.schlockmercenary.com/) puts it thusly: "A little trust goes a long way. The less you use, the further you'll go."
But of course it takes time and effort into removing the trust you've placed in your compiler. It would not be unreasonable for Pharo to say "yes, we know that we're trusting the compiler" simply because there are other, more pressing matters.
frank
Security is not an absolute - it is a spectrum. My usual example is comparing at one extreme keeping all your savings in shoe boxes under you bed. Very simple to use but also easily subverted. At the other extreme you keep all your savings behind several bank vault doors under a mountain. 'Almost' absolutely secure but not very usable. In practice the line is drawn somewhere between by balancing risks, effort and usability. It is useful to consider each extreme to help balancing these conflicting priorities.
I like the term "practical paranoia." Think paranoid to be aware of the issues, then decide based on practical matters what to do about them. The Pharo image is a single binary evolving over more than twenty years. At one extreme you implicitly trust _every_ unknown hand that ever had access to the trunk. At the other extreme "most" people _are_ good people. Pharo certainly has more pressing matters, but the aim should be to reduce the surface area of attack/trust where possible. A single bootstrap step without Diverse Double-Compiling goes a long way to achieving this.
Stéphane Ducasse wrote:
On Feb 8, 2012, at 9:35 AM, Philippe Marschall wrote:
I think it's worse in Pharo because you're never bootstrapping from source. From all you know the tools could be subverted to show you a different code than is actually running in the system.
well I do not think so since we can all read the code. If you have a bootstrap in C or assembly it does make me more confident.
So the argument while nice at first sight does not hold a second. Now we will get a bootstrapped version of pharo believe me :)
That is good to hear. My contemplation of this stemmed from seeing the stub for bootstrapping in the PharoVision document. This dredged up a memory of reading the articles long ago and was was interested in views of how it applied today. While there are a lot of other benefits from bootstrapping, security provides just one more reason to justify the effort. Thanks for your thought, Cheers, -ben
Yes, so duplicating the Compiler can't be a valid strategy. Every Inspector, every Debugger, every message send will modify the binary image... You could trace the image with another program - or another trusted image ;) - and validate some restrictive invariants, for example like: - all behaviours are accessible thru an environment (Smalltalk globals currently) - all behaviours have a methodDict inst var. which is an instance of MethodDictionary - MethodDictionary allInstances size = all behaviors size - all CompiledMethods instances are installed in a MethodDictionary But I'm quite sure that most of these are already false in our image... ...like I launched a process from within a doIt... Or some block of code are rooted in removed or changed CompiledMethod but are still in use, etc... And even better, i can create and compile code at will, so what would prevent me to hide some nasty byte code in an icon by steganography, uncrypt it with an obscure un-noticed graphics method, or even better, use an existing BitBlt method, there are so many.. I would just have to introduce a small bug to trigger its execution, or nec plus ultra exploit an existing one.... Unless I don't even need a bug: there are enough places to store code into, an innocent MessageSend can easily be triggered by some Morph. and I'm quite sure above attack is doable by simply hacking the background Pharo image ;) Nicolas 2012/2/8 Ben Coman <btc@openinworld.com>:
You are right. Â The compiler binary described in the scenario corresponds to the whole of the Smalltalk binary image.
Nicolas Cellier wrote:
Do you really think that the compiler is the real Achille heal in an image where everything work by message send? IMO, the compiler is much less central than in other languages.
What I would do to fool users and tools would just be to hack a few methods like #methodDict (just like Stephane proposed for example). I would arrange to not answer the true methodDict but a fake for a few classes. Create a class var in Behavior, like FakedBehaviors := Dictionary new. Then modify Behavior>>methodDict   ^FakedBehaviors at: self ifAbsent: [methodDict]
Then you can start populating FakedBehaviors. Of course, you would begin by faking Behavior itself to not be caught.
Then you could also arrange to falsify Smalltalk at: #MethodDictionary, just to avoid a sneaker to try (MethodDictionary allInstances), and let a class var hook in Behavior refer to the TrueMethodDictionary etc... fake instVarAt: to never return the true methodDict, fake the messages concerning Behavior classPool to hide your piracy... Or better, don't use a class var at all, but just hack a literal in the hacked method... Faking the whole IDE is a lot more work (think of inspectors, debuggers, Object tracing etc..), but really is possible, and removing clues is also possible, it's just a bootstrap problem ;)
There is no in-image parade, you'd have to use tracing from outside.
Nicolas
2012/2/8 Ben Coman <btc@openinworld.com>:
Frank Shearar wrote:
On 8 February 2012 10:33, Norbert Hartl <norbert@hartl.name> wrote:
Am 08.02.2012 um 11:12 schrieb Philippe Marschall:
On 02/08/2012 10:43 AM, Marcus Denker wrote:
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap.
There is nothing you can do against it. It's true for GCC or Java, too.
Yes, but read the links on how you can use a different, second compiler.
And what if the second compiler is compromised, too? An operating system is also a virtual environment. So what if that environment is rooted, lives in another shell? The "what if"-question in a security context can be played infinitely. The compromisable areas are only defined in opposite where you have put some trust. Or saying it in other words: There is no trust until you put it somewhere.
Norbert
Indeed; that's precisely the point: both compilers need to be subverted in the SAME way in order for you not to notice. The chances of that happening are much lower than not anything at all! Â Regarding "There is no trust until you put it somewhere", my favourite webcomic (http://www.schlockmercenary.com/) puts it thusly: "A little trust goes a long way. The less you use, the further you'll go."
But of course it takes time and effort into removing the trust you've placed in your compiler. It would not be unreasonable for Pharo to say "yes, we know that we're trusting the compiler" simply because there are other, more pressing matters.
frank
Security is not an absolute - it is a spectrum. Â My usual example is comparing at one extreme keeping all your savings in shoe boxes under you bed. Â Very simple to use but also easily subverted. Â At the other extreme you keep all your savings behind several bank vault doors under a mountain. Â 'Almost' absolutely secure but not very usable. Â In practice the line is drawn somewhere between by balancing risks, effort and usability. Â It is useful to consider each extreme to help balancing these conflicting priorities.
I like the term "practical paranoia." Â Think paranoid to be aware of the issues, then decide based on practical matters what to do about them. The Pharo image is a single binary evolving over more than twenty years. Â At one extreme you implicitly trust _every_ unknown hand that ever had access to the trunk. Â At the other extreme "most" people _are_ good people. Â Pharo certainly has more pressing matters, but the aim should be to reduce the surface area of attack/trust where possible. Â A single bootstrap step without Diverse Double-Compiling goes a long way to achieving this.
Stéphane Ducasse wrote:
On Feb 8, 2012, at 9:35 AM, Philippe Marschall wrote:
I think it's worse in Pharo because you're never bootstrapping from source. From all you know the tools could be subverted to show you a different code than is actually running in the system.
well I do not think so since we can all read the code. If you have a bootstrap in C or assembly it does make me more confident.
So the argument while nice at first sight does not hold a second. Now we will get a bootstrapped version of pharo believe me :)
That is good to hear. Â My contemplation of this stemmed from seeing the stub for bootstrapping in the PharoVision document. Â This dredged up a memory of reading the articles long ago and was was interested in views of how it applied today. Â While there are a lot of other benefits from bootstrapping, security provides just one more reason to justify the effort. Thanks for your thought, Cheers, -ben
On 02/08/2012 11:33 AM, Norbert Hartl wrote:
Am 08.02.2012 um 11:12 schrieb Philippe Marschall:
On 02/08/2012 10:43 AM, Marcus Denker wrote:
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap.
There is nothing you can do against it. It's true for GCC or Java, too.
Yes, but read the links on how you can use a different, second compiler.
And what if the second compiler is compromised, too?
Am I the only one who read the link? Cheers Philippe
Am 08.02.2012 um 12:04 schrieb Philippe Marschall:
On 02/08/2012 11:33 AM, Norbert Hartl wrote:
Am 08.02.2012 um 11:12 schrieb Philippe Marschall:
On 02/08/2012 10:43 AM, Marcus Denker wrote:
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap.
There is nothing you can do against it. It's true for GCC or Java, too.
Yes, but read the links on how you can use a different, second compiler.
And what if the second compiler is compromised, too?
Am I the only one who read the link?
Now I read it. But it doesn't change the game. There is an assumption of "a trusted compiler". So they put trust into a compiler and then derive a scenario that is far from being applyable to define an easier way of establishing trust. I can say it again in yet another way: Trust is a _human_ factor that you cannot establish with technology. That's the whole point in everything security. Norbert
Well, it's the turtles all the way down, and you always need a peace of trust to step on to keep the whole thing. So there is no absulute security, but I guess this is not a new concept. But IMHO, if someone would like to reduce (not eliminate) the risks, Smalltalk could make it less daunting. Smalltalk VM is small, and well documented in Blue book. one is free to implement its own, may it be slow, it is just important that it works, and that it is not known to public (secret VM, so that it is more difficult to mount attack against it specifically by hacking C compiler). load small (and private) snippet to dump all code (source and byte codes) from the image using both VM-s, run the MD5. Not that here our VM is reading image directly, (well up to the OS that is), hence all the byte codes, and it is relying on what the whole imaga and original VM are telling. To increase security, implement more than one VM in different languages, Smalltalk is simple enough so implementing it in C, assembler, Prolog, and ASIC-s for the purposes of verification is not out of reach for some paranoid and wealthy org. Also run on at least few operating systems. Davorin Rusevljan http://www.cloud208.com/ ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/Trusting-Trust-tp4364753p4369147.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 8 February 2012 12:33, Norbert Hartl <norbert@hartl.name> wrote:
Am 08.02.2012 um 11:12 schrieb Philippe Marschall:
On 02/08/2012 10:43 AM, Marcus Denker wrote:
On Feb 8, 2012, at 10:39 AM, Philippe Marschall wrote:
well I do not think so since we can all read the code.
No, read the argument again. If the compiler is compromised and the other tools in the image are compromised you can't read the code because the tools don't display you the actual code.
But this stays the same with a boot-strap, as you will use a compomised compiler to bootstrap the bootstrap.
There is nothing you can do against it. It's true for GCC or Java, too.
Yes, but read the links on how you can use a different, second compiler.
And what if the second compiler is compromised, too? An operating system is also a virtual environment. So what if that environment is rooted, lives in another shell? The "what if"-question in a security context can be played infinitely. The compromisable areas are only defined in opposite where you have put some trust. Or saying it in other words: There is no trust until you put it somewhere.
+1 -- Best regards, Igor Stasenko.
participants (8)
-
Ben Coman -
drush66 -
Frank Shearar -
Igor Stasenko -
Marcus Denker -
Nicolas Cellier -
Norbert Hartl -
Philippe Marschall