Scott Knight

Securely configuring your AWS account

2020-09-11T00:00:00+00:00

Recently I decided to sit down and futher lock down my personal AWS account. I haven’t used it for much other than S3 storage of macOS installers and in turn had not configured things as securely as I would have liked. The following post walks you through how to lock down an AWS account that is used by a single user. A lot of the recommendations apply just as much to an account with multiple users as well.

First just a quick note. Amazon has a lot of documentation for AWS. Everything I cover here can be found in their guides and documentation but you have to wade through a lot of different documents. My goal here is to provide a short easy to follow guide. The two following documents are foundational to what I cover and would be useful to read over.

AWS General Reference
AWS Identity and Access Management

AWS root user

When you first sign up for AWS you start with a single root user account that has complete access to all AWS services and resources. This root user account should only be used for setting up your first IAM user or the small handful of tasks that require root user access. With that said the following steps should be taken to lock down access to the root user account:

Ensure the root user has a strong password set.
Enable Multi-factor authentication (MFA) for the root user.
Delete any access keys you might have for the root user.

IAM Policies

IAM policies allow you to define permissions. In order to grant permissions to users or services you need to first create some policies. Alternatively there are a lot of standard policies that are provided in AWS already that you can use. For example there is an AdministratorAccess policy that provides full access to all AWS services and resources. You use policies by attaching them to IAM identities (users, groups or roles). We’re going to create three different policies for our setup.

IAMRequireMFA

The first policy, IAMRequireMFA, will be used to allow all IAM users the ability to set set a password and configure MFA on their IAM user account. It will ensure that MFA is required for any other action the user wants to take.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListMiscAccountInformation",
            "Effect": "Allow",
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:GetAccountSummary",
                "iam:ListAccountAliases"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Sid": "AllowAllUsersToListUserAccounts",
            "Effect": "Allow",
            "Action": [
                "iam:ListUsers"
            ],
            "Resource": [
                "arn:aws:iam::*:user/"
            ]
        },
        {
            "Sid": "AllowIndividualUserToChangeTheirPassword",
            "Effect": "Allow",
            "Action": [
                "iam:ChangePassword"
            ],
            "Resource": [
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "AllowIndividualUserToListTheirMFA",
            "Effect": "Allow",
            "Action": [
                "iam:ListVirtualMFADevices",
                "iam:ListMFADevices"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "AllowIndividualUserToManageTheirMFA",
            "Effect": "Allow",
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:ResyncMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "RequireMFAForUserToManageRemainderOfAccount",
            "Effect": "Allow",
            "Action": [
                "iam:CreateLoginProfile",
                "iam:DeleteLoginProfile",
                "iam:GetLoginProfile",
                "iam:UpdateLoginProfile"
            ],
            "Resource": [
                "arn:aws:iam::*:user/${aws:username}"
            ],
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": true
                }
            }
        },
        {
            "Sid": "RequireMFAToDeactivateTheirOwnVirtualMFADevice",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ],
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": true
                }
            }
        },
        {
            "Sid": "DoNotAllowAnythingOtherThanAboveUnlessMFA",
            "Effect": "Deny",
            "NotAction": "iam:*",
            "Resource": "*",
            "Condition": {
                "Null": {
                    "aws:MultiFactorAuthAge": "true"
                }
            }
        }
    ]
}

AssumeAdminRole

The second policy, AssumeAdminRole, will only be used by users that you want to grant admin privileges to. We haven’t discussed IAM roles yet so just make note that this policy grants permission to assume a role named AdminRole.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::*:role/AdminRole"
            ],
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": true,
                    "aws:SecureTransport": true
                },
                "NumericLessThan": {
                    "aws:MultiFactorAuthAge": "3600"
                }
            }
        }
    ]
}

AdminPolicy

The final policy, AdminPolicy, we define will be used to specify admin privleges. This policy will be specific to your needs but for now you can set up your policy exactly the same as the built in AWS AdministratorAccess policy. Please take care though, this policy grants access to everything in the AWS account.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

IAM Roles

An IAM role is an identity that you can attach IAM policies to. You can use roles to delegate access to different AWS services. An IAM user can log in and then switch to a different role to perform the actions they need. This is called “assuming a role”. The advantage of assuming a role is that when do, a set of temporary short lived credentials are transparently issued to your user and those are used to perform the action. This means if the credentials were ever somehow compromised they only are useful for an hour or two. In our case we’re going to create a single role.

AdminRole

The AdminRole will have the AdminPolicy attached to it. If you’re creating the role from the AWS console simply choose the Another AWS account option but use your own account ID when setting it up. You can check the Require MFA checkbox if you want but our policies above should also ensure that MFA is required in order to assume the role.

IAM Groups

IAM groups are another type of identity that policies can be attached to. IAM users can be added to groups and then a single policy can apply to all users of the group at once. We’re going to create two separate groups.

Users

Any new IAM user should be added to this group. The permissions you attach here are meant to apply to all users. In our case we’re going to attach the IAMRequireMFA policy to this group.

Administrators

Only certain users should be granted administrative access to your account. The AdminPolicy should be attached to this group.

IAM Users

With our policies, roles and groups set up we can now finally create a new IAM user. You can give your user whatever user name you want. For our usage go ahead and check the Programatic access and AWS Management Console access check boxes. Add the user to both the Users group and the Administrators group. Click through and finish creating the user. When prompted make sure to save your newly created access keys somewhere secure.

AWS CLI

Finally we can install and configure the AWS command line interface. The Amazon docs do a good job of covering all this so I’ll just cover how you set things up to use the AdminRole we created.

~/.aws/credentials

Add the access keys you saved after creating your IAM user into the credentials file.

