On 02/04/2015 04:55 PM, Warren Young wrote:> Unless you have misconfigured your system, anyone who can copy > /etc/shadow already has root privileges. They don?t need to crack your > passwords now. You?re already boned.Not exactly. There have been remotely exploitable vulnerabilities where an arbitrary file could be read (not written), but otherwise root access wasn't given by the exploit; that is, no shellcode per se. If you can somehow (buffer overflow shellcode or something similar) get, say, httpd to return a copy of /etc/shadow in a GET request, well, you don't have root, but you do have the hashed passwords. It doesn't take an interactive root session, and may not even leave a trace of the activity depending upon the particular bug being exploited. Now, I have seen this happen, on a system in the wild, where the very first thing the attacker did was grab a copy of /etc/shadow, even with an interactive reverse shell and root access being had. So even when you recover your system from the compromise you have the risk of all those passwords being known, and unfortunately people have a habit of using the same password on more than one system. Further, lists of usernames and passwords have market value.
> On Feb 4, 2015, at 3:16 PM, Lamar Owen <lowen at pari.edu> wrote: > > On 02/04/2015 04:55 PM, Warren Young wrote: >> Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don?t need to crack your passwords now. You?re already boned. > > Not exactly. > > There have been remotely exploitable vulnerabilities where an arbitrary file could be readCVEs, 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. 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.> If you can somehow ...get, say, httpd to return a copy of /etc/shadowhttpd doesn?t have permission to read /etc/shadow, two ways. First, it?s not running as root, and second, you?re running SELinux, *RIGHT*? The default configuration of SELinux on CentOS won?t let httpd read *anything* outside its normal service directories. But of course the same people fighting this move to more secure password minima are the same ones that turn off SELinux.> Now, I have seen this happen, on a system in the wild, where the very first thing the attacker did was grab a copy of /etc/shadow... > > Further, lists of usernames and passwords have market value.Of course. But that?s a different thing than we were discussing.
I just had a peek at the anaconda source for Fedora 21. Apparently
you can waive the password strength tests (and the non-ASCII tests) by
simply clicking "Done" twice.
def _checkPasswordASCII(self, inputcheck):
"""Set an error message if the password contains
non-ASCII characters.
Like the password strength check, this check can be bypassed by
pressing Done twice.
"""
Kahlil (Kal) Hodgson GPG: C9A02289
Head of Technology (m) +61 (0) 4 2573 0382
DealMax Pty Ltd
Suite 1416
401 Docklands Drive
Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore,
if you can't get them together again, there must be a reason. By all
means, do not use a hammer." -- IBM maintenance manual, 1925
On 5 February 2015 at 09:16, Lamar Owen <lowen at pari.edu>
wrote:> On 02/04/2015 04:55 PM, Warren Young wrote:
>>
>> Unless you have misconfigured your system, anyone who can copy
/etc/shadow
>> already has root privileges. They don?t need to crack your passwords
now.
>> You?re already boned.
>
>
> Not exactly.
>
> There have been remotely exploitable vulnerabilities where an arbitrary
file
> could be read (not written), but otherwise root access wasn't given by
the
> exploit; that is, no shellcode per se. If you can somehow (buffer overflow
> shellcode or something similar) get, say, httpd to return a copy of
> /etc/shadow in a GET request, well, you don't have root, but you do
have the
> hashed passwords. It doesn't take an interactive root session, and may
not
> even leave a trace of the activity depending upon the particular bug being
> exploited.
>
> Now, I have seen this happen, on a system in the wild, where the very first
> thing the attacker did was grab a copy of /etc/shadow, even with an
> interactive reverse shell and root access being had. So even when you
> recover your system from the compromise you have the risk of all those
> passwords being known, and unfortunately people have a habit of using the
> same password on more than one system.
>
> Further, lists of usernames and passwords have market value.
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
> On Feb 4, 2015, at 3:56 PM, Kahlil Hodgson <kahlil.hodgson at dealmax.com.au> wrote: > > I just had a peek at the anaconda source for Fedora 21.This change isn?t in a released version of Fedora yet: https://lists.fedoraproject.org/pipermail/test/2015-January/124827.html The change will probably be in Fedora 22, and it?s being discussed here because there?s every reason to think we?ll see the change in CentOS 8.
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 Thu, Feb 05, 2015 at 09:56:30AM +1100, Kahlil Hodgson wrote:> I just had a peek at the anaconda source for Fedora 21. Apparently > you can waive the password strength tests (and the non-ASCII tests) by > simply clicking "Done" twice.That's correct for Fedora 21. The inability to waive the requirement will show up in the new Anaconda. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6