• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Passing pointers as UIDs | kernel<->userspace communication
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Passing pointers as UIDs | kernel<->userspace communication

  • Subject: Re: Passing pointers as UIDs | kernel<->userspace communication
  • From: Jean Suisse <email@hidden>
  • Date: Tue, 18 Sep 2012 23:22:06 +0200
Thank you for your answer.

I considered the security aspects. 
- Only the kernel can write to the structure. 
- The validity of the structure is checked using the "magic" variable (a member of the structure set to a predefined value, as shown in TCP Log NKE example). 
- The data in the structure never gets executed. 
So, unless the malicious app can write in kernel space, I should be covered on that aspect.

But, you are right, a malicious app could cause kernel panics. 
However, it would require a fair bit of reverse engineering, since connection to the kext, thought open to any userspace app, requires the demanding app to authenticate itself first.
The challenge response mechanism I use is not more difficult to crack than any other serial-key based authentication. But my app isn't that attractive, and isn't installed on that many computers to be worth the effort.
I will make investigating this point a high priority.

Do you see anything else ?


On 18 sept. 2012, at 22:01, email@hidden wrote:

This is inherently a security vulnerability if any non-root user gets access to the interface or even if the pointers get logged anywhere (because of KASLR), and is probably a bad idea even if not, since a misbehaved application can now easily cause a kernel panic.

I suggest using an array (with small identifiers) or hash table instead to more quickly locate the appropriate structure, or otherwise optimize the lookup.

Sent from my iPhone

On Sep 18, 2012, at 3:25 PM, Jean Suisse <email@hidden> wrote:

Hello,

I have a kernel extension that does some filtering and collects statistics in several identical data structures. These data structures are stored in a TAILQ list and are updated appropriately.
Meanwhile, a userspace application can request access to the data structures to inspect them and send feedback to the kernel.
This feedback can be : a request for more information, the order to discard the data, to stop recording statistics for a particular structure, etc.

Currently, I am using the following pattern:

1. Notify the userspace app that a data structure has been updated (by sending a custom notification containing the UID of the data structure)
2. If interested, the userspace app ask the content of the data structure by sending a request along with the data structure UID
3. The kext runs through the TAILQ list and searches for any data structure with a matching UID and sends it back
4. The app may want do perform additional request (modification, deletion, getting more info…) on the data structure (request + UID)
5. The kext searches again for any data structure with a matching UID and performs the task.
6. etc…

In parallel to this, the kext may want to perform other operations on its own (such as  delete the oldest unrequested datastructures if their number grows too large, various updates, etc).
And as all the lookup operations are happening frequently and in a locked context, they are processor-cycle consuming.

I was wondering: 

Instead of using true UIDs, is it wise to just send the data structure's address (structure data*) to the userspace app, and then using it back when the app makes its requests ? 
This would save all the searches in the TAILQ lists. The lists would only be used to occasionally pop the first data structure, modify the last, or remove random elements.

Additional informations :
- The UID's only purpose is to identify a single data structure among all *currently* alive data structures.
- A data structure for which the address has been communicated to the userspace application can only be deleted at the app's request. So I don't fear dangling pointers.
- Size of the pointer has been taken into account.

What do you think ?

Best regards,
Jean

-----------
Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Passing pointers as UIDs | kernel<->userspace communication
      • From: comex <email@hidden>
References: 
 >Passing pointers as UIDs | kernel<->userspace communication (From: Jean Suisse <email@hidden>)
 >Re: Passing pointers as UIDs | kernel<->userspace communication (From: email@hidden)

  • Prev by Date: Re: Passing pointers as UIDs | kernel<->userspace communication
  • Next by Date: Re: Passing pointers as UIDs | kernel<->userspace communication
  • Previous by thread: Re: Passing pointers as UIDs | kernel<->userspace communication
  • Next by thread: Re: Passing pointers as UIDs | kernel<->userspace communication
  • Index(es):
    • Date
    • Thread