[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

~/.aws/profile

In the profile we’re going to configure the IAM role we created earlier.

[profile admin]
role_arn = arn:aws:iam::123456789012:role/AdminRole
source_profile = default
mfa_serial = arn:aws:iam::123456789012:mfa/username

Make sure to change 123456789012 and username to your account ID and the user name you created earlier.

Testing it out

Finally we can test things out. Running an aws command will use our default access keys and only have access to assume the AdminRole. If we try to list IAM groups we’ll get an error.

$ aws iam list-groups

An error occurred (AccessDenied) when calling the ListGroups operation: User: arn:aws:iam::123456789012:user/username is not authorized to perform: iam:ListGroups on resource: arn:aws:iam::123456789012:group/

If we instead add the --profile admin argument to our command we’ll be asked to authorize with our configured MFA and then the command can run.

$ aws iam list-groups --profile admin
Enter MFA code for arn:aws:iam::123456789012:mfa/username:
{
    "Groups": [
        {
            "Path": "/",
            "GroupName": "Administrators",
            "GroupId": "ABPAQDWXIEOQBGZSQSWBN",
            "Arn": "arn:aws:iam::123456789012:group/Administrators",
            "CreateDate": "2020-09-09T14:38:41Z"
        },
        {
            "Path": "/",
            "GroupName": "Users",
            "GroupId": "ABPAQDWXIEOQLAFJFH43Y",
            "Arn": "arn:aws:iam::123456789012:group/Users",
            "CreateDate": "2020-09-09T14:20:32Z"
        }
    ]
}

Conclusion

It does take a bit of work to set all of this up but ultimately I think it provides a good set up for a personal account. As a review we’ve done the following.

Locked down the root user with MFA and no access keys.
Created an IAM user who only has permission to do the following:
- Set a password
- Configure MFA
- Assume the role we setup
Created a role with admin permissions.

This set up ensures that when making use of our admin permissions we assume the role and need to enter a MFA token in order for it to work. The assumed role uses transparent temporary credentials that are only good for one hour. If our IAM users access keys are compromised we’ve made sure they don’t have permission to do any harm and the attacker would need our MFA device in order to assume the admin role. I think this set up strikes a good balance between security and usability.

INIT 29

2020-05-02T00:00:00+00:00

In my previous post I covered my “Classic” Mac OS emulator set up. One of my goals of getting the emulator set up was to be able to look at and analyze viruses that affected older versions of Mac OS. I think taking a look at old viruses is interesting for two reasons. First, it provides a good overview of 68k assembly. Second, it provides an interesting perspective on the history of malicious software. The first virus I decided to look at is called INIT 29.

Overview

The Disinfectant 3.7.1 help file has a good short description of the virus:

The INIT 29 virus first appeared in late 1988. We do not know much about its origin. A second minor variant appeared in March, 1994. There are no significant difference between the two strains. The original strain is called “INIT 29 A”. The variant is called “INIT 29 B”.

INIT 29 is extremely virulent. It spreads very rapidly. Unlike Scores and nVIR, you do not have to run an application for it to become infected. Also, unlike Scores and nVIR, INIT 29 can and will infect almost any file, including applications, system files, and document files. Document files are infected, but they are not contagious. The virus can only spread via system files and application files.

Infected application

An application infected with the INIT 29 virus can be easily identified using ResEdit. See an example in the screenshot below:

The first indicator is a CODE resource of exactly 712 bytes. The second indicator can be seen in the jump table. Each executable has a CODE resource with ID 0 that contains the jump table. If it’s a small application it might only have one or two entries in the table. Normally when the compiler builds an application it would create CODE resources sequentially and similarly the jump table would also be laid out in a linear fashion. The first entry in the jump table points to the main entry point for the executable. In the case of the jump table above, the first entry in the jump table actually points to the CODE resource with ID 3. You can see based on the resource names that ID 1 has a name of “Main” and is the largest section of code. This should be the entry point to the application but the INIT 29 virus has modified the jump table entry to point to itself instead.

The image below shows a section of the virus code. You can see how it has saved the original jump table entry to the CODE resource with ID 1.

When an infected application is run it will call UseResFile passing in a refNum value of zero. This will retrieve the System resource file. It will then create a new entry in the INIT resource section with an ID of 29. This is where the name of the virus comes from. The virus copies all 712 bytes of itself into this INIT resource. This code will then be executed when the system starts up next.

Infected system file

An infected System file is also easy to identify using ResEdit. We can run an infected application in our emulator and then use ResEdit to compare the system file before and after detonation.

The left side of the image above is before running the infected application and the right side is after. You can see that after the infected application is run there is now a new INIT resource with the ID 29 and a size of exactly 712 bytes. If we disassemble the virus code we can see the following:

The INIT code is fairly short. It calls GetTrapAddress passing in $A997 to get the address of the current OpenResFile function. It checks to see if it’s already been patched and if it hasn’t it will save a pointer to the original function. Then it allocates 712 bytes on the system heap and makes a copy of itself there. Finally it calls SetTrapAddress to install itself as the new OpenResFile function.

Hijacked OpenResFile

OpenResFile is an important system API. Any time the Finder has to open a file or run an executable it will make use of OpenResFile to find out information about the file. Since it’s used so often it makes a great hook point for the virus to infect other files. The hijacked version of OpenResFile first calls into the original operating system version of the function. This will load the resource file and set it as the current resource. The virus then looks to see if the file has any CODE resources or not. If the file doesn’t have any CODE resources then the virus creates an INIT resource with ID 29 and copies it’s 712 bytes into it. This results in document files that contain the virus code but can’t infect anything else. If the opened resource does have a CODE resource then the virus attempts to find a free ID to use. It will use the lowest free ID to create a new resource entry and copy it’s 712 bytes into it. After that it opens the CODE resource with ID 0 and patches the jump table to point to the new resource that it just created. This results in the application running the virus code the next time it starts attempting to infect the System file.

Conclusion

With the INIT 29 virus attempting to infect every single resource file opened it’s easy to see why the Disinfectant help file called the virus “extremely virulent”. For the most part the virus is harmless and simply infects files. However, since it does hijack the startup of applications it is possible to notice a slow down when launching programs. It’s especially interesting to see just how much the virus accomplishes using only 712 bytes of code.

IOCs

Indicator	Type	Context
36ff546b093706c98524657e69b124b4bb8ff763b02ee5a7df3281d5ff7a8d91	SHA256	Init29.A
b40e63e0ae669ed362370e0b05e20067c1e3d285f2532927ee58a5dea275571a	SHA256	Init29.C
b0318fa75edd599ca739e774fe7a4dcacd2b5e60bcf7830ed45adbbaaacad83a	SHA256	Init29.C
2c08b750c30cbd36827f2ccc01546e4fe3aa5ef86b4fd7a9b65038540849feb8	SHA256	Init29.C

Classic Mac OS development

2020-04-19T00:00:00+00:00

Before macOS, and before OS X, there was just Mac OS. This is often referred to as “Classic” Mac OS. It includes System 1 all the way up to Mac OS 9.x. I started using a Mac with System 6 on a Macintosh Classic. Then I moved up to a Macintosh IIsi running System 7. Finally, after the PowerPC transition, I used a Power Macintosh 8500 which ran all of the later versions of “Classic” Mac OS. I was recently having a conversation with another developer who grew up using Macintosh computers and we were both reminiscing about some of our early development experiences on Mac. While System 6 was the first Mac OS version I used, I didn’t start really writing Mac apps until the Mac OS 8 era. This got me thinking that it might be interesting to spend some time re-learning “Classic” Mac OS app development.

As I mentioned previously I didn’t really start programming until Mac OS 8 and by then CodeWarrior had solidly cemented itself as the IDE of choice for Mac developers. I decided for this exploration that I wanted to stick to early Mac software as much as possible. I chose to only look for tools that were available for Mac prior to the 1990s.

Emulation

Since I no longer have any physical “Classic” Mac hardware I decided to turn to emulation. I’ll go over some of the more populator emulators and why I chose the one I did.

SheepShaver

https://sheepshaver.cebix.net/

SheepShaver emulates a Power PC Macintosh. It was originally created for BeOS back in 1998. Since then, it has become an open source project. It’s capable of running Mac OS 7.5.2 through 9.0.4. If you’re interested in running the more recent versions of “Classic” Mac OS this is probably the emulator you should choose. Mac OS 7.5.2 was released in 1995 and in turn SheepShaver doesn’t fit my criteria of sticking to software and tools available prior to the 1990s.

Basilisk II

https://basilisk.cebix.net/

Basilisk II emulates a 68k Macintosh. Originally released in 1997 by the same developer as SheepShaver. It’s capable of running up to Mac OS 8.1. This is another very popular emulator and a lot of people looking to emulate 68k Macintoshes choose this one. It is also open source, however it is no longer being maintained.

Mini vMac

https://www.gryphel.com/c/minivmac/

Mini vMac is a spinoff of the vMac project. It also emulates a 68k Macintosh. It has a focus on the early Macs with the default build emulating a Macintosh Plus. Mini vMac is capable of emulating up to Mac OS 7.5.5. It’s also open source and unlike Basilisk II is still being maintained.

So what’s the difference between Mini vMac and Basilisk II? The FAQ page for Mini vMac has a great explanation.

The biggest current difference is that Mini vMac emulates the earliest Macs, while Basilisk II emulates later 680x0 Macs. The fundamental technical difference is that Basilisk II doesn’t emulate hardware, but patches the drivers in ROM, while Mini vMac emulates the hardware (with the exception of the floppy drive).

The consequences are that some of the earliest Mac software will run in Mini vMac and not Basilisk II, while much of the later software will run in Basilisk II and not Mini vMac. For software that will run in either, the emulation in Mini vMac can be more accurate, while Basilisk II offers many more features (including color, larger screen, more memory, network access, and more host integration).

Mini vMac aims to stay simple and maintainable. So Mini vMac only has compile time preferences, where as Basilisk II has many run time preferences. And Mini vMac uses a rather simple emulation of the processor, compared to Basilisk II, which could make Mini vMac slower.

The fact that Mini vMac focuses on early Macs and ealy Mac software it fit my criteria well. It has a good Getting Started page as well as a collection of other Tutorials to help you get system software and get up and running. I went through all of the tutorials and now have a working emulated Mac Plus running System 6.0.8.

Software

With an emulator up and running I next needed to find software. Luckily, there are a few sites that host repositories of software for old Mac OS versions. The following sites have been some of the most helpful in terms of finding old software:

IDEs

I mentioned earlier that CodeWarrior was the IDE of choice when I started Mac development but since it came out in the 90s it didn’t fit my criteria for early Mac development. Additionally while C/C++ had become the language of choice for the Mac in the 90s, back in the 80s Pascal was by far more common. I also needed an IDE that supported System 6.

While looking for Pascal compilers I came across two main contenders: Borland Turbo Pascal and THINK Pascal. Both seemed like good potential candidates. They had versions that came out in the late 80s and supported System 6. THINK Pascal seemed to be fairly popular during the era.

An alternative, that I had used a handful of times before CodeWarrior, was the Macintosh Programmer’s Workshop (MPW). MPW was the development environment provided by Apple. In the 80s it was quite expensive. It had a 68k assembler, a pascal compiler, and (new for MPW 2.0) a C compiler as well. This seemed like a fun choice because of the range of languages supported but also because it was the official offerring provided by Apple. After downloading MPW 2.0 from the software links above I had a working development environment.

Books

The last thing I needed were some good programming books from the time period. I found a wonderful resource in the Vintage Apple website.

https://vintageapple.org/macprogramming/

Here’s a list of the books I’ve found most useful so far:

Inside Macintosh Volumes I - III cover everything you would ever want to know about the early Mac and how it worked. It also covers all of the OS managers and their API’s as well. Inside Macintosh Volume IV covers changes for the Macintosh Plus, which is helpful since Mini vMac emulates a Macintosh Plus. The other two books have some good information about MPW itself and how it works as well as some okay intro to Mac programming.

What’s Next?

With an emulated Mac configured and an IDE chosen I’ve started to write some little test programs in Pascal. While I’ve never written a Mac program in Pascal, I have written many Delphi applications on Windows. I’ve also started to search out some old Mac viruses from the 80s to take a look at how they worked. Overall, I find it a nice change of pace to be able to boot into System 6, do some coding, play some old games and remember a time when computers were a lot less complicated to use.

Audit tokens explained

2020-03-20T00:00:00+00:00

The recent Objective by the Sea v3.0 conference had a lot of great talks. Two that stood out to me were Abusing and Securing XPC in macOS Apps by Wojciech Reguła and Job(s) Bless Us! Privileged Operations on macOS by Julia Vashchenko. Both talks discussed different aspects of XPC services and the types of security bugs that can occur in them. There were some great best practice recommendations that both speakers shared for securing your own XPC services. One of those recommendations was to use the audit token rather than PID when checking the connecting process. Since the audit token APIs aren’t public I thought it would be interesting to take a closer look at what audit tokens actually are and where they come from.

PID vs. audit token

I think it’s worth brielfy covering the XPC best practice around PID vs. audit token before diving into the history and internals of the audit token itself. A XPC service listener has the chance to accept or deny an incoming connections. The most common way to validate the incoming connection is to make use of the Security framework provided by Apple. This framework provides a way to access the code signing information of the remote process and you can then check to make sure the calling process is validly signed by your own company. A common way to get access to the code signing information is to do something like the following:

SecCodeRef code = NULL;
NSDictionary *attributes = @{
    kSecGuestAttributePid: @(connection.processIdentifier)
};
SecCodeCopyGuestWithAttributes(0, attributes, kSecCSDefaultFlags, &code);

The issue with this is since it only uses PID to locate the process, and PIDs wrap around and can be reused, it’s possible to race the code signing verification and trick it into checking a different binary. Ian Beer and Samuel Groß both have some good descriptions of this issue:

The fix for the code above is to do the following:

SecCodeRef code = NULL;
NSDictionary *attributes = @{
    kSecGuestAttributeAudit: @(connection.auditToken)
};
SecCodeCopyGuestWithAttributes(0, attributes, kSecCSDefaultFlags, &code);

There’s one catch with this updated code. The auditToken property is not a public property of NSXPCConnection. Wojciech Reguła has a great sample XPC application that shows an easy way to access this private property. As we’ll see shortly, making use of the auditToken allows the Security framework to use the internal fields to ensure the connecting process is the one the XPC service thinks it is.

The history of audit tokens

The audit token mentioned above is actually part of the OpenBSM subsytem in macOS. OpenBSM is an open source implementation of Sun’s Basic Security Module (BSM) security audit API and file format. Back in 2003 Apple decided to submit macOS to the National Information Assurance Partnership (NIAP) for Common Criteria certification. As part of preparing for this certification Apple contracted McAfee to port the Solaris BSM implementation to macOS.

The BSM code can be seen in the XNU kernel as far back as xnu-517 which was released in October of 2003 as part of macOS 10.3.0. It wasn’t until more than a year later in November of 2004 when macOS 10.3.6 was released that end users could actually optionaly install the ported BSM code to enable auditing on their macOS systems. Shortly after the macOS 10.3.6 release Apple did officially receive Common Criteria certification. This certification validated macOS for high security uses such as by the U.S. Government.

Apple eventualy relicensed their BSM port under the BSD license to allow integration into FreeBSD and other systems. This code base is what eventually became the OpenBSM project.

Kernel implementation

Now that we know some of the history behind the audit token lets actually take a look at what it is and how the kernel implements and stores it. We start be taking a look at the definition of audit_token_t itself.

/*
 * The audit token is an opaque token which identifies
 * Mach tasks and senders of Mach messages as subjects
 * to the BSM audit system.  Only the appropriate BSM
 * library routines should be used to interpret the
 * contents of the audit token as the representation
 * of the subject identity within the token may change
 * over time.
 */
typedef struct{
    unsigned int                  val[8];
} audit_token_t;

We can already start to see why the auditToken property of NSXPCConnection is marked as private. The comment explicitly mentions that audit_token_t structure is meant to be opaque and only the appropriatee BSM library routines should be used to interpret its contents.

task structure

Continuing on in the kernel code if we search for other structures that make use of audit_token_t we find the following:

struct task {
    /* Synchronization/destruction information */
    decl_lck_mtx_data(, lock);               /* Task's lock */
    os_refcnt_t     ref_count;      /* Number of references to me */
    boolean_t       active;         /* Task has not been terminated */
    boolean_t       halting;        /* Task is being halted */    
    ...

    /* Task security and audit tokens */
    security_token_t sec_token;
    audit_token_t   audit_token;

    ...
};

A task is one of the fundamental structures of the Mach portion of the XNU kernel. It represents a collection of resources, virtual address space, and a port name space. It contains a queue of thread structures which are what are actually responsible for running code. Searching further through the code we can find the int set_security_token_task_internal(proc_t p, void *t) function which actually sets the fields of the audit token. Here’s an excerpt from that function:

my_cred = kauth_cred_proc_ref(p);
my_pcred = posix_cred_get(my_cred);

...

/*
 * The current layout of the Mach audit token explicitly
 * adds these fields.  But nobody should rely on such
 * a literal representation.  Instead, the BSM library
 * provides a function to convert an audit token into
 * a BSM subject.  Use of that mechanism will isolate
 * the user of the trailer from future representation
 * changes.
 */
audit_token.val[0] = my_cred->cr_audit.as_aia_p->ai_auid;
audit_token.val[1] = my_pcred->cr_uid;
audit_token.val[2] = my_pcred->cr_gid;
audit_token.val[3] = my_pcred->cr_ruid;
audit_token.val[4] = my_pcred->cr_rgid;
audit_token.val[5] = p->p_pid;
audit_token.val[6] = my_cred->cr_audit.as_aia_p->ai_asid;
audit_token.val[7] = p->p_idversion;

Again, we see mention in the comments that only the appropriate BSM library functions should be used to interpret an audit_token_t structure. If we look in the OpenBSM code, we can see that the function audit_token_to_au32 is the function that should be used to extract the contents out of an audit_token_t structure.

Now that we know a tasks’s audit_token field is set from set_security_token_task_internal lets continue further to see where this code is actually called from. There are three functions that call set_security_token_task_internal:

exec_handle_sugid
audit_session_join_internal
set_security_token

We’ll ignore the first two and instead focus on set_security_token for now. Searching for set_security_token we see the following call sites:

load_init_program_at_path
fork1
setuid
seteuid
setreuid
setgid
setegid
setregid
setgroups_internal
persona_proc_adopt
audit_session_setaia

The first function load_init_program_at_path is responsible for starting launchd. The call to set_security_token here ensures that even the launchd process has an audit_token set on its task structure. The fork1 function is eventually called from either the fork or vfork system calls. Since fork and vfork are responsible for creating new processes in the system it ensures all new processes also have an audit_token set on their task structure. All of the setXXX functions are responsible for changing a field that is also stored as part of the audit_token_t structure. It makes sense that if any of those fields change then the audit_token_t values should also be updated. The persona_proc_adopt is part of the persona subsystem. The persona subsystem provides a mechanism for a process or thread to assume a uid, gid and group memberships all at once. So again this is similar to the setXXX functions. Since the audit_token_t structure stores some of the audit session related identifiers we also have a call to set_security_token from audit_session_setaia which is responsible for updating credentials of a process based on new audit info.

All of these calls just go to ensure that a task always has it’s audit_token field populated and updated appropriately throughout it’s lifetime. It is actually possible to retrieve a task’s audit_token using the Mach task_info API. Here’s a short example:

audit_token_t token;
mach_msg_type_number_t size = TASK_AUDIT_TOKEN_COUNT;

kr = task_info(mach_task_self(), TASK_AUDIT_TOKEN, (task_info_t)&token, &size);
if (kr != KERN_SUCCESS) {
    printf("Error getting task audit_token\n");
    exit(1);        
}

There is actually another Mach API call to set a task’s audit_token called host_security_set_task_token. The first parameter of the function is the host security port which is not accessible from user space at all. So in practice only the kernal can change a task’s audit_token.

mach message trailers

If we continue searching through the XNU source for usage of audit_token_t we come across the following structure:

typedef struct{
    mach_msg_trailer_type_t       msgh_trailer_type;
    mach_msg_trailer_size_t       msgh_trailer_size;
    mach_port_seqno_t             msgh_seqno;
    security_token_t              msgh_sender;
    audit_token_t                 msgh_audit;
} mach_msg_audit_trailer_t;

Mach messages can optionally have message trailers appended to them. Trailers are not settable from user space and can only be set by the kernel. The contents of the trailer are assumed to be trusted since only the kernel can set them. If we further search the code for msgh_audit we can find the following call sites:

ipc_kmsg_get
ipc_kmsg_get_from_kernel
mach_msg_send
mach_msg_overwrite

These are the core mach messaging functions of the kernel and each one has a section of code similar to the following:

/*
 * reserve for the trailer the largest space (MAX_TRAILER_SIZE)
 * However, the internal size field of the trailer (msgh_trailer_size)
 * is initialized to the minimum (sizeof(mach_msg_trailer_t)), to optimize
 * the cases where no implicit data is requested.
 */
trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + send_size);
trailer->msgh_sender = current_thread()->task->sec_token;
trailer->msgh_audit = current_thread()->task->audit_token;
trailer->msgh_trailer_type = MACH_MSG_TRAILER_FORMAT_0;
trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE;

