Well, it could just be an example of an InputManager, which would be
nothing new. I non-Admin user can create an InputManager bundle in ~/
Library/InputManagers, which would get loaded for every app that user
launches. An Admin user (even without authenticating) can create one
in /Library/InputManagers, which would get loaded for all users.
Affects Cocoa apps only.
See <http://db.tidbits.com/article/08430> for info about the dangers
of InputManagers.
On 25 Nov 2006, at 14:50, Sûnnet Beskerming wrote:
> First reported by the Finnish Information Security company, F-
> Secure (http://www.f-secure.com/weblog/archives/
> archive-112006.html#00001030), a new proof-of-concept piece of
> malware that specifically targets OS X has been identified. Dubbed
> IAdware, the PoC is designed to open the browser every time that an
> application is opened (as a demonstration that more can be done).
>
> Although the exact mechanism was not disclosed, the coverage
> suggests that exploitation will be limited to only the applications
> that the user has run access to (which should be relatively limited
> in a non-privileged account) and infection does not appear to
> actually modify the parent application bundle. The claim that it
> requires copy permissions to a System Library (~/Library, /
> Library, /usr/lib, or /System is not specified) rules out certain
> Mach-O header modification techniques, as well as preventing lesser
> privileged users from being infected due to a basic lack of write
> access to many sensitive directories.
>
> Based on the available technical documentation from Apple regarding
> dynamically loading code at application runtime, and in conjunction
> with the limited information released by F-Secure, the most likely
> targeted directory is '/usr/lib'. This would make the malware a
> dynamic library infector (libSystem.B.dylib would provide the most
> consistent activation vector) - sort of equivalent to a malicious
> win32.dll on Windows. Luckily for most users, a default system
> installation will prevent non-admin users from writing to that
> directory (and other critical system library directories). The
> other options for dynamic loading of code at runtime are not as
> likely to result in consistent exploitation across arbitrary
> applications, or are based on binary modification of key system
> applications (considered extremely unlikely based on the limited
> screen capture F-Secure provides).
>
> It is also not known whether it is related to Macarena (Symantec)
> or MachoMan (Independent release), which are two recent OS X
> malware samples. It is, however, considered unlikely to be related
> to these releases.
>
> In summary, the key deviation from normal system operation that
> this malware seems to require is write access to an unnamed System
> Library (F-Secure's claim of need for admin rights to exploit is
> counter-intuitive at this point). So long as users refrain from
> running rampant in their admin accounts, this malware should pose
> little threat, even if it does get into the wild.
nothing new. I non-Admin user can create an InputManager bundle in ~/
Library/InputManagers, which would get loaded for every app that user
launches. An Admin user (even without authenticating) can create one
in /Library/InputManagers, which would get loaded for all users.
Affects Cocoa apps only.
See <http://db.tidbits.com/article/08430> for info about the dangers
of InputManagers.
On 25 Nov 2006, at 14:50, Sûnnet Beskerming wrote:
> First reported by the Finnish Information Security company, F-
> Secure (http://www.f-secure.com/weblog/archives/
> archive-112006.html#00001030), a new proof-of-concept piece of
> malware that specifically targets OS X has been identified. Dubbed
> IAdware, the PoC is designed to open the browser every time that an
> application is opened (as a demonstration that more can be done).
>
> Although the exact mechanism was not disclosed, the coverage
> suggests that exploitation will be limited to only the applications
> that the user has run access to (which should be relatively limited
> in a non-privileged account) and infection does not appear to
> actually modify the parent application bundle. The claim that it
> requires copy permissions to a System Library (~/Library, /
> Library, /usr/lib, or /System is not specified) rules out certain
> Mach-O header modification techniques, as well as preventing lesser
> privileged users from being infected due to a basic lack of write
> access to many sensitive directories.
>
> Based on the available technical documentation from Apple regarding
> dynamically loading code at application runtime, and in conjunction
> with the limited information released by F-Secure, the most likely
> targeted directory is '/usr/lib'. This would make the malware a
> dynamic library infector (libSystem.B.dylib would provide the most
> consistent activation vector) - sort of equivalent to a malicious
> win32.dll on Windows. Luckily for most users, a default system
> installation will prevent non-admin users from writing to that
> directory (and other critical system library directories). The
> other options for dynamic loading of code at runtime are not as
> likely to result in consistent exploitation across arbitrary
> applications, or are based on binary modification of key system
> applications (considered extremely unlikely based on the limited
> screen capture F-Secure provides).
>
> It is also not known whether it is related to Macarena (Symantec)
> or MachoMan (Independent release), which are two recent OS X
> malware samples. It is, however, considered unlikely to be related
> to these releases.
>
> In summary, the key deviation from normal system operation that
> this malware seems to require is write access to an unnamed System
> Library (F-Secure's claim of need for admin rights to exploit is
> counter-intuitive at this point). So long as users refrain from
> running rampant in their admin accounts, this malware should pose
> little threat, even if it does get into the wild.
[ reply ]