The vulnerability is contained by the process's memory space, since one process cannot read another's memory by merely referencing it (although with exec priv a process can inspect another ...doesn't apply here). OpenSSH doesn't use OpenSSL, nor does su, so passwords aren't vulnerable when typed into them. If your mail server uses the OpenSSL port/pkg and password authentication, then passwords of users who logged in were vulnerable and need to be changed. Those passwords may have subsequently been used to log in so check their accounts for unwanted ..ssh/authorized_keys that an attacker may have dropped in for a back door. If one of those passwords allows root access...consider tje system fully compromised. On 2014-04-26 1:05 PM, "Joe Parsons" <[email protected]> wrote: > Ok, thanks a lot for all your kind help. I learned the pwd_mkdb manpage > and the databases as you suggested. > > To clarify, I understand 9.1 kernel contains the non-vulnerable version of > openssl library, hence mere apache/https is not vulnerable. However the > vulnerable openssl port is installed for the mail software to provide > imaps/pops/smtps services, so they are vulnerable. > > The following reply is what I'm confused: > > In any case, heartbleed does *not* facilitate remote code execution or > > code injection, only information retrieval, so unless your passwords > > were stored in cleartext (or a weakly hashed form) in the memory of an > > Internet-facing SSL-enabled service (such as https, smtp with STARTTLS > > or imaps, but not ssh), you cannot have been "hacked" as a consequence > > of heartbleed.I ssh into the system, and I /usr/bin/su to become root. > Do my shell passwords show up in in clear text in the memory briefly, so > the attacker could happen to harvest them? In another word, on a system > with the vulnerable openssl port, do we need to change the shell password > for root and other users, if these passwords are ONLY used in ssh and > /usr/bin/su ? > > I googled and found few result, almost all are focused on changing user > mail passwords and server certificates. Only found this page said they > changed server root password: > > http://digitalopera.com/geek-rants/what-were-doing-to-combat-heartbleed/ > > Thanks, Joe > > > From: [email protected] > > Date: Sat, 26 Apr 2014 12:02:05 -0500 > > Subject: Re: am I NOT hacked? > > To: [email protected] > > CC: [email protected] > > > > Joe, > > > > Just thinking about this practically, I don't think you were compromised. > > It seems more like you goofed the upgrade in the same way on each VM. > Also, > > if I were attacking, I wouldn't leave such overt traces that one would > > immediately notice. And if the attacker were goofing up that badly, he'd > > likely not do it the same way on every VM. Not that assuming anything > about > > an attacker's intelligence guarantees anything, but it does seem like an > > odd thing to do. Not to mention other's comments about pre-10 not being > > vulnerable, and local compromise requiring that your password or SSH key > > was read by a process serving SSL sockets. > > > > If you decide it's likely your system was compromised while it was > > vulnerable, shutting off the system is a priority to stop ongoing > damages. > > Then you have to mount its disks in a clean system so that whatever bad > > stuff (bots, backdoors, etc) the attacker added don't just start again at > > reboot, and to be sure the attacker doesn't merely add backdoors back > while > > you take them away. It's hard to be sure you fixed every single file that > > was touched ...executables, dynamic libs, configs, and much more contain > > subtle ways to leave a back door, and one could even patch the kernel to > > hide a malicious process in memory. Starting from a fresh install and > > copying your data over is really the quickest and safest approach. Since > > "restore your data" usually means home directories, be sure to check > > everyone's .ssh/authorized_keys for unwanted entries before copying. > > > > Try "man pwd_mkdb" for info on the password database; especially look > under > > the "FILES" heading. It's a good subsystem to know more about anyway, and > > not complicated. It is perhaps easier to remember that using vipw to add > a > > blank line will sync everything than to remember the cryptic "pwd_mkdb -p > > /etc/master.passwd" command though. > > > > Actually having a machine compromised is no fun; I've been there. I do > hope > > that's not the case for you. > > > > - Leif > > > > > > On Sat, Apr 26, 2014 at 4:55 AM, Joe Parsons <[email protected]> wrote: > > > > > I was slow to patch my multiple vms after that heartbleed disclosure. > I > > > just managed to upgrade these systems to 9.2, and installed the patched > > > openssl, then started changing passwords for root and other shell > users. > > > However I realized that, only the root password was changed. For > other > > > users, even though the "passwd userid" issued no warning, and "echo > $?" is > > > 0, the password is NOT changed. > > > > > > For more debugging, I tried to "adduser", the command was successful, > and > > > I can see the new entry "test" in /etc/passwd. However "finger test" > > > complains no such user! Also, "rm test" complains there is no such > user to > > > delete as well. > > > > > > Furthermore, the mail server got problem sending email, the log file > said > > > there is no such user "postfix", and sure enough: > > > > > > # finger postfix > > > finger: postfix: no such user > > > > > > while this "postfix" user certainly existed for years, and I can see > see > > > its entry in /etc/passwd. > > > > > > This appeared to all the multiple vms on multiple hosts, all running > > > FreeBSD 9.2 now. > > > > > > I was paranoid, I really should have patched all these systems > immediately > > > reading that heartbleed news, as all these servers had the vulnerable > > > openssl port installed! > > > > > > Until googling and I found this: > > > > > > https://forums.freebsd.org/viewtopic.php?&t=29644 > > > > > > it said "The user accounts are actually stored in a database. It's > > > possible it got out of sync with your [file]/etc/passwd[/file] file.", > and > > > it suggested running "vipw" to fix it. > > > > > > I ran vipw, then saved, and quit. No joy. Then ran vipw again, made a > > > change, then undid the change, save again. Now "finger postfix" found > the > > > user, and I can change user password now, and all the above problem > > > disappeared. > > > > > > Am I right that, that I am NOT hacked? Is the above problem produced > by > > > the freebsd-update process? Is this supposed to happen? I just > followed > > > the handbook to update from 9.1-RELEASE to 9.2-RELEASE, never compiled > > > kernel or tweak. > > > > > > Thank you! Joe > > > > > > _______________________________________________ > > > [email protected] mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > > To unsubscribe, send any mail to " > [email protected] > > > " > > > > > > > > > > > -- > > > > As implied by email protocols, the information in this message is > > not confidential. Any middle-man or recipient may inspect, modify, > > copy, forward, reply to, delete, or filter email for any purpose unless > > said parties are otherwise obligated. As the sender, I acknowledge that > > I have a lower expectation of the control and privacy of this message > > than I would a post-card. Further, nothing in this message is > > legally binding without cryptographic evidence of its integrity. > > > > http://bilbo.hobbiton.org/wiki/Eat_My_Sig > > _______________________________________________ > > [email protected] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to " > [email protected]" > > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "[email protected] > " > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"