Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Industry Watch » The Technological

Fucking Insecure

There are several lessons to be learned here.


Get It

Try It

Fucking insecure: when it comes to chops in OS X and Unix that's exactly what Kamil and his friends at F-Secure are. And you know you don't have to wait long for the Cooperites to pick up the ball and run with it.

And they're at it again, stumbling over their own feet.

This time it starts with a blog post by 'Kamil' at F-Secure.

[Recognise the font in the screen dump? It's Microsoft's 'Terminal' used in Notepad - 'Kamil' is inspecting the exploit code from a Windows machine. What are security experts doing running Windows machines? Ed.]

http://www.f-secure.com/weblog/archives/archive-112006.html#00001030

We recently received a proof of concept sample of an adware program. Normally that wouldn't be worth blogging about, but in this case it's for Mac OS X. In theory, this program could be silently installed to your User account and hooked to each application you use... and it doesn't require Administrator rights to do so. We won't disclose the exact technique used here, it's a feature not a bug, but let's just say that installing a System Library shouldn't be allowed without prompting the user. Especially as it only requires Copy permissions. An Admin could install this globally to all users.

The result: This particular sample successfully launched the Mac's Web browser when we used any of a number of applications.

This is easier to do than with Windows. After all, it's a Mac.


What a crock. And it's amazing how much traction this bullshit story's already acquired. When the CNET Cooperites found the blog post they probably called Rob Enderle who called Bill Gates who got the cheque in the mail before noon. And vnunet.com write:

Security researchers have found proof of concept code...

According to security firm F-Secure, the application does not target a security flaw or bug in the operating system's code. Instead, the adware installs itself through a feature in OS X that allows system libraries to be installed without notifying the user...

While installers require user permission to run in Mac OS X, system library files can be copied onto a machine without ever prompting the user for permission, according to David Frazer, F-Secure's director of technology services...

'It can be seamlessly installed', Frazer told vnunet.com. 'When you install the library it doesn't require administrator rights.'


What a bunch of incompetent pompous boobs. First of all, F-Secure didn't 'discover' anything - it was sent to them. Secondly, you can't copy 'system library files' to a machine without privilege escalation. Period. Thirdly, it's obvious - especially when reading the 'gem' 'Kamil' posted - that the team at F-Secure are hideously incompetent when it comes to OS X and Unix in general.

Which is not surprising as they're a Microsoft insecurity cottage industry and don't have any money to make off the OS X platform.

[But knock on wood: the dream of the F-Secure team is to make OS X just as insecure as Windows so they can have more time to play with it. And justify purchase of MBPs for everyone. So they can learn Unix. Ed.]

But let's look instead at the skimpy code snippet F-Secure are baiting the media with.

tmp/macrocosm, O_RDWR);

Let's stop right there for a moment. For it's easy to see what's going on. Things start off with the system call open(). This creates the file '/tmp/macrocosm'. BFD.

% man 2 open

OPEN(2)                       System Calls Manual                      OPEN(2)

NAME
     open - open or create a file for reading or writing

SYNOPSIS
     #include <fcntl.h>

     int
     open(const char *path, int flags, mode_t mode);

DESCRIPTION
     The file name specified by path is opened for reading and/or writing as
     specified by the argument flags and the file descriptor returned to the
     calling process.  The flags argument may indicate the file is to be cre-
     ated if it does not exist (by specifying the O_CREAT flag), in which case
     the file is created with mode mode as described in chmod(2) and modified
     by the process' umask value (see umask(2)).

     The flags specified are formed by or'ing the following values

           O_RDONLY        open for reading only
           O_WRONLY        open for writing only
           O_RDWR          open for reading and writing
           O_NONBLOCK      do not block on open or for data to become available
           O_APPEND        append on each write
           O_CREAT         create file if it does not exist
           O_TRUNC         truncate size to 0
           O_EXCL          error if create and file exists
           O_SHLOCK        atomically obtain a shared lock
           O_EXLOCK        atomically obtain an exclusive lock

Now the file '/tmp/macrocosm' is marked so it can be 'eXecuted'.

tmp/macrocosm; chmod 777 /tmp/macrocosm");

Another sign of gross incompetence: for instead of changing the mode programmatically the boob uses the system call - sort of like carrying coals to Newcastle but stopping off in Kathmandu and Kuala Lumpur in the afternoon for bangers and mash and a pint.

% man 2 chmod

CHMOD(2)                      System Calls Manual                     CHMOD(2)

NAME
     chmod, fchmod - change mode of file

SYNOPSIS
     #include <sys/types.h>
     #include <sys/stat.h>

     int
     chmod(const char *path, mode_t mode);

The next line is a puzzler. Is this silly code advertising its presence? Surely there's not that much to be proud of with this kindergarten hack?

