3 ms·

Yes, any modern OS lets any process load into its memory space binaries from anywhere the user has permissions, even if those are binaries it generated just now

Yes, any modern OS lets any process load into its memory space binaries from anywhere the user has permissions, even if those are binaries it generated just now. It can be a security problem if the binaries are generated from untrusted sources (e.g. you download some, say, Haskell, compile it and run it fully automatically).

shortrounddev2 2y ago
Windows has a private heap system where you can disable code execution from the pages allocated to `HeapCreate`, if you don't* set that flag: https://learn.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heapcreate https://learn.microsoft.com/en-us/windows/win32/api/heapapi/... > HEAP_CREATE_ENABLE_EXECUTE > 0x00040000 > All memory blocks that are allocated from this heap allow code execution, if the hardware enforces data execution prevention. Use this flag heap in applications that run code from the heap. If HEAP_CREATE_ENABLE_EXECUTE is not specified and an application attempts to run code from a protected page, the application receives an exception with the status code STATUS_ACCESS_VIOLATION. I think POSIX has equivalent memory protection calls, but no equivalent to HeapCreate
- fluoridation 2y ago
  But you can still call VirtualAlloc(), VirtualProtect(), and LoadLibrary(), so this isn't really a security mechanism, but more of a safety mechanism. I don't think Windows provides a mechanism to disable creating any further executable pages, although I've seen Chrome do it by hooking those functions (and I know it because I've had to bypass it :)).
  - pjmlp 2y ago
    App Sandboxing and VBS enclaves go onto that direction.
  - shortrounddev2 2y ago
    I wouldn't expect windows to prevent creating further executable pages; there are legitimate use cases for creating dynamically allocated executable memory. It just means that whatever foreign data you load into those pages can't execute, which is a security mechanism (for example, game save data can be loaded into these heaps so that you can load all game state but without the save file potentially running foreign code)
    - fluoridation 2y ago
      There are legitimate uses, but the point would be that the process could ask the system to lock it down with whatever executable code is already present. This could be used to prevent already running code from tampering with the process' behavior by loading new code, or to thwart code injection. >It just means that whatever foreign data you load into those pages can't execute, which is a security mechanism (for example, game save data can be loaded into these heaps so that you can load all game state but without the save file potentially running foreign code) But malloc() and all the other standard memory allocation functions already return pointers into non-executable pages, anyway. Perhaps those functions call into this one internally, but using this over whatever your language offers by default offers no additional protection.
      - shortrounddev2 2y ago
        The benefit of heapalloc and heapcreate is that it makes serialization of data simpler because you can define the bounds of the heap so you can easily save pointer offsets. There are other flags available as well. It's a win32 feature so you would only use it if windows is your target platform (and then write other bindings for other platforms)
        fluoridation 2y ago
        I still don't get it. Why can't you do the same with a regular buffer?
- adzm 2y ago
  All of this calls VirtualAlloc behind the scenes, and you can do that yourself as well for manual page allocation. Each page can have options set with VirtualProtect to allow or disallow execution of code within the pages as well.
IshKebab 2y ago
iOS won't let you do that. Or at least Apple won't let you do that on iOS.
- fluoridation 2y ago
  What's actually happening is that the SDK doesn't expose the system calls necessary to do it, but I can guarantee that if you can get a native binary to run on the device, you can have it do whatever you want. If that wasn't the case, the few apps that do support JITting wouldn't work.

shortrounddev2 2y ago

Windows has a private heap system where you can disable code execution from the pages allocated to `HeapCreate`, if you don't* set that flag: https://learn.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heapcreate https://learn.microsoft.com/en-us/windows/win32/api/heapapi/... > HEAP_CREATE_ENABLE_EXECUTE > 0x00040000 > All memory blocks that are allocated from this heap allow code execution, if the hardware enforces data execution prevention. Use this flag heap in applications that run code from the heap. If HEAP_CREATE_ENABLE_EXECUTE is not specified and an application attempts to run code from a protected page, the application receives an exception with the status code STATUS_ACCESS_VIOLATION. I think POSIX has equivalent memory protection calls, but no equivalent to HeapCreate

fluoridation 2y ago
But you can still call VirtualAlloc(), VirtualProtect(), and LoadLibrary(), so this isn't really a security mechanism, but more of a safety mechanism. I don't think Windows provides a mechanism to disable creating any further executable pages, although I've seen Chrome do it by hooking those functions (and I know it because I've had to bypass it :)).
- pjmlp 2y ago
  App Sandboxing and VBS enclaves go onto that direction.
- shortrounddev2 2y ago
  I wouldn't expect windows to prevent creating further executable pages; there are legitimate use cases for creating dynamically allocated executable memory. It just means that whatever foreign data you load into those pages can't execute, which is a security mechanism (for example, game save data can be loaded into these heaps so that you can load all game state but without the save file potentially running foreign code)
  - fluoridation 2y ago
    There are legitimate uses, but the point would be that the process could ask the system to lock it down with whatever executable code is already present. This could be used to prevent already running code from tampering with the process' behavior by loading new code, or to thwart code injection. >It just means that whatever foreign data you load into those pages can't execute, which is a security mechanism (for example, game save data can be loaded into these heaps so that you can load all game state but without the save file potentially running foreign code) But malloc() and all the other standard memory allocation functions already return pointers into non-executable pages, anyway. Perhaps those functions call into this one internally, but using this over whatever your language offers by default offers no additional protection.
    - shortrounddev2 2y ago
      The benefit of heapalloc and heapcreate is that it makes serialization of data simpler because you can define the bounds of the heap so you can easily save pointer offsets. There are other flags available as well. It's a win32 feature so you would only use it if windows is your target platform (and then write other bindings for other platforms)
      - fluoridation 2y ago
        I still don't get it. Why can't you do the same with a regular buffer?
adzm 2y ago
All of this calls VirtualAlloc behind the scenes, and you can do that yourself as well for manual page allocation. Each page can have options set with VirtualProtect to allow or disallow execution of code within the pages as well.

IshKebab 2y ago

iOS won't let you do that. Or at least Apple won't let you do that on iOS.

fluoridation 2y ago
What's actually happening is that the SDK doesn't expose the system calls necessary to do it, but I can guarantee that if you can get a native binary to run on the device, you can have it do whatever you want. If that wasn't the case, the few apps that do support JITting wouldn't work.