If an attacker finds an exploit to take control of httpd, they're still blocked in part by the fact that httpd runs as the unprivileged apache user and hence can't write any root-owned files on the system, unless the attacker also knows of a second attack that lets apache escalate its privilege. Basically correct?
What about sshd -- assuming that the attacker can connect to sshd at all (i.e. not prevented by a firewall), if they find an exploit to let them take control of sshd, would that imply immediate total control of the machine? Because if they can control sshd they can tell sshd, "Allow root login (even if prohibited in sshd.conf) and accept 'foo' as the password", then the attacker can log in as root. Is it possible, even in theory, to provide a second layer of defense behind sshd to prevent the attacker from controlling the machine, if the attacker controls sshd? The "log me in as root" attack would appear to imply that an extra layer is not possible.
(Note I'm not talking about extra layers of security *in front* of sshd, like a firewall that only permits logins from known locations. I'm also not talking about detection after the fact -- obviously you can detect unexpected root logins from the /var/log/secure* files if the attacker doesn't erase them -- only whether you could use extra layers to *prevent* the attacker from owning the machine if they take control of sshd.)
On 01/10/12 11:12, Bennett Haselton wrote:
What about sshd -- assuming that the attacker can connect to sshd at all (i.e. not prevented by a firewall), if they find an exploit to let them take control of sshd, would that imply immediate total control of the
UsePrivilegeSeparation Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes. The default is ``yes''. If UsePrivilegeSeparation is set to ``sandbox'' then the pre-authentication unprivileged process is subject to additional restrictions.
http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5
also selinux is everywhere this days... (default mechanism for "defense-in-depth")
HTH, Adrian
On 1/10/2012 2:02 AM, Adrian Sevcenco wrote:
On 01/10/12 11:12, Bennett Haselton wrote:
What about sshd -- assuming that the attacker can connect to sshd at all (i.e. not prevented by a firewall), if they find an exploit to let them take control of sshd, would that imply immediate total control of the
UsePrivilegeSeparation Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes. The default is ``yes''. If UsePrivilegeSeparation is set to ``sandbox'' then the pre-authentication unprivileged process is subject to additional restrictions.
http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5
OK. So it sounds like if you found a particular exploit in sshd that could *only* do certain things -- like write a file to an arbitrary location on disk -- then this privilege separation would prevent that exploit from being used to make the child process write somewhere that it didn't have privileges to write to.
On the other hand if you found an exploit that let you take complete control of sshd, you could just tell it "allow logins from root, accept 'foo' as the password, and then do whatever you were going to do before", and that would presumably work, wouldn't it?
Bennett
From: Bennett Haselton bennett@peacefire.org
On 1/10/2012 2:02 AM, Adrian Sevcenco wrote:
UsePrivilegeSeparation Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes. The default is
``yes''. OK. So it sounds like if you found a particular exploit in sshd that could *only* do certain things -- like write a file to an arbitrary location on disk -- then this privilege separation would prevent that exploit from being used to make the child process write somewhere that it didn't have privileges to write to.
Do a ps and look at the sshd tree. Example: root 6014 0.0 0.1 97816 3760 ? S 11:01 0:00 _ sshd: bob [priv] bob 6029 0.0 0.0 97816 1796 ? S 11:01 0:00 _ sshd: bob@pts/2 bob 6030 0.0 0.0 108392 1760 pts/2 Ss 11:01 0:00 _ -bash
The sshd child is running as bob; so it has bob (and not root) rights...
JD
On 1/10/2012 5:16 AM, John Doe wrote:
From: Bennett Haseltonbennett@peacefire.org
On 1/10/2012 2:02 AM, Adrian Sevcenco wrote:
UsePrivilegeSeparation Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes. The default is
``yes''. OK. So it sounds like if you found a particular exploit in sshd that could *only* do certain things -- like write a file to an arbitrary location on disk -- then this privilege separation would prevent that exploit from being used to make the child process write somewhere that it didn't have privileges to write to.
Do a ps and look at the sshd tree. Example: root 6014 0.0 0.1 97816 3760 ? S 11:01 0:00 _ sshd: bob [priv] bob 6029 0.0 0.0 97816 1796 ? S 11:01 0:00 _ sshd: bob@pts/2 bob 6030 0.0 0.0 108392 1760 pts/2 Ss 11:01 0:00 _ -bash
The sshd child is running as bob; so it has bob (and not root) rights...
JD
Yes, I understand that. What I said was that if you could take complete control of the sshd process you were connecting to, even if that process was completely unprivileged, you could still make it say "Accept a login from 'root' with password 'foo'" and then log in as root.
Bennett
From: Bennett Haselton bennett@peacefire.org
On 1/10/2012 5:16 AM, John Doe wrote:
The sshd child is running as bob; so it has bob (and not root) rights...
Yes, I understand that. What I said was that if you could take complete control of the sshd process you were connecting to, even if that process was completely unprivileged, you could still make it say "Accept a login from 'root' with password 'foo'" and then log in as root.
How would your bob owned child sshd take complete control of the parent root owned sshd...?
JD
On Tue, Jan 10, 2012 at 2:49 PM, John Doe jdmls@yahoo.com wrote:
From: Bennett Haselton bennett@peacefire.org
On 1/10/2012 5:16 AM, John Doe wrote:
The sshd child is running as bob; so it has bob (and not root)
rights...
Yes, I understand that. What I said was that if you could take complete control of the sshd process you were connecting to, even if that process was completely unprivileged, you could still make it say "Accept a login from 'root' with password 'foo'" and then log in as root.
How would your bob owned child sshd take complete control of the parent root owned sshd...?
JD
Or, if you simply WANT more layers, then deploy defense-in-depth in FRONT of sshd. VPN or port-knocking springs to mind
BR Bent
John Doe wrote:
From: Bennett Haselton bennett@peacefire.org
On 1/10/2012 5:16 AM, John Doe wrote:
The sshd child is running as bob; so it has bob (and not root) rights...
Yes, I understand that. What I said was that if you could take complete control of the sshd process you were connecting to, even if that process was completely unprivileged, you could still make it say "Accept a login from 'root' with password 'foo'" and then log in as root.
How would your bob owned child sshd take complete control of the parent root owned sshd...?
I have not read the details of any given exploit, but as I understand it, if one can craft an exploit that breaks in the middle of the login, the child would die, leaving one in the parent (root) process.
mark
On 10/01/12 13:34, Bennett Haselton wrote:
On 1/10/2012 5:16 AM, John Doe wrote:
From: Bennett Haseltonbennett@peacefire.org
On 1/10/2012 2:02 AM, Adrian Sevcenco wrote:
UsePrivilegeSeparation Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes. The default is
``yes''. OK. So it sounds like if you found a particular exploit in sshd that could *only* do certain things -- like write a file to an arbitrary location on disk -- then this privilege separation would prevent that exploit from being used to make the child process write somewhere that it didn't have privileges to write to.
Do a ps and look at the sshd tree. Example: root 6014 0.0 0.1 97816 3760 ? S 11:01 0:00 _ sshd: bob [priv] bob 6029 0.0 0.0 97816 1796 ? S 11:01 0:00 _ sshd: bob@pts/2 bob 6030 0.0 0.0 108392 1760 pts/2 Ss 11:01 0:00 _ -bash
The sshd child is running as bob; so it has bob (and not root) rights...
JD
Yes, I understand that. What I said was that if you could take complete control of the sshd process you were connecting to, even if that process was completely unprivileged, you could still make it say "Accept a login from 'root' with password 'foo'" and then log in as root.
Probably.
If a flaw were to exist in OpenSSH that allows execution of arbitrary code then pretty much anything is possible, which is why it is wise to always stay fully patched and limit exposure by only providing access (to the sshd service) to those that need it. Heck, even security through obscurity (running on a non-standard port) will limit exposure to the extent that the casual attacker scanning for machines vulnerable to a zero-day vulnerability will probably pass you by given the number of lower hanging fruit out there.
What you are talking about is essentially a zero-day vulnerability that's being actively exploited in the wild. So although you said you weren't talking about layers of security in front of sshd, these are exactly the layers of defence that will help limit the scope of such an attack. You can't look at security in isolation, you have to look at the whole picture, identify the risks in your systems and then take measures to mitigate those risks that are relevant to you. IOW, if you only access the system from a handful of locations, firewalling the sshd service to only allow access from those IP ranges essentially makes the rest of the discussion redundant. Similarly, running on a non-standard port will be highly effective against the casual attacker scanning large areas of the IP address space for vulnerable machines to attack, less so against a targeted attack.
On 01/10/2012 07:58 AM, Ned Slider wrote:
On 10/01/12 13:34, Bennett Haselton wrote:
On 1/10/2012 5:16 AM, John Doe wrote:
From: Bennett Haseltonbennett@peacefire.org
On 1/10/2012 2:02 AM, Adrian Sevcenco wrote:
UsePrivilegeSeparation Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes. The default is
``yes''. OK. So it sounds like if you found a particular exploit in sshd that could *only* do certain things -- like write a file to an arbitrary location on disk -- then this privilege separation would prevent that exploit from being used to make the child process write somewhere that it didn't have privileges to write to.
Do a ps and look at the sshd tree. Example: root 6014 0.0 0.1 97816 3760 ? S 11:01 0:00 _ sshd: bob [priv] bob 6029 0.0 0.0 97816 1796 ? S 11:01 0:00 _ sshd: bob@pts/2 bob 6030 0.0 0.0 108392 1760 pts/2 Ss 11:01 0:00 _ -bash
The sshd child is running as bob; so it has bob (and not root) rights...
JD
Yes, I understand that. What I said was that if you could take complete control of the sshd process you were connecting to, even if that process was completely unprivileged, you could still make it say "Accept a login from 'root' with password 'foo'" and then log in as root.
Probably.
If a flaw were to exist in OpenSSH that allows execution of arbitrary code then pretty much anything is possible, which is why it is wise to always stay fully patched and limit exposure by only providing access (to the sshd service) to those that need it. Heck, even security through obscurity (running on a non-standard port) will limit exposure to the extent that the casual attacker scanning for machines vulnerable to a zero-day vulnerability will probably pass you by given the number of lower hanging fruit out there.
What you are talking about is essentially a zero-day vulnerability that's being actively exploited in the wild. So although you said you weren't talking about layers of security in front of sshd, these are exactly the layers of defence that will help limit the scope of such an attack. You can't look at security in isolation, you have to look at the whole picture, identify the risks in your systems and then take measures to mitigate those risks that are relevant to you. IOW, if you only access the system from a handful of locations, firewalling the sshd service to only allow access from those IP ranges essentially makes the rest of the discussion redundant. Similarly, running on a non-standard port will be highly effective against the casual attacker scanning large areas of the IP address space for vulnerable machines to attack, less so against a targeted attack.
Ding, Ding, Ding .... what he <^^^> said :D
Limit access to the sshd port from only authorized places ... and the authorized places can be an openvpn type connection if you always need access from difference IPs. If you have a laptop, put an openvpn client on it and take it with you if you need access from dynamic places. Connect the openvpn to the endpoint someplace and then use that to connect to the sshd on the server via the vpn.
Wide open sshd ports on the Internet are dangerous.
There have been NO critical sshd security issues in any release of RHEL (and therefore CentOS) since 2003 ... and that was for CentOS-2.1. Critical being the kind that allows remote access directly via sshd ... please see this link for an explanation of the severities:
https://access.redhat.com/security/updates/classification/
So, the person is not getting sshd access remotely via an exploit. They MIGHT get access via some other exploit (httpd exploit of php code that provides shell access, something that then can escalate that to root level access (that would be an "Important" level of problem (allowing local user to escalate)) ... but the vast majority of the time, it is logins via the sshd port because of bad passwords (or published passwords, or e-mailed passwords, etc.), no IP control on the sshd port via iptables, allowing root to login directly, not using keys for access, etc.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 10.01.2012 19:05, schrieb Johnny Hughes:
Limit access to the sshd port from only authorized places ... and the authorized places can be an openvpn type connection if you always need access from difference IPs. If you have a laptop, put an openvpn client on it and take it with you if you need access from dynamic places. Connect the openvpn to the endpoint someplace and then use that to connect to the sshd on the server via the vpn.
I'm not convinced that would actually improve security. What that does is replace the risk of intrusion via an sshd exploit by the risk of intrusion via an OpenVPN exploit. But it also adds a layer of complexity, and complexity is the enemy of security. So the risk of an exploitable hole in OpenVPN would have to be provably so much lower than in SSH that the difference outweighs the increase of risk through added complexity. I don't know of any data to support that claim.
Wide open sshd ports on the Internet are dangerous.
That's a very bold statement. I guess its truth depends on your definition of "wide open". In fact I'd maintain that an open ssh port is less dangerous than most other open ports. (http, smtp, imap, to name a few)
Jm2c, T.
- -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany
On Thu, Jan 12, 2012 at 10:31 AM, Tilman Schmidt t.schmidt@phoenixsoftware.de wrote:
I'm not convinced that would actually improve security. What that does is replace the risk of intrusion via an sshd exploit by the risk of intrusion via an OpenVPN exploit.
Yes, but only to someone with inside information. You can't really hide an ssh server from a port scan, but openvpn on UDP will not respond to packets that aren't signed with the right key. You can't tell it from a firewall that drops packets at that address/port. And, if you do get the openvpn connection you only get network access - you still have to find a host on the other side and break into its ssh before you can do anything.
But it also adds a layer of complexity, and complexity is the enemy of security. So the risk of an exploitable hole in OpenVPN would have to be provably so much lower than in SSH that the difference outweighs the increase of risk through added complexity. I don't know of any data to support that claim.
Since you have to (a) find the connection, and (b) still break ssh, it seems logically more secure. Or are you thinking of the probably of a flaw in openvpn giving you arbitrary command access? I suppose you can't rule that out, but it is not as complicated as ssh so probably less to go wrong.
Wide open sshd ports on the Internet are dangerous.
That's a very bold statement. I guess its truth depends on your definition of "wide open". In fact I'd maintain that an open ssh port is less dangerous than most other open ports. (http, smtp, imap, to name a few)
You are pretty much guaranteed to get hacking attempts both by password guessing and vulnerability probes on all of those ports/services.
On 01/12/2012 10:31 AM, Tilman Schmidt wrote:
Am 10.01.2012 19:05, schrieb Johnny Hughes:
Limit access to the sshd port from only authorized places ... and the authorized places can be an openvpn type connection if you always need access from difference IPs. If you have a laptop, put an openvpn client on it and take it with you if you need access from dynamic places. Connect the openvpn to the endpoint someplace and then use that to connect to the sshd on the server via the vpn.
I'm not convinced that would actually improve security. What that does is replace the risk of intrusion via an sshd exploit by the risk of intrusion via an OpenVPN exploit. But it also adds a layer of complexity, and complexity is the enemy of security. So the risk of an exploitable hole in OpenVPN would have to be provably so much lower than in SSH that the difference outweighs the increase of risk through added complexity. I don't know of any data to support that claim.
Not at all ... you first have to crack the OpenVPN system to gain access to the ssh port at all (that did not get you into the machine, it got you an IP address that then allows you to TRY to access the machine) ... THEN ... you still have to do all the things you need to do to the openssl port to break into it. Without OpenVPN, you only need to do the second step and can totally skip the first. It would therefore make a actual machine breach exponentially harder.
Wide open sshd ports on the Internet are dangerous.
That's a very bold statement. I guess its truth depends on your definition of "wide open". In fact I'd maintain that an open ssh port is less dangerous than most other open ports. (http, smtp, imap, to name a few)
No, it's not. They need to use one of the other ports you mentioned to gain access to a method to grab your shadow file. Then after they gain access to your shadow file, they figure out the root (or another user's) password based on the hash ... then IF you have your ssh port unrestricted they use what they gained to login to your machine and take it over.
None of that can happen if you have restricted access to your openssh port ... they might find a password, but then they have no ability to login to the machine. If you have some kind of access restrictions to the ssh port AND also do not allow password logins, but also require keys (with a pass-phrase) to login ... then you have again made it exponentially harder to hack into.
On 1/12/2012 5:25 PM, Johnny Hughes wrote:
On 01/12/2012 10:31 AM, Tilman Schmidt wrote:
Am 10.01.2012 19:05, schrieb Johnny Hughes:
Limit access to the sshd port from only authorized places ... and the authorized places can be an openvpn type connection if you always need access from difference IPs. If you have a laptop, put an openvpn client on it and take it with you if you need access from dynamic places. Connect the openvpn to the endpoint someplace and then use that to connect to the sshd on the server via the vpn.
I'm not convinced that would actually improve security. What that does is replace the risk of intrusion via an sshd exploit by the risk of intrusion via an OpenVPN exploit. But it also adds a layer of complexity, and complexity is the enemy of security. So the risk of an exploitable hole in OpenVPN would have to be provably so much lower than in SSH that the difference outweighs the increase of risk through added complexity. I don't know of any data to support that claim.
Not at all ... you first have to crack the OpenVPN system to gain access to the ssh port at all (that did not get you into the machine, it got you an IP address that then allows you to TRY to access the machine) ...
I think Tilman is saying that rather than "cracking" OpenVPN in the sense of tricking into allowing you access, you could find an exploit in OpenVPN where simply sending the right packets to the OpenVPN server would allow you to execute arbitrary code as root on the server, the same way as an attacker might try to do to the sshd server.
Or is there a reason that an exploit against OpenVPN would be less powerful than an exploit against sshd?
This came up earlier, and you said that OpenVPN has had far fewer such exploits logged against it than sshd. In that case it really would be more secure, but not because it provides an extra "layer", but rather simply because exploits against it are more rare.
On Thursday 12 January 2012 18:56:04 Bennett Haselton wrote:
Or is there a reason that an exploit against OpenVPN would be less powerful than an exploit against sshd?
Not really.
The thing is that the tools are there but you have to use them *CORRECTLY*
The OpenVPN server and the SSH server you are trying to access should be in *different* machines. Like web servers, app servers and databases are separete:
http server | | | app server | | | mysql server
Same structure works for openvpn and ssh ;)
Regards
On 01/12/2012 08:56 PM, Bennett Haselton wrote:
On 1/12/2012 5:25 PM, Johnny Hughes wrote:
On 01/12/2012 10:31 AM, Tilman Schmidt wrote:
Am 10.01.2012 19:05, schrieb Johnny Hughes:
Limit access to the sshd port from only authorized places ... and the authorized places can be an openvpn type connection if you always need access from difference IPs. If you have a laptop, put an openvpn client on it and take it with you if you need access from dynamic places. Connect the openvpn to the endpoint someplace and then use that to connect to the sshd on the server via the vpn.
I'm not convinced that would actually improve security. What that does is replace the risk of intrusion via an sshd exploit by the risk of intrusion via an OpenVPN exploit. But it also adds a layer of complexity, and complexity is the enemy of security. So the risk of an exploitable hole in OpenVPN would have to be provably so much lower than in SSH that the difference outweighs the increase of risk through added complexity. I don't know of any data to support that claim.
Not at all ... you first have to crack the OpenVPN system to gain access to the ssh port at all (that did not get you into the machine, it got you an IP address that then allows you to TRY to access the machine) ...
I think Tilman is saying that rather than "cracking" OpenVPN in the sense of tricking into allowing you access, you could find an exploit in OpenVPN where simply sending the right packets to the OpenVPN server would allow you to execute arbitrary code as root on the server, the same way as an attacker might try to do to the sshd server.
Except there is no way to see the openvpn port if you don't first have a valid certificate from the server if the firewall is properly configured ... Les has explained this dozens of times on the list. Also, I normally do not put VPN on the server itself, but on an external device. It doesn't have to be openvpn ... it can be a cisco ipsec vpn, etc. If it was a machine at an ISP, I would use openvpn on the machine.
Or is there a reason that an exploit against OpenVPN would be less powerful than an exploit against sshd?
Sure ... an exploit against openvpn does not open a shell as root, that makes it MUCH less important. The vast majority of other exploits are also not actually against the OS itself but rather they normally target bad programming from some framework like php or java (or asp or .net on windows) where some kind of web application allows the user to send a file off the machine. As I have stated before, there hasn't been a remotely exploitable openssh (sshd) problem on CentOS or RHEL since version EL 2.1 in 2003. People are not getting into a machine by exploiting openssh ... they are exploiting data (or files) to gain access to people's passwords and then using that data to login normally on people's machines. They might be getting that data by sniffing packets when someone crosses their routers to login and check their e-mail or if someone has mailed them (unencrypted) the password, etc. Somehow they get password data, then they log in.
If there was some kind of access restriction (keys, iptables restricting IPs, etc) to the ssh logins, then even with the login credentials the bad guy can not gain a root shell on the machine. Their goal is normally not to open a rogue shell as the apache user (though things like SELinux make those things much less probable), it is to gain full root access via ssh on the machine. To do that, they need a exploit to gain access, and then be able to somehow escalate that access to some other user that can see or do something bad.
This came up earlier, and you said that OpenVPN has had far fewer such exploits logged against it than sshd. In that case it really would be more secure, but not because it provides an extra "layer", but rather simply because exploits against it are more rare.
I did not say that ... as I said before, most exploits do not just open up a shell that lets people have full access to your machine as root. Most exploits will allow someone to execute a command as the owner of the listening service (apache for httpd, as an example) that is running. SELinux greatly inhibits any of those processes (the initial rogue ones that the other exploited process allowed) being able to do things outside the contexts where the initial user (apache) is allowed to go. So, with SELinux enabled, if a person was able to use an exploit to put something in a tmp directory, they would not be able to make that file they put there executable and they would not be able to escalate the apache user to become root. They might be able to craft some kind of sql query to mail a SQL Dump of some application that maintains its usernames and passwords in it. If that data had anyone's username and password in it that would also be allowed to ssh into the machine (because they use the same password in their e-mail or on <X_WEB_APP> as the do to login) ... well then, they just use ssh and those credentials.
On 01/10/2012 01:12 AM, Bennett Haselton wrote:
What about sshd -- assuming that the attacker can connect to sshd at all (i.e. not prevented by a firewall), if they find an exploit to let them take control of sshd, would that imply immediate total control of the machine?
Yes, but the question itself ignores the extensive security that accompanies sshd.
OpenSSH's server already features defense-in-depth.
OpenSSH's server features privilege separation, a mechanism in which the network connections and encryption are handled by a process which is unprivileged. Attacks against connection handling or encryption won't get you root access.
OpenSSH's server code has been thoroughly audited for security.
Red Hat's build of OpenSSH's server features an SELinux policy. Attacks which require system access not granted by the policy won't work.
All of Red Hat's systems feature shared lib address randomization, to protect against stack attacks.
Your hypothetical attack that takes control of sshd would have to defeat a number of levels of defense. You compared sshd to httpd, which runs as a non-root user, but ignore that its *purpose* is to grant shell access to the system. No matter what additional layers you add to sshd, a successful attack is going to grant shell access, because that's the purpose of the daemon. You can't lower the privilege level of sshd to the point that an attacker can't get a shell (which is what was done to httpd) without making the service useless.
-
Adrian Sevcenco -
Bennett Haselton -
Bent Terp -
Gordon Messmer -
John Doe -
Johnny Hughes -
Les Mikesell -
m.roth＠5-cent.us -
Marc Deop -
Ned Slider -
Tilman Schmidt