As part of the mach message routines the kernel will allocate a trailer structure of the maximum size possible. When the message is copied back to user space of the receiving process only the portion of the trailer requested will be delivered.

This is a really interesting feature because it means as part of every Mach message sent it’s possible to have the sender’s audit_token value sent along with it. Here’s a short example of how this can be done.

struct message
{
    mach_msg_header_t header;
    char data[256];
    mach_msg_audit_trailer_t trailer;
};

mach_port_t server_port;
struct message msg;
kern_return_t kr;

kr = mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &server_port);
if (kr != KERN_SUCCESS) {
    printf("Error allocating port\n");
    exit(1);
}

const mach_msg_option_t options = MACH_RCV_MSG |
    MACH_RCV_TRAILER_TYPE(MACH_RCV_TRAILER_AUDIT) |
    MACH_RCV_TRAILER_ELEMENTS(MACH_RCV_TRAILER_AUDIT);

kr = mach_msg(&msg.header,
              options,
              0,
              sizeof(msg),
              server_port,
              MACH_MSG_TIMEOUT_NONE,
              MACH_PORT_NULL);

if (kr != KERN_SUCCESS) {
    printf("Error receiving mach message 0x%x\n", kr);
    exit(1);
}

printf("pid  %d\n", msg.trailer.msgh_audit.val[5]);

csops_audittoken system call

Continuing our search through the XNU source code there’s one more place worth mentioning making use of the audit_token_t structure. Suprisingly it’s a portion of the code that doesn’t seem to have anything to do with the OpenBSM subsystem. It’s part of the code signing system calls. There’s two system calls implemented in XNU to support code signing:

int csops(pid_t pid, unsigned int ops, void * useraddr, size_t usersize);
int csops_audittoken(pid_t pid, unsigned int ops, void * useraddr, size_t usersize, audit_token_t * token);

These system calls get used by the Security framework to support checking code signing attributes of processes. Both of them will call into the csops_internal function. If we look into that code we can see how the audit_token_t gets used:

pt = proc_find(pid);
if (pt == PROC_NULL) {
    return ESRCH;
}

