OS X/Linker: New Mac malware attempts zero-day Gatekeeper bypass
1–10 of 19 posts
Re: OS X/Linker: New Mac malware attempts zero-day Gatekeeper bypass
#2so...
sudo vi /etc/auto_master
#/net -hosts -nobrowse,hidefromfinder,nosuid
Re: OS X/Linker: New Mac malware attempts zero-day Gatekeeper bypass
#3> However, because the .app inside the disk images is dynamically linked, it could change on the server side at any time—without the disk image needing to be modified at all.
Wait, what? This makes no sense: dynamic linking means that it would pull in different libraries on the user’s machine…
Re: OS X/Linker: New Mac malware attempts zero-day Gatekeeper bypass
#4> However, because the .app inside the disk images is dynamically linked, it could change on the server side at any time—without the disk image needing to be modified at all. Wait, what? This makes no sense: dynamic linking means that it would pull in different libraries on the user’s machine…
It's dynamic in the context of a symlink, not meaning dynamic libraries.
Re: OS X/Linker: New Mac malware attempts zero-day Gatekeeper bypass
#5> However, because the .app inside the disk images is dynamically linked, it could change on the server side at any time—without the disk image needing to be modified at all. Wait, what? This makes no sense: dynamic linking means that it would pull in different libraries on the user’s machine…
The article author means filesystem links, not libraries. Earlier in the article:
> [...] creating a symbolic link (or "symlink"—similar to an alias) to an app hosted on an attacker-controlled Network File System (NFS) server, and then creating a .zip archive containing that symlink [...]
Re: OS X/Linker: New Mac malware attempts zero-day Gatekeeper bypass
#6> it seems reasonable to speculate that all four files may have been uploaded by the same person, who forgot to mask his or her IP address until after uploading the first sample.
Or turned it off after the first sample. Or switches proxies randomly. It's good they brought up that the IP can be masked, but they could go one step further...
Re: OS X/Linker: New Mac malware attempts zero-day Gatekeeper bypass
#7HN discussion about the 0-day [0].
Re: OS X/Linker: New Mac malware attempts zero-day Gatekeeper bypass
#8> However, because the .app inside the disk images is dynamically linked, it could change on the server side at any time—without the disk image needing to be modified at all. Wait, what? This makes no sense: dynamic linking means that it would pull in different libraries on the user’s machine…
It's dynamic in the context of a symlink, not meaning dynamic libraries.
Oh, that makes more sense. That sentence would be much improved by switching those words around, because I’m too conditioned to apps being dynamically linked in the library/framework :)
Re: OS X/Linker: New Mac malware attempts zero-day Gatekeeper bypass
#9so... sudo vi /etc/auto_master #/net -hosts -nobrowse,hidefromfinder,nosuid
What does that do?
Re: OS X/Linker: New Mac malware attempts zero-day Gatekeeper bypass
#10so... sudo vi /etc/auto_master #/net -hosts -nobrowse,hidefromfinder,nosuid
What does that do?
From the article:
For home users, unfortunately there isn't a simple solution for preventing this type of attack, until or unless Apple releases a macOS security update to mitigate the vulnerability. Cavallarin describes a possible temporary mitigation (opening /etc/auto_master in a text editor and adding # to the beginning of the line that starts with /net).