On Wed, Feb 4, 2015 at 4:55 PM, Warren Young <wyml at etr-usa.com> wrote:>>> >> There have been remotely exploitable vulnerabilities where an arbitrary file could be read > > CVEs, please? > > I?m aware of vulnerabilities that allow a remote read of arbitrary files that are readable by the exploited process?s user, but for such an exploit to work on /etc/shadow, the process has to be running as root. > > Most such vulns are against Apache, PHP, etc, which do not run as root.Those are common. Combine them with anything called a 'local privilege escalation' vulnerability and you've got a remote root exploit. And people will know how to combine them.> One of the biggest reasons for the mass exodus from Sendmail to qmail/exim/postfix/etc was to get away from a monolithic program that had to run as root to do its work.Except that sendmail was fixed. And when the milter interface was added it became even less monolithic.>> Further, lists of usernames and passwords have market value. > > Of course. But that?s a different thing than we were discussing.Not exactly - it just becomes a question of whether the complexity requirements imposed by the installer are really worth much against the pre-hashed lists that would be used to match up the shadow contents. -- Les Mikesell lesmikesell at gmail.com
> On Feb 4, 2015, at 4:14 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > > Not exactly - it just becomes a question of whether the complexity > requirements imposed by the installer are really worth much against > the pre-hashed lists that would be used to match up the shadow > contents.Rainbow tables don?t help against salted hashes. Rainbow tables are for attacking *un*salted hashes, like NTLM used. https://crackstation.net/hashing-security.htm When the hashes are properly salted, the only option is brute force. All having /etc/shadow does for you is let you make billions of guesses per second instead of 5 guesses per minute, as you get with proper throttling on remote login avenues.
On 5 February 2015 at 10:36, Warren Young <wyml at etr-usa.com> wrote:> When the hashes are properly salted, the only option is brute force. All having /etc/shadow does for you is let you make billions of guesses per second instead of 5 guesses per minute, as you get with proper throttling on remote login avenues.Kinda highlights that 'time' is important here. Booting into a fresh system and then running updates and hardening your system can take a few minutes. There may be an appreciable difference between having a password that can be cracked in 1 second and one that takes an hour. (Yes, infrastructure can help mitigate this risk). I'm thinking of someone with limited infrastructure installing a system under time pressure. They might be tempted to use a very weak password initially with the expectation that they would get back to hardening the system later. If they are regularly under time pressure, that may never actually happen, or may be delayed for hours/days. An 8 character password might just nudge the probabilities in your favour and protect against a drive by attack. Does that sound like a reasonable case to protect against?
> On Feb 4, 2015, at 4:14 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > > On Wed, Feb 4, 2015 at 4:55 PM, Warren Young <wyml at etr-usa.com> wrote: >>>> >> Most such vulns are against Apache, PHP, etc, which do not run as root. > > Those are common. Combine them with anything called a 'local > privilege escalation' vulnerability and you've got a remote root > exploit.Not quite. An LPE can only be used against your system by logged-in users. To make a blended attack that can read /etc/shadow from an LPE, you need either SSH access or a remote shell vuln, not an arbitrary file read vuln. Holes that expose an unintended remote shell are quite a bit rarer than ones that allow a service like Apache to send you any file their non-root account has permission to read. It?s a bit like calling lightning to find a system where both types of vulnerabilities are available at the same time.
While this discussion has been very interesting, I would like to encourage participants to be very careful about disclosing the specifics their own security efforts. While is good to discuss the pros and cons of strategies, disclosing the details of the exact strategies that you use, no matter how good they are, is a bad idea. This is typically hard information for an attacker to acquire and they would run the risk of generating too much noise if they were to try to acquire it. A somewhat subtle trap is to disclose information about time, e.g., when you last changed a password on a system.
On Wed, Feb 4, 2015 at 6:32 PM, Warren Young <wyml at etr-usa.com> wrote:>>>> Most such vulns are against Apache, PHP, etc, which do not run as root. >> >> Those are common. Combine them with anything called a 'local >> privilege escalation' vulnerability and you've got a remote root >> exploit. > > Not quite. An LPE can only be used against your system by logged-in users.Or any running program - like a web server.> To make a blended attack that can read /etc/shadow from an LPE, you need either SSH access or a remote shell vuln, not an arbitrary file read vuln. Holes that expose an unintended remote shell are quite a bit rarer than ones that allow a service like Apache to send you any file their non-root account has permission to read. > > It?s a bit like calling lightning to find a system where both types of vulnerabilities are available at the same time.No, you exploit the server application hole to tell you about the kernel vulnerability. The last one I saw in the wild involved the symlink race in the kernel around centos 5.2 or .3 and a struts java library bug. But there are people who know what combinations of vulnerabilities to try. -- Les Mikesell lesmikesell at gmail.com