upid = pt->p_pid;
uidversion = pt->p_idversion;
if (uaudittoken != USER_ADDR_NULL) {
    error = copyin(uaudittoken, &token, sizeof(audit_token_t));
    if (error != 0) {
        goto out;
    }
    /* verify the audit token pid/idversion matches with proc */
    if ((token.val[5] != upid) || (token.val[7] != uidversion)) {
        error = ESRCH;
        goto out;
    }
}

When the csops_audittoken version of the system call is used the code will perform an additional check to make sure the process looked up by PID actually matches the values on the audit_token_t. The key is to make use of the p_idversion field in addition to the p_pid. This prevents the PID reuse vulnerability that was mentioned at the start of this write up.

XPC and audit tokens

Now that we know how the kernel implements and stores the audit_token_t we can take a closer look at XPC and how it makes use of the functionality. Unfortunately libxpc.dylib is not open source so we’ll have to do some reverse engineering to understand what’s going on. If you’re using the XPC C API instead of the higher level Objective-C API the way to get a connection’s audit_token_t is to use void xpc_connection_get_audit_token(xpc_connection_t, audit_token_t *);. If we disassemble xpc_connection_get_audit_token we see the following:

__int64 __fastcall xpc_connection_get_audit_token(_QWORD *connection, _QWORD *token)
{
    __int64 v2; // rax

    os_unfair_lock_lock_with_options((char *)connection + 84, 0x10000LL);
    token[3] = connection[15];
    token[2] = connection[14];
    v2 = connection[12];
    token[1] = connection[13];
    *token = v2;
    return os_unfair_lock_unlock((char *)connection + 84);
}

Since we don’t have any source for libxpc.dylib we’ll do some guess work here but the function is pretty straight forward. It simply accesses internal fields of the xpc_connection_t structure passed in and copies it to the audit_token_t pointer. I would guess that the xpc_connection_t structure actually has an audit_token_t field within it. Based on this knowledge we can continue our search looking for where this xpc_connection_t field gets set. With a short amount of digging we can find the _xpc_connection_set_creds function. Disassembled it looks like the mirror opposite of xpc_connection_get_audit_token:

__int64 __fastcall _xpc_connection_set_creds(_QWORD *a1, __int64 a2)
{
    __int64 *v2; // r14
    __int64 v3; // rax

    v2 = (__int64 *)_xpc_mach_msg_get_audit_token(a2);
    os_unfair_lock_lock_with_options((char *)a1 + 84, 0x10000LL);
    a1[15] = v2[3];
    a1[14] = v2[2];
    v3 = *v2;
    a1[13] = v2[1];
    a1[12] = v3;
    return os_unfair_lock_unlock((char *)a1 + 84);
}

unsigned __int64 __fastcall _xpc_mach_msg_get_audit_token(__int64 a1)
{
    return a1 + ((*(unsigned int *)(a1 + 4) + 3LL) & 0xFFFFFFFFFFFFFFFCLL) + 20;
}

From here we can search for all the callers of _xpc_connection_set_creds and find the following functions:

_xpc_connection_mach_event
_xpc_connection_unpack_message

The _xpc_connection_mach_event function is called from two other functions: _xpc_connection_create and _xpc_connection_set_event_handler2. In both cases the functions that use _xpc_connection_mach_event pass it into a libdispatch event handler for handling Mach messages. _xpc_connection_unpack_message itself is called from _xpc_connection_mach_event as well as two other XPC message sending functions.

Based on what we know about the kernel implementation and the disassembly and function names above it’s safe to say that XPC is retrieving the audit_token_t from the mach message trailer for each message that it receives. It will then call _xpc_connection_set_creds passing in the xpc_connection_t structure as well as the mach message to ensure that the audit_token_t field of the xpc_connection_t is up to date.

We can verify this through an XPC test application by calling xpc_connection_get_audit_token in our server process when the client first connects, then have the client call setuid (which will force the kernel to update the task’s audit_token) and then send a message to the server. The server can then call xpc_connection_get_audit_token again and see that the audit_token_t values have been updated.

Conclusion

After diving into all the details of what an audit_token_t is, and how it gets used, I think it’s important to take a step back. We started this journey by discussing an XPC service best practice of using the audit_token_t rather than the PID to verify the code signing of an incoming connection. With the knowledge of all the internals we can now more clearly say why this is more secure. The audit_token_t contains not just the p_pid of the incoming process but also the p_idversion. The p_idversion is what allows the csops_audittoken system call to make sure that the process we’re checking code signing on actually matches what we expect. It prevents the race condition of the p_pid looping back around and the server blindly trusting that it’s the same process.

Building XNU 6153.11.26 (almost)

2020-02-18T00:00:00+00:00

A couple weeks ago Apple finally released the XNU source code for macOS Catalina. It looks like they have now added more of the open source packages needed to build the entire XNU kernel, so it’s time to update my build instructions.

If you’re interested in looking through what’s new or changed in the latest XNU code, you can look at a diff of the latest source here:

https://github.com/knightsc/darwin-xnu/commit/21722f3926534b9dab63b1194b0136ddd6d1fc24

The first issue that I ran into was compilation issues with dtrace-338.0.1. It looks like Apple is now including a handful of llvm header files as part of dtrace in the include subfolder. One of those files include/llvm-Support/PointerLikeTypeTraits.h still references a file from the llvmCore folder structure. So in order to get the dtrace tools to compile I had to generate the missing DataTypes.h file and update PointerLikeTypeTraits.h to reference it.

With this dtrace header fix in place the build script will run through and generate all of the depedencies needed to try to compile the kernel. Unfortunately it looks like there are some errors compiling the kernel itself that I’m still looking into.

For now if you want to follow along at home, here’s a bash script to automate the entire process of building a DEBUG kernel. (Note: It pulls the fixed dtrace header files from gists I’ve created.):

CoreServicesUIAgent internals

2019-12-24T00:00:00+00:00

The recent release of macOS 10.15.2 had some additional updates to the Xprotect yara rules within it. After reviewing what changed in the yara rules I decided to dig a little deeper into how Xprotect gets called. Jonathan Levin’s excellent book MacOS and iOS Internals, Volume III: Security & Insecurity briefly talks about Gatekeeper and Xprotect but didn’t have the internals I was looking for. I ended up finding Patrick Wardle’s excellent presentation from the 2015 Virus Bulletin Conference. His slide deck does a great job of explinaing the communication between LaunchServices, CoreServicesUIAgent and the XprotectService. It did, however, make me question what all does CoreServicesUIAgent do? This posts digs into the internals of CoreServicesUIAgent and documents its functionality.

CoreServicesUIAgent

CoreServicesUIAgent has the responsibility of providing the occasional GUI to the end user when various other system frameworks need user input. The app bundle can be found in /System/Library/CoreServices/CoreServicesUIAgent.app and is installed as a LaunchAgent via the /System/Library/LaunchAgents/com.apple.coreservices.uiagent.plist. The LaunchAgent plist is short enough that I’ll include the whole thing here:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>com.apple.coreservices.uiagent</string>
	<key>Program</key>
	<string>/System/Library/CoreServices/CoreServicesUIAgent.app/Contents/MacOS/CoreServicesUIAgent</string>
	<key>MachServices</key>
	<dict>
		<key>com.apple.coreservices.code-evaluation</key>
		<true/>
		<key>com.apple.coreservices.quarantine-resolver</key>
		<true/>
	</dict>
	<key>EnablePressuredExit</key>
	<true/>
	<key>EnableTransactions</key>
	<true/>
	<key>POSIXSpawnType</key>
	<string>Interactive</string>
</dict>
</plist>

When a user logs into the system, an instance of CoreServicesUIAgent is started and we can see from the plist that it has two Mach services that it provides. I’ll start the exploration of the binary by looking at what it does at startup and then dive into each of the services.

Initialization

If we look at the CoreServicesUIAgent binary the application delegate class is CSUIController. Looking at this class we can see what happens when CoreServicesUIAgent starts up.

Create a com.apple.coreservices.uiagent.active-handler-queue dispatch queue
Register a handful of message handlers (quarantine, launch error, file open, check access, etc)
Register to listen for locale changes
Create a new instance of CSUICodeEvaluationController, which in turn creates the NSXPCListener object for com.apple.coreservices.code-evaluation
Call xpc_connection_create_mach_service for the com.apple.coreservices.quarantine-resolver service
Calls the CSUIController classes beginListeningForWindowChanges method to listen for NSWindow lifecycle events

It’s a bit odd that the code-evaluation service makes use of a NSXPCListener object while the qaurantine-resolver makes use of the C based XPC APIs. My guess is the quarantine-resolver code has been around for longer.

com.apple.coreservices.quarantine-resolver

Searching for callers of this service we find that the primary caller is the LaunchServices.framework. Within the LaunchServices.framework there is a __LSAgentGetConnection() function that gets called in various other functions to retrieve an XPC connection to this service. I’ll start by covering some of the general connection handling of this service.

CSUIController handleIncomingXPCConnection

This handler gets set up during CoreServicesUIAgent initialization. It’s responsible for accepting or denying incoming XPC connections. In general there are only a few basic checks. Keep in mind that CoreServicesUIAgent is a launch agent so it’s running as the currently logged in user. It starts by calling xpc_connection_get_audit_token to get security information from the calling process. It then proceeds to check the euid and asid to ensure that it’s the same logged in user trying to call the service.

There is alternatively an entitlement check for the com.apple.private.coreservicesuiagent.allowedtouseCSUIFromOutsideSession entitlement to see if a different user is allowed to call the service. As far as I could tell no application on the system has this entitlement.

CSUIController handleIncomingXPCMessage

If the connection is accepted then the next step is to read and handle the XPC message itself. Every valid XPC message sent to this service has an int64 value sent in the dictionary called cmd which lets the service know which message handler to hand off to.

At this point if an invalid cmd value is sent then the service calls xpc_dictionary_create_reply and sets an int64 value with a name of com.apple.coreservices.uiagent.status and a negative error code.

