Jump to content











Photo
- - - - -

Understanding security implications of using ImDisk

security cache

  • Please log in to reply
3 replies to this topic

#1 mbrownnyc

mbrownnyc
  • Members
  • 2 posts
  •  
    United States

Posted 24 January 2013 - 04:15 PM

Olof,

 

Thank you so much for such a great, easy to use RAM disk.  I have been recommending usage for years, but recently a question came up.

 

 

I am interested in learning a bit more about the security implications of using ImDisk.

 

Specifically, we are currently utilizing some files that are encrypted at rest that we are mapping into shared memory space for accessibility by multiple processes.

 

If we were to opt to write these files into a RAM disk created with ImDisk, what is the data flow?

 

Is there any sort of caching used?  If so, can you describe it a bit?

 

I noticed that when the kernel driver service and/or the helper service are stopped, I am still able to read/write/mount/dismount a drive.  I also used process monitor and process explorer to try to understand the i/o activity a bit better, but I did not see where the reads/writes are taking place.

 

If you can cite specific functions in source code that handle the read/write operations, it would be great!

 

 

Thanks for your time,

 

Matt


Edited by mbrownnyc, 24 January 2013 - 04:20 PM.


#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 25 January 2013 - 04:54 PM

Olof,

 

Thank you so much for such a great, easy to use RAM disk.  I have been recommending usage for years, but recently a question came up.

 

I am interested in learning a bit more about the security implications of using ImDisk.

 

Thanks for your kind words, I will try to answer your questions!

 

Specifically, we are currently utilizing some files that are encrypted at rest that we are mapping into shared memory space for accessibility by multiple processes.

 

If we were to opt to write these files into a RAM disk created with ImDisk, what is the data flow?

 

Is there any sort of caching used?  If so, can you describe it a bit?

 

If you create an ImDisk virtual disk which is backed by virtual memory storage, all disk data is in a memory block allocated from virtual memory in the System process (process id 4). Virtual memory can physically be located in physical RAM (needs to be when used) or on disk in a system pagefile, such as C:\pagefile.sys. If you store security sensitive data on your virtual disk, this could be a scenario to take into account, because the disk data can be swapped out to physical disk at any time. To avoid this and make sure that the virtual disk data is stored in physical RAM at all times, you can use the awealloc driver. There are a few examples in this forum, for example in the FAQ.

 

ImDisk itself does not use any cache, except that data from last read or write request is held in a separate non-paged pool memory block, for faster I/O response. However, filesystem drivers, such as FAT or NTFS drivers, could use various kinds of caching internally, but that is out of scope for what ImDisk or other disk drivers are responsible for.

 

I noticed that when the kernel driver service and/or the helper service are stopped, I am still able to read/write/mount/dismount a drive.

 

If you stop the driver it will automatically be started when you request to create a new virtual disk.

 

The helper service is not used when you just use ImDisk for memory disks, like in your case. The helper service is only used for "proxy mode", when I/O requests are redirected to some other application, possibly across network.

 

I also used process monitor and process explorer to try to understand the i/o activity a bit better, but I did not see where the reads/writes are taking place.

 

It is difficult to follow I/O in that way. What you see in process monitor are file I/O records where applications requests read or write to individual files. Then, requests are handled by the filesystem driver and possibly carried out directly inside the filesystem cache. If disk I/O is required to carry out the request, you can use Disk Monitor or similar to follow when filesystem drivers request I/O to specific sectors on the disk drive. The driver for the disk drive is in this case ImDisk, which will just copy I/O buffers to or from the virtual memory where the virtual disk is stored.

 

The filesystem tasks are generally taking place in a thread in the calling application. The calls to the disk driver are generally not taking place in the context of the calling application though, but rather in some cache or lazy-write thread created by the filesystem driver. Such threads generally, but do not need to, run in the System process.

 

When the disk driver get an I/O request it queues this work to a worker thread. There is one worker thread for each virtual disk in ImDisk. Worker threads run in the System process. This makes it possible to carry out requests at a lower IRQ level but still in kernel mode, so that it can call things that are not safe to call at non-pageable IRQ levels.

 

When about IOCTL requests sent directly to the disk driver, using for example DeviceIoControl or similar API functions, the relevant handling functions in the driver usually run directly in the context of the caller. There is no other process or thread called in that case. A few IOCTL calls need to do a few things that needs to be done in the worker thread though. Such requests are queued in a way similar to read or write requests.

 

If you can cite specific functions in source code that handle the read/write operations, it would be great!

 

In sys\imdisk.c you have functions like ImDiskReadWrite and ImDiskDeviceControl which handles requests from applications and filesystem drivers. These functions carry out a few things directly within them, while most tasks are queued to the worker thread. The worker thread is a function called ImDiskDeviceThread.

 

I hope this answered some of your questions!

:cheers:


  • mbrownnyc likes this

#3 v77

v77

    Silver Member

  • Team Reboot
  • 602 posts
  •  
    France

Posted 25 January 2013 - 07:49 PM

About the pagefile, I can add Microsoft has introduced a new feature with Windows Vista, that can encrypt the pagefile. It seems to be difficult to find informations about that, but I can tell the pagefile is also wiped at the shutdown, so it can take a lot of time to turn off your computer... If you want to give it a try, you can use this command in a command prompt with admin right:

fsutil behavior set encryptpagingfile 1

But the best solution is probably to have enough RAM to disable pagefile, if you don't have an old and bad coded application who check it.

 

Be also careful about the new hybrid sleep of Windows 8: it is an hibernation of the system processes, so your ramdisk content will also be saved on the hard drive. In this case, you can simply disable hibernation with the following command:

powercfg -h off

 



#4 mbrownnyc

mbrownnyc
  • Members
  • 2 posts
  •  
    United States

Posted 25 January 2013 - 09:57 PM

Olof,

 

Thank you so much for the thorough response.  It sounds great, and thanks for the advice, pointing out the VMM in Windows and it's paging to disk functionality.  All of the remainder sounds great, and I will turn this info over to our developers to see how we can best utilize the driver (etc).

 

Thanks for the info, v77.  By policy, we have full disk encryption in place and suspend-to-RAM (sleep) is disable, so our page files are encrypted at-rest and not a concern (deleting the page file at shutdown is slow!).

 

 

Thanks for your replies!

 

Matt







Also tagged with one or more of these keywords: security, cache

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users