MacOS High Sierra Users: Change Root Password Now
Security Bot last edited by
A newly-discovered flaw inmacOS High Sierra :undefined:—:undefined: Apple:undefined:’:undefined:s latest iteration of its operating system :undefined:—:undefined: allows anyone with local (and, apparently in some cases, remote) access to the machine to log in as the all-powerful :undefined:“:undefined:root:undefined:”:undefined: user without supplying a password. Fortunately, there is a simple fix for this until Apple patches this inexplicable bug: Change the root account:undefined:’:undefined:s passwordnow.
For better or worse, this glaring vulnerability was first disclosed today on Twitter by Turkish software developerLemi Orhan Ergin, who unleashed his findings onto the Internet witha tweet to @AppleSupport:
:undefined:“:undefined:Dear @AppleSupport, we noticed aHUGE security issue at MacOS High Sierra. Anyone can login as :undefined:“:undefined:root:undefined:”:undefined: with empty password after clicking on login button several times. Are you aware of it @Apple?:undefined:”:undefined:
High Sierra users should be able to replicate the exploit by accessing System Preferences, then Users & Groups, and then click the lock to make changes. Type :undefined:“:undefined:root:undefined:”:undefined: with no password, and simply try that several times until the system relents and lets you in.
How does one change the root password? It:undefined:’:undefined:s simple enough. Open up a Terminal (in the Spotlight search box just type :undefined:“:undefined:terminal:undefined:”:undefined:) and type :undefined:“:undefined:sudo passwd root:undefined:”:undefined:.
Many people responding to that tweet said they were relieved to learn that this extremely serious oversight by Apple does not appear to be exploitable remotely. However, sources who have tested the bug say it can be exploited remotely if a High Sierra user a) has not changed the root password yet and b) has enabled :undefined:“:undefined:screen sharing:undefined:”:undefined: on their Mac.
Likewise, multiple sources have now confirmed thatdisabling the root account does not fix the problem because the exploit actually causes the account to be re-enabled.
There may be other ways that this vulnerability can be exploited: I:undefined:’:undefined:ll update this post as more information becomes available. But for now, if you:undefined:’:undefined:re using macOS High Sierra, take a moment to change the root password now, please.
Make ISO from DVD
In this case I had an OS install disk which was required to be on a virtual node with no optical drive, so I needed to transfer an image to the server to create a VM
Find out which device the DVD is:lsblk
Output:NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 464.8G 0 part ├─centos-root 253:0 0 50G 0 lvm / ├─centos-swap 253:1 0 11.8G 0 lvm [SWAP] └─centos-home 253:2 0 403G 0 lvm /home sdb 8:16 1 14.5G 0 disk /mnt sr0 11:0 1 4.1G 0 rom /run/media/rick/CCSA_X64FRE_EN-US_DV5
Therefore /dev/sr0 is the location , or disk to be made into an ISO
I prefer simplicity, and sometimes deal with the fallout after the fact, however Ive repeated this countless times with success.dd if=/dev/sr0 of=win10.iso
Where if=Input file and of=output file
I chill out and do something else while the image is being copied/created, and the final output:8555456+0 records in 8555456+0 records out 4380393472 bytes (4.4 GB) copied, 331.937 s, 13.2 MB/s
Recreate postrgresql database template encode to ASCIIUPDATE pg_database SET datistemplate = FALSE WHERE datname = 'template1';
Now we can drop it:DROP DATABASE template1;
Create database from template0, with a new default encoding:CREATE DATABASE template1 WITH TEMPLATE = template0 ENCODING = 'UNICODE'; UPDATE pg_database SET datistemplate = TRUE WHERE datname = 'template1'; \c template1 VACUUM FREEZE;