Finally this method will call scheduleHandlerForMessageType to actually create and run the appropriate handler.

CSUIController scheduleHandlerForMessageType

This method starts by calling CSUIMessageHandler classForMessageType which will loop through the registered message handlers and attempt to initialize the appropriate one for the cmd value sent in the XPC message. It then gets the audit token and checks whether the message handler allows callers that are sandboxed processes. Only some of the registered message handlers allow this. Finally, if permission checks pass, the method schedules a call to the message handlers handleMessageWithCompletionHandler method on a dispatch queue with the name com.apple.coreservices.uiagent.background-message-queue.

Message Handlers

The message handlers make up the majority of the logic for this service. All the various message handlers get registered when CoreServicesUIAgent starts up and based on the cmd various handlers get called.

CSUIMessageHandler

All message handlers inherit from the CSUIMessageHandler base class. Most of the class logic is implemented in class methods that allow the registration and lookup of appropriate message handlers. But there are also default implementations of some of the message handler instance methods as well. For example canBeUsedBySandboxedApplications has a default return value of NO and only the message handlers that need to allow sandbox access override this method.

CSUIQuarantineMessageHandler

This handler is responsible for Gatekeeper and Xprotect checking. It’s called from the LaunchService.framework _LSOpenStuffCallLocal function. As mentioned in the blog opening Patrick Wardle has a great slide deck that covers the details fairly well. Ultimately though this message handler delegates most of the checking off to the GKQuarantineResolver class. This class attempts to check and resolve items that are marked as quarantined. It makes use of the Xprotect.framework XProtectAnalysis class to call into the XprotectService.

Overall this message handler seems like a weird fit into this service. Most of the other services are really in CoreServicesUIAgent to present the occasional dialog to the end user. While this handler does show dialogs to the user if items are blocked it does also have the quarantine resolver logic. Some of this code almost seems like it should be in it’s own service and then that service calls into this if it needs to present a dialog to the user.

The XPC message values can be seen below:

XPC Values

Key	Type	Value
cmd	int64	0x1
data	data	See Data Values below.
flags	uint64	?
firstLaunchPSN	uint64	process serial number

Data Values

Key	Type	Value
LSQAllowUnsigned	NSNumber	YES or NO
LSQAppPSN	NSNumber	process serial number
LSQAppPath	NSString	Full path to the application to be evaluated
LSQAuthorization	NSData	A serialized AuthorizationRef object
LSQItemSandboxExtensions	NSDictionary	?
LSQRiskCategory	NSString	Various risk categories. For example: “LSRiskCategoryUnsafeExecutable”

LSLaunchErrorHandler

This message handler gets called from the LaunchServices.framework _LSErrorDictPost function. This function is called at various spots in the LaunchServices.framework when there’s a problem trying to launch an application. The only thing this message handler does is present an error dialog to the user letting them know there was an issue launching the application.

The XPC message values can be seen below:

XPC Values

Key	Type	Value
cmd	int64	0x2
data	data	See Data Values below.

Data Values

Key	Type	Value
Action	NSString	Not sure what this is used for. `GURL` is one possible value
ErrorCode	NSNumber	The error code from trying to launch an application
AppPath	NSString	Full path to the application that couldn’t be launched
AppMimimumSystemVersion	NSString	?
AppMaximumSystemVersion	NSString	?

CSUILSOpenHandler

This is an interesting handler because it can actually be called from sandboxed application. It’s called from the LaunchService.framework _LSRemoteOpenCall invokeWithError method. If the caller is sandboxed then the sandbox_check_by_audit_token method is called checking if the caller was granted lsopen privileges. Doing a quick search through sandbox profiles we can see the following applications that are allowed to call lsopen:

com.apple.AppSSOAgent.sb:(allow lsopen)
com.apple.CommerceKit.TransactionService.sb:(allow lsopen)
com.apple.ServicesUIAgent.sb:(allow lsopen)
com.apple.appstoreagent.sb:(allow lsopen)
com.apple.appstored.sb:(allow lsopen)
com.apple.assistantd.sb:(allow lsopen)
com.apple.commerce.sb:(allow lsopen)
com.apple.commerced.sb:(allow lsopen)
com.apple.iMessage.shared.sb:(allow lsopen)
com.apple.storeassetd.sb:(allow lsopen)
com.apple.storedownloadd.sb:(allow lsopen)
com.apple.storeuid.sb:(allow lsopen)
com.apple.studentd.sb:(allow lsopen)
com.apple.telephonyutilities.callservicesd.sb:(allow lsopen)
com.apple.touristd.sb:(allow lsopen)
fmfd.sb:(allow lsopen)
usernoted.sb:(allow lsopen)

This handler is interesting because normally from a non sandboxed application the caller can just use LaunchServices.framework directly to open another application. This handler seems to really just be here to provide this functionality to sandboxed applications. If the caller has the appropriate sandbox permissions then this message handler simply calls into the _LSOpenCallInvokeXPC function of LaunchServices.framework. It seems like for sandboxed applications CoreServuceisUIAgent provides a convienant launch agent process to put random code into.

The XPC message values can be seen below:

XPC Values

Key	Type	Value
cmd	int64	0x3
call	data	A serialized version of a `_LSRemoteOpenCall` instance.

CSUICheckAccessHandler

This is another message handler that is callable from the sandbox and seems to only exist as a way to provide functionality to sandboxed processes. All this message handler does is call the access system call. When calling access the value R_OK is passed in as the mode. It then returns the value it gets back to the caller in a flags value. It’s called from _BindingBlueprint::checkUserAccessFlags in LaunchServices.framework.

The XPC message values can be seen below:

XPC Values

Key	Type	Value
cmd	int64	0x5
path	string	The full path to the file to check

CSUIGetDisplayNameHandler

Another handler that can be called from sandboxed applications. This one seems to be just for retrieving the proper localized name of a given application. It gets called from _LaunchServices::URLPropertyProvider::prepareLocalizedNameValue in the LaunchServices.framework.

The XPC message values can be seen below:

XPC Values

Key	Type	Value
cmd	int64	0x7
path	string	The path to an installed application
com.apple.coreservices.uiagent.localizations	xpc_object_t	?

CSUIChangeDefaultHandlerHandler

At first glance this message handler seems like it might be interesting. It’s called from _LSSetSchemeHandler in LaunchServices.framework. When a message is sent over to this handler it replies right away and then runs a code block. After digging a little deeper into this it really is only displaying a prompt to the end user. This message handler will call back into the LaunchServices.framework using the LSDModifyService class which in turn asks lsd to do the real work.

The XPC message values can be seen below:

XPC Values

Key	Type	Value
cmd	int64	0x8
scheme	string	The scheme of the document handler that is being changed
bundleidentifier	string	The bundle id of the new document handler
bundleversion	string	The version number of the bundle that will be the new document handler
remove	bool	A bool indicating whether the handler is being removed or not.

CSUIRecommendSafariHandler

Another handler that can be called from the sandbox. This message handler appears to be what displays the prompt if Safari isn’t the default browser. It’s called from a block in LSApplicationCheckin in the case of a process that is a browser.

The XPC message values can be seen below:

XPC Values

Key	Type	Value
cmd	int64	0x9

com.apple.coreservices.code-evaluation

This services makes use of the NSXPC* classes. It’s only called from the LaunchServices.framework. The LaunchServices.framework has a LSCodeEvaluationClientManager class that is part of the LSCodeEvaluation class. LSCodeEvaluationClientManager calls into the remote service of CoreServucesUIAgent and makes use of the LSCodeEvaluationServerProtocol for the remote interface. In CoreServicesUIAgent the CSUICodeEvaluationController implements the LSCodeEvaluationServerProtocol. The protocol can be seen below:

@class LSCodeEvaluationInfo, NSString, NSUUID;

@protocol LSCodeEvaluationServerProtocol
- (void)showSecurityPreferencesAnchor:(NSString *)arg1;
- (void)showOriginForInfo:(LSCodeEvaluationInfo *)arg1;
- (void)ejectVolumeForInfo:(LSCodeEvaluationInfo *)arg1;
- (void)moveItemToTrashForInfo:(LSCodeEvaluationInfo *)arg1;
- (void)closeProgressForInfo:(LSCodeEvaluationInfo *)arg1;
- (void)updateProgressForInfo:(LSCodeEvaluationInfo *)arg1;
- (void)startProgressForInfo:(LSCodeEvaluationInfo *)arg1;
- (void)registerWithLaunchServicesForInfo:(LSCodeEvaluationInfo *)arg1;
- (void)updateQuarantineFlagsForInfo:(LSCodeEvaluationInfo *)arg1 setFlags:(int)arg2 clearFlags:(int)arg3 reply:(void (^)(void))arg4;
- (void)presentPromptOfType:(long long)arg1 options:(long long)arg2 info:(LSCodeEvaluationInfo *)arg3 identifier:(NSUUID *)arg4;
@end

I’m not entirely clear how and when the LaunchServices.framework makes use of this remote service but for the most part this service is really just presenting dialogs to the end user. Methods in the protocol above that seem to take an actual action end up calling back into LaunchServices.framework to do any of the real work.

Conclusion

This proved to be an interesting deep dive into the internals of a system launch agent that probably most of us take for granted. Additionally, there really seem to three types of main functionality that CoreServicesUIAgent handles:

Coordinating and running quarantine malware checks
Providing random functionality to sandboxed processes
Displaying dialogs to the logged in user

Displaying dialogs is clearly the majority of what the launch agent does. Historically I would guess this was also the only thing in CoreServicesUIAgent. Over time it seems like like the launch agent provided a convienant point to add additional functionality that should be running as the logged in user. All of the above internals comes from macOS 10.15.2. It would be interesting to go back over the last couple major versions of macOS and see how the internal mach services have changed or grown over time. Finally if you want to play around with sending some XPC messages to CoreServicesUIAgent you can find a small command line program I used for testing here.

