On 26.4.2014, at 21.17, Joe Parsons <[email protected]> wrote: > Sorry, one paragraph of my last reply appears to be screwed up on the web > archive. You can ignore that reply and just read the following. I'm sorry > for the confusion. > > > 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 >
You’re missing a few fundamental properties of a modern operating system, memory management and memory protection. The sshd or the su processes might have the passwords in the clear in their own memory for some time but any other process (for example the web server with the vulnerable OpenSSL) has no access to that memory because of how virtual memory works. Every process has its own private memory space and the process can not address memory owned by other processes. For example, a process running on i386 can try to address all of the 4GBs that the i386 instruction set allows it to do but none of the memory that it can read or write belongs to another process because the OS keeps the those private address spaces separate from each other using the memory management hardware on the CPU. -Kimmo
signature.asc
Description: Message signed with OpenPGP using GPGMail