printf("start Macrocosm - The biggest <fill

And it's always curious to see how these 'pseudo experts' such as F-Secure have this IRRESISTIBLE URGE to RENAME things all the time. This hack is called 'Macrocosm' - obviously - and yet Kamil and those Keystone Kops at Fucking Insecure are now calling it 'iAdware'. Isn't that cute?

int pid;
char *urlz[8];


What this gem is going to do with a process ID is anyone's guess - probably the author's too! As for the character pointer declaration: here we have another sign a true boob is at work. He's going to have exactly eight character strings because he's (unnecessarily) already told us so.

And what be the nature of those character strings, pray tell?

urlz[0] = "open -a Safari http://www.
urlz[1] = "open -a Safari http://www.
urlz[2] = "open -a Safari http://www.
urlz[3] = "open -a Safari http://www.
urlz[4] = "open -a Safari http://www.
urlz[5] = "open -a Safari http://www.
urlz[6] = "open -a Safari http://www.
urlz[7] = "open -a Safari http://www.


More gross incompetence: for specifying '-a Safari' means this only works if the user has Safari installed; it's also totally unnecessary. And what is the 'adware' going to do with these character strings? Care to venture a guess?

How about writing them to that open file '/tmp/macrocosm' and then running the file through a system call?

% man system

SYSTEM(3)               System Library Functions Manual              SYSTEM(3)

NAME
     system - pass a command to the shell

LIBRARY
     Standard C Library (libc, -lc)

SYNOPSIS
     #include 

     int
     system(const char *string);

% man open

OPEN(1)                 System General Commands Manual                 OPEN(1)

NAME
     open - open files and directories

SYNOPSIS
     open [-a application] file ...

     open [-e] file ...

Talk about hideous incompetence. The ACP Web Services, if you haven't already guessed, access URLs programmatically as most software does. They don't use the NeXTSTEP open().

Neither do menu commands for software titles. Things like 'visit our website'. It's programmatic. And it may not be rocket science but it's miles above this sorry heap of losers.

Does this prove the 'sensation' F-Secure are trying to hype is not really an exploit? No it can't - because F-Secure - where the 'F' absolutely cannot stand for 'full disclosure' - are deliberately not releasing the actual code.

As if. They'd be laughed out of the market otherwise.

Update: Kevin Finisterre

So it was Kevin Finisterre behind the exploit. And you can download it here. And it's fairly straightforward.

But it has squat to do with 'system libraries'. It's an input managers exploit - the same kind of code used in Oompa Loompa. The fix for which you can find here.

Once cleaned up the code looks something like this.

@implementation InqTanaHandler
-(id)init {
    if (self = [super init]) {
        int fd = open("/tmp/macrocosm", O_RDWR);

        srand(time(0)); system("touch /tmp/macrocosm; chmod 777 /tmp/macrocosm");

        if (fd == -1) { // File didn't exist before we touched it.
            char *url[] = {
                "www.digitalmunition.com/",
                "www.symantec.com/nav/nav_mac/",
                "www.sophos.com/products/es/endpoint/sav-mac.html",
                "www.intego.com/virusbarrier/",
                "www.clamxav.com/",
                "docs.info.apple.com/article.html?artnum=61798",
                "www.securityfocus.com/"
            };
            int pid;

            // Pain in the ass to a mac user?
            printf("start Macrocosm - The biggest  in existence!\n");

            if ((pid = fork()) < 0) {
                perror("Fork failed."); exit(errno);
            }
            if (!pid)
                for (;;) {
                    char s[1024];

                    sprintf(s, "sleep %d; open -a Safari http://%s",
                            rand() % 300, url[rand() % (sizeof(url) / sizeof(url[0]))]);
                    system(s);
                }
        } else
            printf("Macrocosm already started.\n");
    }

    return self;
}
@end

As suspected, it works out of a file in /tmp. It wants first to see if the file exists. It sets a random seed and then 'touches' the file (creating it if it doesn't exist) and then sets the mode to 'executable'.

After that the process forks itself and in the child process starts an infinite loop with random sleep and then a random selection of URL to open.

That's it. But to work it has to go into your input managers directory.

Of course there's a way to harden the user specific input managers directory just as there was a way to harden the one under root.

Back to Fucking Insecure

But let's go back to F-Secure now. We now know this is a variant of Oompa Loompa's use of /Library/InputManagers. Let's see again what 'Kamil' at Fucking Insecurity wrote.

We won't disclose the exact technique used here, it's a feature not a bug, but let's just say that installing a System Library shouldn't be allowed without prompting the user.

Then, forcing both of his feet further down his throat so not even laser surgery can extricate them, he says the following.

An Admin could install this globally to all users.

But an admin: #1) is a trusted user; and #2) wouldn't bother installing it globally - all the admin would need to do is place it in /Library/InputManagers where it would automatically apply to everyone.

Lessons?

There are several lessons to be learned here.

  • CNET and vnunet.com don't have the chops to crosscheck their stories. They just publish whatever blather comes their way.
  • F-Secure bear the ultimate responsibility because through their staggering pompousness and ineptitude they totally misrepresented the issue.
  • F-Secure were playing 'stir the pot'. It's one thing for Kevin Finisterre to publish his POC; it's quite another for a security company to pick it up and run it - especially in the reprehensible way they did.
  • When it comes to Unix in general and OS X in particular, the boobs at Fucking Insecure don't know jack shit. And Mister Bill still has time to cancel his cheque.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.