CVE-2019-8805 - A macOS Catalina privilege escalation

2019-10-31T00:00:00+00:00

With the release of macOS Catalina in October, Apple rolled out a set of interesting new features collectively called System Extensions. System Extensions are a set of user space frameworks encouraging developers who currently maintain and ship kernel extensions to move their features to user space for increased security and stability. One of these new frameworks is the Endpoint Security framework. As a security researcher this framework is of special interest. It’s intended to provide a public and stable API for implementing security products. During the process of looking into what functionality the Endpoint Security framework provided, a privilege escalation bug was identified that would let an attacker execute any code they wanted with root privileges. The following describes both the vulnerability as well as what Apple did to fix the issue.

Endpoint Security Architecture

There are a lot of different parts to the Endpoint Security framework and in order to understand the vulnerability it will be useful to briefly cover the architecture of the Endpoint Security framework. The framework spans three different layers. There’s the user layer, the system layer, and then finally the kernel layer.

In order to use the Endpoint Security framework a developer needs to create at least two applications. One is an application that actually uses the Endpoint Security framework (libEndpointSecurity.dylib) and will run in the system layer. The other is an application running in the user layer that makes use of the System Extensions framework to actually prompt the user to approve and install the Endpoint Security extension. Apple takes care of creating and maintaining the components running in the kernel layer.

As can be seen in the diagram above, normally when loading an Endpoint Security extension the user application uses the SystemExtensions.framework and programmatically requests to install/load the specific extension. This sends a message to the sysextd daemon which is then responsible for sending a message to the endpointsecurityd daemon. The task that the endpointsecurityd daemon carries out is installing extensions and starting them up. To start them, the daemon calls into the ServiceManagement.framework calling SMJobSubmit. SMJobSubmit is what sends a message to launchd and it will launch the extension as a root daemon. Due to the way launchd works, even if a user exits the program, launchd will just restart it again.

The Vulnerability

The privilege escalation vulnerability actually exists within endpointsecurityd and the SystemExtensions.framework it depends on. All of the communication above, between daemons, takes place using a low level system IPC mechanism called XPC. The SystemExtensions.framework provides a OSSystemExtensionPointListener class used by endpointsecurityd to listen for the XPC activation requests sysextd sends. When the endpointsecurityd daemon starts up it does the following:

So the OSSystemExtensionPointListener in the SystemExtensions.framework is what’s actually responsible for listening to XPC activation requests from sysextd.

XPC is a standard IPC mechanism on macOS that any application utilize and copmmunicate with. So what’s stopping a malicious application from sending a XPC request to endpointsecurityd asking it to launch a malicious program? Normally the answer is entitlements. Apple’s built a good system in macOS and iOS where critical subsystems of the OS are protected by entitlement checks. A random binary has to have a special entitlement embedded in it and be properly signed to communicate with critical parts of the OS. In this case however the OSSystemExtensionPointListener class did not have any entitlement checks.

This means that in macOS 10.15.0 an attacker can send a specially crafted XPC message directly to the "com.apple.endpointsecurity.system-extensions" service and request launchd to start any application the attacker chooses. Compounding the issue, launchd will treat the application it’s starting as a system daemon. It will run it as root and ensure that the process is always running, even if the user tries to kill it.

Apple’s Patch

With the release of macOS 10.15.1, Apple has patched this vulnerability. If we disassemble and reconstruct the code for [OSSystemExtensionPointListener listener:shouldAcceptNewConnection:] we can see the changes that they applied:

The first thing the [OSSystemExtensionPointListener listener:shouldAcceptNewConnection:] method does now is call valueForEntitlement passing in the string "com.apple.private.security.storage.SystemExtensionManagement". If the calling program does not have this entitlement then the message “XPC denied because caller lacks entitlement” will be logged and the connection will not be accepted. If you filter the macOS logs for endpointsecurityd and attempt to send the specially crafted XPC message you can see this error in the system logs:

default    16:04:04.919496-0400    endpointsecurityd Init ipc server
default    16:04:04.923851-0400    endpointsecurityd ESD init
default    16:04:04.926649-0400    endpointsecurityd XPC denied because caller lacks entitlement

The only binary that has this special entitlement is sysextd. This means that now in macOS 10.15.1 only sysextd can ask endpointsecurityd to install and launch extensions.

Conclusion

The new System Extensions framework in macOS Catalina is a great step forward for even more security and stability in macOS. In this case the vulnerability was fairly straightforward and Apple was able to patch it quickly. As Apple creates more and more system daemons to do specialized jobs however it does create an increased attack surface. In turn this creates more ways for attackers to find their way into the secure parts of the OS. As security researchers, this means we also need to be working to understand these new security mechanisms and testing them to see if they work as expected.

System Extension internals

2019-08-24T00:00:00+00:00

One of the most exciting things announced at this years WWDC was System Extensions. From a security perspective I think this is a really important advancedment for macOS. It means less third party code running in kernel space which should mean more security and stability. From a programmers perspective I think this is even more important. It means that the code developers previously had to write in C++ can now be written in a more modern language like Swift. Apple has been attempting to wrangle in kexts for a while now and this seems to be the final nail in the coffin. They have said macOS 10.15 will be the last release to fully support kexts without compromises and that in future releases of macOS Kernel Extensions with System Extension equivalents will not load at all. I thought it might be interesting to look at the internals of how System Extensions work.

First a disclaimer: everything that follows is based on the Catalina betas so these details might change by the time of the final release. Additionally my goal with this article is to provide an extremely high level overview. There are a lot of moving parts to System Extensions and it wouldn’t be possible to cover all the internals in one post. With that out of the way let’s take a look at how all the different subsystems communicate with each other.

Conceptually there’s really two big chunks to this. A user program calling into system services to activate or deactivate an extension and then the system itself running the extensions. The extensions then are what communicate with the kernel. Let’s take a look at some of the different subsystems.

SystemExtensions.framework

This is one of the new frameworks in Catalina. It’s written in Objective-C and is pretty small. You can read through the official documentation on it here. Its sole purpose is to provide end user applications a way to install and uninstall system extensions. Installation is one area that I hope continues to evolve because for critical security extensions it doesn’t make sense that a user application needs to run once before you’re protected. Regardless there are a couple internal classes that are worth calling out.

OSSystemExtensionInfo

This class represents the full information pertaining to a system extension. This object conforms to NSSecureCoding and is used when making requests to OSSystemExtensionPointListener instances.

OSSystemExtensionPointListener

The main System Extension daemon has friend daemons that it uses to handle the different types of system extension categories. Both endpointsecuritydand nesessionmanager use this class at start up to create a XPC service that listens for system extension start and stop events.

OSSystemExtensionClient

This class is the main way for the different applications to talk to sysextd. You can see a list of apps using this class by searching for it with ripgrep

$ rg -l -a -M 80 OSSystemExtensionClient 2> /dev/null
/sbin/kextload
/usr/bin/kextutil
/usr/bin/systemextensionsctl
/usr/libexec/endpointsecurityd
/usr/libexec/kextd
/usr/libexec/nesessionmanager
/usr/sbin/kextcache
/System/Library/Frameworks/SystemExtensions.framework/Versions/A/Helpers/sysextd
/System/Library/Frameworks/SystemExtensions.framework/Versions/A/SystemExtensions
/System/Library/PreferencePanes/Security.prefPane/Contents/MacOS/Security
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/DesktopServicesHelper
/System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd

systemextensionsctl

This is a small command line utility provided by Apple to “list and control System Extensions installed”. It’s also written in Objective-C. It makes direct use of the OSSystemExtensionClient class to call into sysextd. While this isn’t pictured in the diagram above it’s worth calling out because it’s not well documented and is useful for anyone playing around with System Extensions. In the first Catalina beta it was actually non-functional but now if you run the command you can see some basic help information about it.

$ systemextensionctl
systemextensionsctl: usage:
    systemextensionsctl developer [on|off]
    systemextensionsctl list [category]
    systemextensionsctl reset  - reset all System Extensions state
    systemextensionsctl uninstall <teamId> <bundleId>; can also accept '-' for teamID

There are some other test commands not documented. They all basically allow further testing of calls into sysextd

    systemextensionsctl disable <teamID> <bundleID>; can also accept '-' or 'plat' for teamID
    systemextensionsctl enable <teamID> <bundleID>; can also accept '-' or 'plat' for teamID
    systemextensionsctl test <test_routine_name>
    systemextensionsctl testauthz <test_routine_name>
    systemextensionsctl testshouldmove <fromPath> <toPath>; n.b. paths not URLs. To test moving to trash, specify \\\"Trash\\\" as toPath.
    systemextensionsctl testwillmove <fromPath> <toPath>; n.b. paths not URLs. To test moving to trash, specify \\\"Trash\\\" as toPath.

Finally I think it’s useful to see what entitlements applications like these have to get some idea of whether or not the functionality is locked down or not.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.private.system-extensions.modify</key>
    <true/>
</dict>
</plist>

sysextd

This is a new system daemon. It’s mostly written in swift, which is exciting to see. Most of the existing system daemons are written in Objective-C. It’s great to see Apple adopting Swift more and more for internal uses other than just end user applications. This daemon is responsible for installation, approval, and uninstalling of all the system extensions. It has the following entitlements:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.private.security.storage.SystemExtensionManagement</key>
    <true/>
</dict>
</plist>

It delegates out actions to each of the relevant subsystems: kextd, nesessionmanager and endpointsecurityd. There are a couple internal classes that are worth calling out.

KextdClient

This class forwards requests off to kextd through IOKit for DriverKit loading.

StandardExtensionDelegate

This class provides common actions for forwarding requests off to any friend daemon that implements the OSSystemExtensionPointListener class.

