윈도우 보호 공유 메모리

공유 메모리 블록을 생성 한 프로세스를 제외한 모든 프로세스에 대해 쓰기 금지 된 공유 메모리 블록을 Windows 플랫폼에서 생성 할 수있는 가능성을 찾고 있습니다.윈도우 보호 공유 메모리

공정 (1)는 공유 메모리 블록을 생성하는 버퍼를 변경할 수 있어야한다 :

상세히 I는 다음의 필요가있다. 프로세스 (2)는 생성 된 공유 메모리 블록을 열고 읽을 수 있어야하지만 내용을 수정할 수있는 권한이 없어야합니다. 이것은 보안/안전상의 이유로 중요합니다. 다음 판독 프로세스 쓰기 권한있다 MapViewOfFile()와 함께 현재

I 해결책하여 CreateFileMapping을 (사용하여 공유 메모리 블록을 생성 있음) (1) 및 (2)와 같은

HANDLE handle = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, highSize, lowSize, L"uniquename"); 
void* sharedMemory = MapViewOfFile(handle, FILE_MAP_ALL_ACCESS, 0, 0, 0); 
// now we can modify sharedMemory...

이 두

첫 번째 프로세스가 공유 메모리 블록을 생성하고 두 번째 프로세스가 단순히 공유 메모리를 열 때 코드 줄이 두 프로세스에 모두 적용될 수 있습니다. 그러나 분명히 두 번째 프로세스는 메모리 블록을 만드는 동안 제공된 액세스 값 (PAGE_READWRITE 및 FILE_MAP_ALL_ACCESS)으로 인해 쓰기 권한을 갖습니다.

액세스 값 PAGE_READONLY 및 FILE_MAP_READ를 사용하여 프로세스 (1)에서 공유 메모리 블록을 작성해야하지만 분명히 프로세스 (1)에서 메모리 블록을 초기화/설정/수정할 수 없습니다 쓸모없는 메모리 버퍼.

내 지식으로는 사용자 또는 그룹에 의존하지 않으므로 보안 속성의 정의로는 문제를 해결할 수 없습니다.

프로세스 (1)에서 공유 메모리 블록을 생성하기 전에 알려진 메모리 내용에 의존하는 공유 메모리 블록을 만드는 영혼도 만족 스럽습니다 (프로세스 1에서 수정되지 않음) 나중에).

어떤 힌트 나 의견을 보내 주셔서 감사합니다.

출처

2014-01-17 user3208346

FILE_MAP_READ을 사용하려면 프로세스 2를 신뢰합니까? 실수로 덮어 쓰는 것을 방지 할 수 있습니다. 와일드 포인터가 공유 메모리를 손상시킵니다.

악의적 인 덮어 쓰기를 방지하려면 OS 제공 보안 주체를 사용하고 적은 자격 증명으로 다른 세션에서 프로세스 # 2를 실행해야합니다. 프로세스 # 2가 프로세스 # 1과 동일한 보안 자격 증명으로 실행되는 경우 # 1이 수행 할 수있는 모든 작업 프로세스 (예 : 프로세스 # 1에 코드를 주입)를 수행 할 수 있습니다.

(Windows에서 사용자는 보안 주체이며 프로세스가 아닙니다. 사용자가 Vista의 사용자 액세스 제어와 같은 유일한 제한 사항이 아니며 나중에 Administrators 그룹 구성원이 있거나없는 관리 사용자에 해당하는 토큰을 만듭니다)

프로세스 # 1이 쓰기 액세스를 계속할 필요가 없다고 했으므로 매핑을 생성하고 쓰기 위해 매핑 한 다음 SetSecurityInfo을 사용하여 ACL을 조정하면 이후의 액세스가 쓸 수 없게됩니다.

다른 방법으로 디스크 파일을 매핑하고 첫 번째 프로세스에서 FILE_SHARE_READ (단, FILE_SHARE_WRITE 제외) 액세스로 열 수 있습니다.

