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]"