NetworkExtensionCategoryDelegate

EndpointSecurityCategoryDelegate

These two classes leverage the StandardExtensionDelegate logic for the most part. They’re both responsible for claiming their respective extension types.

DriverKit

DriveKit extensions have a new .dext file type. There’s a lot that goes on to make user space drivers work so again I won’t go into it in great detail. The DriverKit extension binaries are a bit weird. They have no LC_MAIN command in the Mach-O binary. This means if you wanted to try to run the extension yourself in user space you couldn’t. In fact if you try to run it in LLDB you’ll get the following error: error: Bad executable (or shared library). Ultimately the binaries do get loaded and run in user space. It would be interesting to dig a little further into the loading process of .dext files. Overall, I like the architecture and find it very interesting. The user mode drivers basically set up a connection to IOKit and get forwarded events happening and can send back responses as well.

IOKit.framework

There’s a couple new internal functions in the IOKit.framework.

_KextManagerValidateExtension

_KextManagerUpdateExtension

_KextManagerStopExtension

These three functions are used by kextd to install and uninstall DriverKit extensions.

kextd

There were changes to kextd in order for it to understand what drivers have a corresponding user executable. I’m hoping that Apple will release Catalina source shortly after final release in order to be able to look into this more.

kernel

The kernel side of IOKit had changes to support sending events of to user space. It looks like in the kernel IOUserServer corresponds to the user space version of the IOUserServer class in the DriverKit.framework

Endpoint Security

This is one of the most interesting parts of System Extensions in my opinion. From what I can tell Apple took their standard pattern for kext to system daemon communication and attempted to turn it into a framework. That way third parties would only have to worry about writing the system daemon side of things and Apple could control the kernel side. Ideally this should lead to much better stability for third party security tools as they’ll be kicked out of doing nasty things inside of kernel space.

endpointsecurityd

This is another new system daemon. Written in Objective-C. It’s responsible for the installing and uninstalling of endpoint security extensions. libEndpointSecurity.dylib doesn’t communicate with endpointsecurityd in any way. There are a handful of entitlements the daemon has:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.private.endpoint-security.manager</key>
    <true/>
    <key>com.apple.private.security.storage.SystemExtensionManagement</key>
    <true/>
    <key>com.apple.private.system-extensions.extension-point</key>
    <true/>
    <key>com.apple.private.tcc.manager</key>
    <true/>
    <key>com.apple.private.xpc.protected-services</key>
    <true/>
</dict>
</plist>

libEndpointSecurity.dylib

When you write an Endpoint Security extension this is the main library that you’ll use. It makes use of the IOKit.framework to register itself as a client with the EndpointSecurity.kext. From there it can opt in or out of listening for certain events from the Kernel Extension and send responses back.

EndpointSecurity.kext

If you’ve ever looked at any third party antivirus kernel extensions this kext looks very similar. It uses the MACF and kauth kernel frameworks to listen to events happening and then sends messages out to any registerd clients. Those registered clients can then make decision on whether to allow or deny the actions happening.

Network Extensions

This is probably where I’ve spent the least amount of time looking into things. The NetworkExtension.framework was something that already existed. As part of Catalina some of the functionality that already existed on iOS is now ported over to macOS. With Network Extensions you can now create things like firewall applications that run completely in user space rather than having to use Network Kernel Extensions

nesessionmanager

The daemon listens for messages from sysextd to take care of validating, starting and stopping network extensions

NetworkExtension.framework

This framework existed but there is a new public function that should be noted.

NEProvider.startSystemExtensionMode()

This method is responsible for starting up a listening XPC server. This allows the kernel to send out relevant messages to the user space Network Extensions.

Conclusion

So as you can see there are a lot of different pieces involved in “System Extensions” and I only barely managed to scratch the surface. I’m excited to see how this evolves and the increased security it should bring.

Swift metadata

2019-07-17T00:00:00+00:00

When reverse engineering macOS binaries that are written in Objective-C, class-dump is a common tool used to extract Objective-C declarations from the runtime information stored in the Mach-O files. With Swift binaries, since there is Objective-C compatability, sometimes you can extract declarations using class-dump but not always. Swift has a rich set of type metadata itself but the documentation is not up to date. With Swift 5 bringing ABI stability I thought it would be interesting to take a look at the type of metadata availble in Swift binaries.

From the documentation we see the following overview of Swift type metadata:

The Swift runtime keeps a metadata record for every type used in a program, including every instantiation of generic types. These metadata records can be used by (TODO: reflection and) debugger tools to discover information about types.

To start off with lets start with finding out where the Swift metadata is stored in a Mach-O file. jtool -l or otool -l will work in this case.

$ jtool2 -l /Applications/Stocks.app/Contents/MacOS/Stocks
LC 00: LC_SEGMENT_64              Mem: 0x000000000-0x100000000    __PAGEZERO
LC 01: LC_SEGMENT_64              Mem: 0x100000000-0x100028000    __TEXT
    Mem: 0x100002ca0-0x100020304        __TEXT.__text    (Normal)
    Mem: 0x100020304-0x100020a90        __TEXT.__stubs    (Symbol Stubs)
    Mem: 0x100020a90-0x100021734        __TEXT.__stub_helper    (Normal)
    Mem: 0x100021740-0x100022c28        __TEXT.__const
    Mem: 0x100022c30-0x100024dc5        __TEXT.__cstring    (C-String Literals)
    Mem: 0x100024dc5-0x100026630        __TEXT.__objc_methname    (C-String Literals)
    Mem: 0x100026630-0x100026d54        __TEXT.__swift5_typeref
    Mem: 0x100026d60-0x100027061        __TEXT.__swift5_reflstr
    Mem: 0x100027064-0x1000274cc        __TEXT.__swift5_fieldmd
    Mem: 0x1000274cc-0x100027608        __TEXT.__swift5_capture
    Mem: 0x100027608-0x100027668        __TEXT.__swift5_assocty
    Mem: 0x100027668-0x1000276f8        __TEXT.__swift5_proto
    Mem: 0x1000276f8-0x10002776c        __TEXT.__swift5_types
    Mem: 0x10002776c-0x100027794        __TEXT.__swift5_builtin
    Mem: 0x100027794-0x1000277ac        __TEXT.__swift5_protos
    Mem: 0x1000277ac-0x100027bb0        __TEXT.__unwind_info
    Mem: 0x100027bb0-0x100027ff8        __TEXT.__eh_frame

We can see that in the __TEXT segment of the binary there are a handful of sections that start with the __swift5 prefix. With the documentation out of date the best way to determine what goes in these sections is to look directly in the Swift code. Here are some of the most helpful places in code I’ve found:

These are just a few of the example files I found useful while looking into Swift metadata. In general the useful code breaks down into ABI code, reflection code and LLVM IR generation code. The metadata in the LLVM IR code is nicely labelled and is the same as what gets emitted in the final compiled binary. If you have a test .swift file you can generate the IR yourself for inspection using the following command:

swiftc -emit-ir -Xfrontend -disable-llvm-optzns -O test.swift > test.ir

What follows is a high level description of all the Swift 5 sections that can show up in a Swift binary.

TEXT.swift5_protos

This section contains an array of 32-bit signed integers. Each integer is a relative offset that points to a protocol descriptor in the __TEXT.__const section.

A protocol descriptor has the following format:

type ProtocolDescriptor struct {
    Flags                      uint32
    Parent                     int32
    Name                       int32
    NumRequirementsInSignature uint32
    NumRequirements            uint32
    AssociatedTypeNames        int32
}

TEXT.swift5_proto

This section contains an array of 32-bit signed integers. Each integer is a relative offset that points to a protocol conformance descriptor in the __TEXT.__const section.

A protocol conformance descriptor has the following format:

type ProtocolConformanceDescriptor struct {
    ProtocolDescriptor    int32 
    NominalTypeDescriptor int32
    ProtocolWitnessTable  int32
    ConformanceFlags      uint32
}

TEXT.swift5_types

This section contains an array of 32-bit signed integers. Each integer is a relative offset that points to a nominal type descriptor in the __TEXT.__const section.

A nominal type descriptor can take different formats based on what type it represents. There are different structures for Enum, Struct and Class types. They have the following format:

type EnumDescriptor struct {
    Flags                               uint32
    Parent                              int32
    Name                                int32
    AccessFunction                      int32
    FieldDescriptor                     int32
    NumPayloadCasesAndPayloadSizeOffset uint32
    NumEmptyCases                       uint32
}

type StructDescriptor struct {
    Flags                   uint32
    Parent                  int32
    Name                    int32
    AccessFunction          int32
    FieldDescriptor         int32
    NumFields               uint32
    FieldOffsetVectorOffset uint32
}

type ClassDescriptor struct {
    Flags                       uint32
    Parent                      int32
    Name                        int32
    AccessFunction              int32
    FieldDescriptor             int32
    SuperclassType              int32
    MetadataNegativeSizeInWords uint32
    MetadataPositiveSizeInWords uint32
    NumImmediateMembers         uint32
    NumFields                   uint32
}

TEXT.const

This section is not Swift specific. It contains descriptors referenced from other sections. Here are some of the various structures you’ll see in this section:

Protocol conformance descriptor
Module descriptor
Protocol descriptor
Nominal type descriptors
Direct field offsets
Method descriptors

TEXT.swift5_fieldmd

This section contains an array of field descriptors. A field descriptor contains a collection of field records for a single class, struct or enum declaration. Each field descriptor can be a different length depending on how many field records the type contains.

A field descriptor has the following format:

type FieldRecord struct {
    Flags           uint32
    MangledTypeName int32
    FieldName       int32
}

type FieldDescriptor struct {
    MangledTypeName int32
    Superclass      int32
    Kind            uint16
    FieldRecordSize uint16
    NumFields       uint32
    FieldRecords    []FieldRecord
}