하지만 둘 다 프로세스 # 1이 프로세스 # 1을 강제 변경하여 해당 프로세스를 변경할 수 없습니다. 별도의 토큰 만 사용하면 강제 변환을 방지 할 수 있습니다.

출처

2014-01-17 22:10:33

위의 SetSecurityInfo() 기반 솔루션은 문제를 완전히 해결하지 못합니다.이 호출과 섹션/매핑 생성 간의 경쟁 조건이 있습니다. – Bukes

@Bukes : 'SetSecurityInfo()'솔루션으로 문제가 해결되지 않습니다 * all *, 프로세스 # 2는'WriteProcessMemory (PROCESS1_HANDLE, ...)'을 사용하여 공유 섹션에 접근 할 수있다. 이러한 방법은 사고를 예방할뿐입니다. 필수 보안의 경우 OS 지원 사용자 (사용자 및 그룹 구성원)를 사용해야합니다. –

@Ben 디스크 파일을 사용할 수있는 가능성에 대해서도 생각했지만 디스크에 대한 액세스를 피하는 해결책을 찾고 싶습니다. – user3208346

각 경우마다 다른 인수를 제공 할 수없는 이유를 설명하지 않으므로 파일을 열 때까지 어떤 프로세스가 작성자인지 알 수 없다고 가정합니다. 이 경우에, 당신은 시도 할 수 있습니다 :

HANDLE h = OpenFileMapping(FILE_MAP_READ, /*args*/); 
if (h) { 
    v = MapViewOfFile(h, FILE_MAP_READ, 0, 0, 0); 
} else { 
    h = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, highSize, lowSize, L"uniquename"); 
    if (!h) 
     FirePhotonTorpedoes(); 
    v = MapViewOfFile(handle, FILE_MAP_ALL_ACCESS, 0, 0, 0); 
}

출처

2014-01-17 22:17:57 kfsone

제가 프로세스 # 1인지 프로세스 # 2인지를 아는 것처럼 다른 인수를 제공 할 수 있습니다. 그러나 다른 나쁜 사람이 프로세스 # 3을 사용하여 구현 된 내용을 해킹 할 수 없도록하고 싶습니다. 단지 생성 된 공유 메모리 블록을 PAGE_READWRITE로 열고 공유 메모리 블록의 내용을 수정하는 것입니다. – user3208346

@ user3208346 : 컴퓨터 소유자로서, 내 자신의 기억에 쓸 수있는 능력을 저에게 부인할 수있는 프로세스가 없는지 확인하고 싶습니다. 나는 그것을 위해 돈을 지불했다. 이 솔루션은 사용자 자격 증명에 달려 있습니다. 자신과 같은 권한으로 프로세스 # 3을 실행하지 마십시오. –

@Ben 답장을 보내 주셔서 감사합니다. 당신은 절대적으로 맞습니다.하지만 제 생각에는 Windows API를 기본적으로 사용하는 고유 한 솔루션 (제 문제는 매우 커먼 이슈라고 생각합니다)은 좋았을 것입니다.) - 내 애플리케이션을 사용하는 사람들이 내 코드를 악용 할 수있는 가능성을 찾으십시오. (이 사람들은 동일한 권한으로 내 애플리케이션과 애플리케이션을 실행합니다.) – user3208346

CreateFileMapping 기능을 사용하면 파일 매핑 개체에 대한 ACL을 설정할 수 있습니다. 읽기 전용 액세스 만 허용하는 ACL을 작성하면 다른 프로세스가 읽기/쓰기 액세스로 파일 맵핑 오브젝트를 열 수 없어야합니다.

일반적으로 개체를 만들 때 할당 한 사용 권한은 생성 중에 얻은 핸들에 적용되지 않습니다. 그러나, 특히 CreateFileMapping으로 테스트하지 않았습니다.

약한 보호 기능 만 제공합니다. 악성 프로세스는 파일 매핑 개체에 대한 사용 권한을 변경하거나 개체를 만든 프로세스에 코드를 삽입 할 수 있습니다.

출처

2014-01-20 01:30:26

답변

관련 문제