Re: secure MTA
On Thu, Apr 09, 2020 at 04:24:34PM +0100, Kevin Chadwick wrote: > > > Now this whole debate boils down to "how much effort is someone willing to > > invest > > into hacking Cord's computers?", and that's something I can't answer. > > And how competent Cord is at defending his computer because they may not be > able > to if he is competent enough, which is my point; It is not just about "how > much > effort an attacker is willing to invest". However, at the end of the day, like > it says in the faq. If black suits in helcopters come and demand your > password, > it almost certainly doesn't matter if your computer is secure! In fact we must assume that Cords computer is already hacked without him being aware of it at all. The emails that APPEAR to come from him is actually the hackers trying to hack into OUR computers by having us revealing whether we're running some not-guaranteed unhackable servers of any kind. https://dilbert.com/strip/1995-09-17
Re: secure MTA
> Now this whole debate boils down to "how much effort is someone willing to > invest > into hacking Cord's computers?", and that's something I can't answer. And how competent Cord is at defending his computer because they may not be able to if he is competent enough, which is my point; It is not just about "how much effort an attacker is willing to invest". However, at the end of the day, like it says in the faq. If black suits in helcopters come and demand your password, it almost certainly doesn't matter if your computer is secure! I was objecting to a particular comment that you still lament.
Re: secure MTA
> Conversely, if everything was easily hackable then we probably wouldn't use > computers, at all. Being hacked is a risk everybody is ready to accept, some knowingly, some unknowingly. There may be people here, who have never done business with any of these entities listed here, but they are certainly a minority: https://informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/ Some of these companies were probably run by incompetent monkeys, but most definitely not all of them. Some other companies may not show up here, because they managed to brush the issue under the rug, or because they haven't even learned about an ongoing incident yet. On the other side I am reasonably sure, that I personally haven't gotten hacked yet, but that has more to do with me being quite uninteresting than with hax0r mad skillz. Now this whole debate boils down to "how much effort is someone willing to invest into hacking Cord's computers?", and that's something I can't answer. Cord at least claims there is someone out there to get him. Let's see, how this whole story unfolds.
Re: secure MTA
On 2020-04-09 10:55, Rudolf Leitgeb wrote: > My point was, that security is an ongoing effort. Flaws and new > exploit venues are discovered. There will be different numbers > of flaws for different operating systems, but none remains unscathed > for years. As soon as your server does anything useful, it will > present an attack vector to the outside world, and one needs to > be aware of it. OpenBSD has remained unscathed for years with sshd listening by default, despite sshd doing some complicated things. Take ipv6 out of the picture and it's a very long time? Note that ipv6 is way more complex than it should have been like ASN.1, due to a committee. OpenBSD resisted ipv6 for a long time and I still don't use it, neither does my phone network or ISPs, on my side. I'm not sure anyone has said OpenBSD is infallible or that what OpenBSD strives to achieve isn't great. What I said was that the idea that everything is hackable is complete nonsense. I am not saying sshd is infallible but you can run all sorts behind sshd and it be a very useful server. You can take some of the security designs like priv sep of sshd and make a simpler service arguably unhackable. People have put services out there and said I will pay you to hack me and remained unhacked. Maybe the amount was too small. You could argue sshd will be broken by quantum cryptography one day. It might and it might not, the mantra "everything is hackable", is still misleading and FUD. Conversely, if everything was easily hackable then we probably wouldn't use computers, at all. "unhackable" is an unknown. It is normal to fear the unknown. It is right to hold many to a higher standard of security. Saying everything is unhackable is almost like saying what's the point in securing anything, or spend lots of money and we will worry about that for you. That is wrong.
Re: secure MTA (was: news from ...)
On 09.04.20 11:55, Rudolf Leitgeb wrote: > As soon as your server does anything useful, it will > present an attack vector to the outside world, and one needs to > be aware of it. > just to add to your argument: your server does not even have to do anything ... the interface driver or just the tcp ip stack can also be vulnerable. e.g. I hit the nasty bug in OpenBSD 6.0 where ipv6 router advertisements did crash my freshly installed boxes remotely ... this was one of those "WTF" moments when you stand in front of your racks and see 4 kernel panics at the same time. And where there is such a bug, there might be a possibility to inject a payload and execute stuff.
Re: secure MTA (was: news from ...)
On Wed, 2020-04-08 at 13:55 -0400, Allan Streib wrote: > My (default) smtpd.conf says: > > listen on lo0 > > So how might that be remotely exploitable? I can disable all network connections on an unpatched Windows 95 laptop - oh, this would make it s secure ... Hint: a server, which provides no services to the outside, is very secure and at the same time completely useless! I personally welcome OpenBSD's decision to turn off most services per default, but that's not the point here. Even as a client you are exposed, since most browsers are bug fests of their own. The same is true of office productivity software and just about anything else. My point was, that security is an ongoing effort. Flaws and new exploit venues are discovered. There will be different numbers of flaws for different operating systems, but none remains unscathed for years. As soon as your server does anything useful, it will present an attack vector to the outside world, and one needs to be aware of it.
Re: secure MTA (was: news from ...)
Claus Assmann writes: > On Wed, Apr 08, 2020, Kevin Chadwick wrote: > >> OpenSMTPD does not listen to the internet, by default and even if you do set >> it > > From: Qualys Security Advisory > To: oss-secur...@lists.openwall.com > Message-ID: <20200224184538.GF17396@localhost.localdomain> > > - Client-side exploitation: This vulnerability is remotely exploitable > in OpenSMTPD's (and hence OpenBSD's) default configuration. Although > ^^^ My (default) smtpd.conf says: listen on lo0 So how might that be remotely exploitable? Allan
Re: secure MTA
Claus Assmann wrote: > > Qualsys chose to call that remote, at a stretch. Either way, it does not > > change > > It seems to be similar to "if you visit a compromised website"... Which is not remote, either. > Anyway, it doesn't seem to be productive to argue terminology etc, > hence: sorry for the interruption and I stop now. Often said by those who are wrong.
Re: secure MTA
On Wed, Apr 08, 2020, Kevin Chadwick wrote: > You missed some out. I assume on purpose. Wrong "assumption"; I did it to keep it short -- I included the info how someone could find the details. > So it does require internal users to make an action and a MITM or outbound > connection to an attacker controlled server and not an incoming connection... Yes, it requires you to send mail according to the exploit that was posted. I did not try it myself and I did not see a followup stating "this does not work". So if that example does not work, maybe someone can clarify? > Qualsys chose to call that remote, at a stretch. Either way, it does not > change It seems to be similar to "if you visit a compromised website"... Anyway, it doesn't seem to be productive to argue terminology etc, hence: sorry for the interruption and I stop now. - Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: secure MTA
On 2020-04-08 18:39, Claus Assmann wrote: > - Client-side exploitation: This vulnerability is remotely exploitable > in OpenSMTPD's (and hence OpenBSD's) default configuration. Although You missed some out. I assume on purpose. Client-side exploitation: This vulnerability is remotely exploitable in OpenSMTPD's (and hence OpenBSD's) default configuration. Although OpenSMTPD listens on localhost only, by default, it does accept mail from local users and delivers it to remote servers. If such a remote server is controlled by an attacker (either because it is malicious or compromised, or because of a man-in-the-middle, DNS, or BGP attack -- SMTP is not TLS-encrypted by default), then the attacker can execute arbitrary shell commands on the vulnerable OpenSMTPD installation. So it does require internal users to make an action and a MITM or outbound connection to an attacker controlled server and not an incoming connection... Qualsys chose to call that remote, at a stretch. Either way, it does not change the point around "everything is hackable" being false. I never brought up smtpd and never said smtpd was unhackable!
Re: secure MTA (was: news from ...)
On Wed, Apr 08, 2020, Kevin Chadwick wrote: > OpenSMTPD does not listen to the internet, by default and even if you do set > it From: Qualys Security Advisory To: oss-secur...@lists.openwall.com Message-ID: <20200224184538.GF17396@localhost.localdomain> - Client-side exploitation: This vulnerability is remotely exploitable in OpenSMTPD's (and hence OpenBSD's) default configuration. Although ^^^ > Is it hard to write a secure mail server, sure. Look at exims bugs. [Is that like saying: "Is it hard to write a secure OS, sure. Look at Linux bugs."? ] How about qmail (or postfix)? (and some other barely known MTA) -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