TEXT.swift5_assocty

This section contains an array of associated type descriptors. An associated type descriptor contains a collection of associated type records for a conformance. An associated type records describe the mapping from an associated type to the type witness of a conformance.

An associated type descriptor has the following format:

type AssociatedTypeRecord struct {
    Name                int32
    SubstitutedTypeName int32
}

type AssociatedTypeDescriptor struct {
    ConformingTypeName       int32
    ProtocolTypeName         int32
    NumAssociatedTypes       uint32
    AssociatedTypeRecordSize uint32
    AssociatedTypeRecords    []AssociatedTypeRecord
}

TEXT.swift5_builtin

This section contains an array of builtin type descriptors. A builtin type descriptor describes the basic layout information about any builtin types referenced from other sections.

A builtin type descriptor has the following format:

type BuiltinTypeDescriptor struct {
    TypeName            int32
    Size                uint32
    AlignmentAndFlags   uint32
    Stride              uint32
    NumExtraInhabitants uint32
}

TEXT.swift5_capture

Capture descriptors describe the layout of a closure context object. Unlike nominal types, the generic substitutions for a closure context come from the object, and not the metadata.

A capture descriptor has the following format:

type CaptureTypeRecord struct {
    MangledTypeName int32
}

type MetadataSourceRecord struct {
    MangledTypeName       int32
    MangledMetadataSource int32
}

type CaptureDescriptor struct {
    NumCaptureTypes       uint32
    NumMetadataSources    uint32
    NumBindings           uint32
    CaptureTypeRecords    []CaptureTypeRecord
    MetadataSourceRecords []MetadataSourceRecord
}

TEXT.swift5_typeref

This section contains a list of mangled type names that are referenced from other sections. This is essentially all the different types that are used in the application. The Swift docs and code are the best places to find out more information about mangled type names.

TEXT.swift5_reflstr

This section contains an array of C strings. The strings are field names for the properties of the metadata defined in other sections.

TEXT.swift5_replace

This section contains dynamic replacement information. This is essentially the Swift equivalent of Objective-C method swizzling. You can read more about this Swift feature here.

The dynamic replacement information has the following format:

type Replacement struct {
    ReplacedFunctionKey int32
    NewFunction         int32
    Replacement         int32
    Flags               uint32
}

type ReplacementScope struct {
    Flags uint32
    NumReplacements uint32
    
}

type AutomaticReplacements struct {
    Flags            uint32
    NumReplacements  uint32 // hard coded to 1
    Replacements     int32
}

TEXT.swift5_replac2

This section contains dynamica replacement information for opaque types. It’s not clear why this additional section was created instead of __swift5_replace but you can see the original pull request that implemented it here.

The dynamic replacement information for opaque types has the following format:

type Replacement struct {
    Original    int32
    Replacement int32
}

type AutomaticReplacementsSome struct {
    Flags uint32
    NumReplacements uint32
    Replacements    []Replacement
}

DATA.const

This section is not Swift specific. It contains things like value witness tables and full type metadata. Presumably some of the metadata is placed here so it can be modified at runtime.

Wrapping up

My hope is the information above helps make it more clear what type of extra information is stored in Swift binaries. Just like was mentioned in the official metadata documentation this information can be used for writing debug tools. It should be possible to use this information to create a class-dump like tool for Swift binaries.

Debugging Apple binaries that use PT_DENY_ATTACH

2019-06-03T00:00:00+00:00

Recently while looking into the Apple adid daemon, I noticed that I couldn’t attach to the process with lldb even if SIP was completely disabled. After digging into it a little bit I came to the conclusion that adid was calling the ptrace API passing in PT_DENY_ATTACH. There are numerous other posts out there (like this one) that talk about defeating PT_DENY_ATTACH if you’re running the application yourself. In my case adid is started as a LaunchDaemon and is already running by the time a user is logged in. I decided to take a look at how you could defeat the ptrace call even after the application is already running.

First a quick note on how I determined that adid was using the ptrace API. I started off on a virtual machine with SIP disabled. This is my usual setup when inspecting Apple platform binaries. I tried to connect to adid using lldb but it didn’t seem to work.

$ ps xa | grep adid
  374   ??  Ss     0:00.06 /System/Library/PrivateFrameworks/CoreADI.framework/adid

$ lldb -o "attach 374"
(lldb) attach 374
error: attach failed: Error 1

$ sudo lldb -o "attach 374"
Password:
(lldb) attach 374
error: attach failed: lost connection

The second attempt running lldb with sudo resulted in debugserver itself crashing with a segmentation fault. This is what made me think that ptrace might be in use. Checking the symbols on adid confirmed this.

$ jtool2 -S /System/Library/PrivateFrameworks/CoreADI.framework/adid  | grep ptrace
                 U _ptrace

From there I decided that I should be able to either catch the ptrace call at boot time by debugging XNU itself or potentially inspect and undo the ptrace call from the running process. I set up my virtual machine for kernel debugging and then decided to look into what the ptrace call itself does when called. Looking in the XNU source we can see that the following happens when calling ptrace(PT_DENY_ATTACH, 0, 0, 0);

...
#define P_LNOATTACH     0x00001000
...
if (uap->req == PT_DENY_ATTACH) {
  proc_lock(p);
  if (ISSET(p->p_lflag, P_LTRACED)) {
    proc_unlock(p);
    KERNEL_DEBUG_CONSTANT(BSDDBG_CODE(DBG_BSD_PROC, BSD_PROC_FRCEXIT) | DBG_FUNC_NONE,
              p->p_pid, W_EXITCODE(ENOTSUP, 0), 4, 0, 0);
    exit1(p, W_EXITCODE(ENOTSUP, 0), retval);

    thread_exception_return();
    /* NOTREACHED */
  }
  SET(p->p_lflag, P_LNOATTACH);
  proc_unlock(p);

  return(0);
}
...

When the ptrace API is called with the PT_DENY_ATTACH argument what happens is that the proc structures p_lflag field gets updated to have the P_LNOATTACH flag set. Some of the proc fields are exposed to user space APIs but unfortunately it doesn’t look like the p_lflag is. At this point I decided to start up lldb and connect to the kernel and inspect the task itself. (The following commands assume you’ve loaded the lldbmacros that come with the Kernel Debug Kit)

First I got some information about the adid task.

(lldb) showtask -F adid
task                 vm_map               ipc_space            #acts flags    pid       process             io_policy  wq_state  command
0xffffff8017de1188   0xffffff8018d97838   0xffffff801acca980       3 R        374   0xffffff801acecd50            BLT  2  2  0    adid

(lldb) showprocinfo 0xffffff801acecd50
Process 0xffffff801acecd50
	name adid
	pid:374    task:0xffffff8017de1188   p_stat:2      parent pid: 1
Cred: euid 265 ruid 265 svuid 265
Flags: 0x4004
	0x00000004 - process is 64 bit
	0x00004000 - process has called exec

Now that we have an address for the process itself we can inspect the p_lflag field.

(lldb) p/x ((struct proc *)0xffffff801acecd50)->p_lflag
(unsigned int) $2 = 0x00801000

You can see that the p_lflag field has the P_LNOATTACH flag set. All we need to do to effectively negate the ptrace call is to change the value of the p_lflag field.

(lldb) expr ((struct proc *)0xffffff801acecd50)->p_lflag = 0x00800000

After this lldb can happily attach to the adid process. This effectively solves the original problem I had, which was being able to debug adid after it has already started, but it got me wondering what other processes Apple has that might be doing the same type of thing. I created a short python script to check all tasks to see if they had the P_LNOATTACH flag set.

(lldb) command script import kernhelper.py

(lldb) script kernhelper.show_ptrace_deny_attach_procs()
...
...
0xffffff8025cabe20: SecurityAgent
0xffffff802a615b70: authorizationhos
0xffffff802cbd87f0: adid

(lldb)

So you can see there are a couple other processes running after first login that also have called ptrace passing in the PT_DENY_ATTACH argument. These correspond to the following binaries:

/System/Library/Frameworks/Security.framework/Versions/A/MachServices/SecurityAgent.bundle/Contents/MacOS/SecurityAgent
/System/Library/Frameworks/Security.framework/Versions/A/MachServices/authorizationhost.bundle/Contents/MacOS/authorizationhost
/System/Library/PrivateFrameworks/CoreADI.framework/adid

If we go even further and try to search for all binaries on a clean macOS 10.14.5 install that reference ptrace we see the following list:

$ cd /System/Library
$ rg -l -a -M 80 _ptrace 2> /dev/null
Kernels/kernel
QuickTime/QuickTimeComponents.component/Contents/MacOS/QuickTimeComponents
CoreServices/AppleFileServer.app/Contents/MacOS/AppleFileServer
Frameworks/DVDPlayback.framework/Versions/A/DVDPlayback
PrivateFrameworks/CoreADI.framework/Versions/A/adid
PrivateFrameworks/CoreFP.framework/Versions/A/fpsd
PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages
PrivateFrameworks/AnnotationKit.framework/Versions/A/XPCServices/com.apple.AnnotationKit.MigratorService.xpc/Contents/MacOS/com.apple.AnnotationKit.MigratorService
Frameworks/Security.framework/Versions/A/MachServices/SecurityAgent.bundle/Contents/MacOS/SecurityAgent
Frameworks/Security.framework/Versions/A/MachServices/authorizationhost.bundle/Contents/MacOS/authorizationhost

I’m not sure if all of these are really using PT_DENY_ATTACH or if some are just referencing the text _ptrace in some way but they are candidates that could be looked at in the future.

My hope is this post shows a good example of how you can get started with kernel debugging learning about the internals of XNU itself as well as showing that as long as we still have control of the kernel on macOS there’s ultimately not much Apple can do to prevent us from inspecting their binaries.