dd if=/dev/urandom of=/dev/mem은 안전합니까?

집에서 이것을 시도하지 마십시오! 시스템이 충돌할 수 있으며 운이 좋지 않으면 주변 장치가 손상되거나 컴퓨터를 부팅할 수 없게 될 수도 있습니다.

실제로 대부분의 플랫폼에서는 오류로 인해 실패하지만 이는 하드웨어 아키텍처에 따라 다릅니다. 권한이 없는 사용자로 명령을 실행하지 않는 한 이것이 무해하다는 보장은 전혀 없습니다. 권한이 없는 사용자의 경우 이 명령은 열 수 없으므로 전혀 무해합니다 /dev/mem.

루트로 명령을 실행할 때 수행 중인 작업을 알아야 합니다. 커널은때때로위험한 일을 하지 못하게 하지만 항상 그런 것은 아닙니다. /dev/mem자신이 무엇을 하고 있는지 꼭 알아야 하는 잠재적으로 위험한 일 중 하나입니다.

/dev/memLinux에서 write to가 어떻게 작동하는지 설명하겠습니다 . 일반적인 원칙은 다른 Unices에서도 동일하지만 커널 옵션과 같은 것은 완전히 다릅니다.

프로세스가 장치 파일을 읽거나 쓸 때 일어나는 일은 커널에 의해 결정됩니다. 장치 파일에 액세스하면 장치 파일을 처리하는 드라이버의 일부 코드가 실행됩니다. 예를 들어, /dev/mem호출 함수를 작성하세요.write_mem존재하다drivers/char/mem.c. 이 함수는 열린 파일을 나타내는 데이터 구조, 기록할 데이터에 대한 포인터, 기록할 바이트 수, 파일의 현재 위치 등 4개의 매개변수를 사용합니다.

호출자가 처음에 파일을 열 수 있는 권한이 있는 경우에만 이 작업을 수행할 수 있습니다. 장치 파일은 일반적으로 파일 권한을 따릅니다. 일반 권한은 의 소유 /dev/mem이므로 루트 없이 쓰기 위해 열려고 하면 "권한 거부"(EACCESS) 메시지가 표시됩니다. 그러나 귀하가 루트인 경우(또는 루트가 파일에 대한 권한을 변경한 경우) 열기 프로세스가 완료되고 쓰기를 시도할 수 있습니다.crw-r-----root:kmem

함수의 코드는 write_mem일부 온전성 검사를 수행하지만 이러한 검사만으로는 모든 나쁜 일로부터 보호하기에 충분하지 않습니다. 가장 먼저 하는 일은 현재 파일 위치를 *ppos실제 주소로 변환하는 것입니다. 실패할 경우(실제로 32비트 물리적 주소가 있는 플랫폼에 있지만 파일 오프셋이 64비트이고 파일 오프셋이 2^32보다 크기 때문에) EFBIG(파일이 너무 큼)로 인해 쓰기가 실패합니다. . 다음 확인은 기록될 물리적 주소 범위가 이 특정 프로세서 아키텍처에서 유효한지 여부입니다. 실패하면 EFAULT(잘못된 주소)가 발생합니다.

다음으로 Sparc 및 m68k에서는 첫 번째 물리적 페이지에 기록된 모든 부분을 자동으로 건너뜁니다.

우리는 이제 도달했습니다메인 루프블록에 들어갈 수 있는 데이터를 반복합니다.메모리 관리 유닛페이지. /dev/mem가상 메모리가 아닌 물리적 메모리에 액세스하지만 메모리에 데이터를 로드하고 저장하는 프로세서 명령은 가상 주소를 사용하므로 코드는 물리적 메모리가 일부 가상 주소에 매핑되도록 준비해야 합니다. Linux에서는 프로세서 아키텍처 및 커널 구성에 따라 이 매핑이 영구적이거나 동적으로 생성되어야 합니다.xlate_dev_mem_ptr(그리고 당신이 한 모든 것을 unxlate_dev_mem_ptr취소합니다 ). xlate_dev_mem_ptr그런 다음 함수는 copy_from_user시스템 호출에 전달된 버퍼에서 데이터를 읽고 write현재 물리적 메모리에 매핑된 가상 주소에 씁니다. 코드는 일반적인 메모리 저장소 지침을 발행하며, 이는 하드웨어에 따라 의미가 달라집니다.

물리적 주소에 대한 쓰기를 논의하기 전에 쓰기 전에 발생하는 확인에 대해 논의하겠습니다. 루프 내에서 page_is_allowed커널이 옵션을 구성하는 경우 함수는 특정 주소에 대한 액세스를 차단합니다.CONFIG_STRICT_DEVMEM활성화됨(기본값): 허용된 주소만devmem_is_allowed액세스가 가능합니다 /dev/mem. 다른 경우에는 EPERM(Operation Not Allowed)으로 인해 쓰기가 실패합니다. 이 옵션에 대한 설명은 다음과 같습니다.

이 옵션이 켜져 있고 IO_STRICT_DEVMEM=n인 경우 /dev/mem 파일은 PCI 공간과 BIOS 코드 및 데이터 영역에 대한 사용자 공간 액세스만 허용합니다. 이것은 Dosemu와 X 및 /dev/mem의 모든 일반 사용자에게 충분합니다.

이것은 매우 x86 중심적인 설명입니다. 실제로 더 일반적으로는 CONFIG_STRICT_DEVMEMRAM에 매핑된 물리적 메모리 주소에 대한 액세스는 차단되지만 RAM에 매핑되지 않은 주소에 대한 액세스는 허용됩니다. 허용되는 물리적 주소 범위의 세부 사항은 프로세서 아키텍처에 따라 다르지만 커널 및 사용자 모드 프로세스 데이터를 저장하는 RAM은 모두 제외됩니다. 추가 옵션CONFIG_IO_STRICT_DEVMEM(Ubuntu 18.04부터 비활성화됨) 드라이버가 선언한 물리적 주소에 대한 액세스를 차단합니다.

RAM에 매핑된 물리적 메모리 주소. 그렇다면 RAM에 매핑되지 않은 물리적 메모리 주소가 있습니까? 예. 이것이 주소에 글을 쓴다는 것이 무엇을 의미하는지 위에서 제가 약속한 논의입니다.

메모리 저장소 명령어가 반드시 RAM에 기록되는 것은 아닙니다. 프로세서는 주소를 확인하고 스토리지를 전달할 주변 장치를 결정합니다. (내가 "프로세서"라고 말할 때는 동일한 제조업체가 아닐 수도 있는 주변 장치 컨트롤러를 의미합니다.) RAM은 이러한 주변 장치 중 하나일 뿐입니다. 스케줄링이 수행되는 방식은 프로세서 아키텍처에 따라 크게 다르지만 기본 원칙은 모든 아키텍처에서 거의 동일합니다. 프로세서는 기본적으로 주소의 상위 비트를 분해하고 하드 코딩된 정보, 특정 버스를 검색하여 얻은 정보 및 소프트웨어로 구성된 정보를 기반으로 채워진 일부 테이블에서 이를 찾습니다. 많은 캐싱과 버퍼링이 관련될 수 있지만 간단히 말해서 분해 후 프로세서는 무언가를 씁니다(대상 주소와 저장되는 데이터 인코딩).버스그런 다음 이를 처리하는 것은 주변 장치에 달려 있습니다. (또는 테이블 조회 결과 해당 주소에 주변 장치가 없을 수도 있습니다. 이 경우 프로세서 입력은트랩 상태커널에서 일부 코드를 실행하고 일반적으로 다음과 같은 결과를 낳습니다.신호 버스전화 절차를 위해. )

RAM에 매핑된 주소에 대한 저장소는 이전에 해당 주소에 저장된 값을 덮어쓰는 것 외에는 아무것도 "수행"하지 않으며, 나중에 동일한 주소에 로드하면 마지막으로 저장된 값이 반환된다는 약속을 받습니다. 하지만 RAM에도 이런 식으로 동작하지 않는 주소가 있습니다.등록하다새로 고침 빈도 및 전압 등을 제어할 수 있습니다.

일반적으로 하드웨어 레지스터를 읽거나 쓰는 것은 하드웨어가 수행하도록 프로그래밍된 모든 작업을 수행합니다. 하드웨어에 대한 대부분의 액세스는 다음과 같이 작동합니다. 소프트웨어(일반적으로 커널 코드)는 일부 물리적 주소에 액세스하고 프로세서를 주변 장치에 연결하는 버스에 도달한 다음 주변 장치가 해당 작업을 수행합니다. 일부 프로세서(특히 x86)에는 메모리 로드 및 저장과 별도로 주변 장치에 대한 읽기/쓰기를 수행하는 별도의 CPU 명령이 있지만 x86에서도 많은 주변 장치는 로드/저장을 통해 액세스됩니다.

이 명령은 dd if=/dev/urandom of=/dev/mem주소 0(및 쓰기가 성공하는 한 후속 주소)에 매핑된 주변 장치에 무작위 데이터를 씁니다. 실제로 많은 아키텍처에서 물리적 주소 0에는 매핑된 주변 장치가 없거나 RAM이 없으므로 첫 번째 쓰기 시도가 실패할 것으로 예상합니다. 그러나 주소 0에 매핑된 주변 장치가 있거나 다른 주소에 쓰도록 명령을 변경하면 주변 장치에서 예측할 수 없는 일부 조건이 트리거됩니다. 주소가 지속적으로 임의의 데이터를 추가하면 흥미로운 작업을 수행할 가능성이 없지만 원칙적으로는 컴퓨터를 종료할 수 있고(실제로 이 작업을 수행하는 주소가 있을 수 있음) 일부 BIOS 설정을 덮어쓰고 부팅할 수 없게 만들고 심지어 일부 문제를 일으킬 수도 있습니다. 결함이 있는 주변 장치로 인해 손상될 수 있습니다.

alias Russian_roulette='dd if=/dev/urandom of=/dev/mem seek=$((4096*RANDOM+4096*32768*RANDOM))'

커널을 올바르게 구성하면 안전합니다(작동하지 않는다는 점에서 안전합니다).

매뉴얼 페이지에 따르면메모리(4):

/dev/mem은 컴퓨터 메인 메모리의 이미지인 문자 장치 파일입니다. 예를 들어 시스템을 검사(또는 패치)하는 데 사용할 수 있습니다.

따라서 이론상으로는 dd if=/dev/urandom of=/dev/mem설치된 물리적 메모리의 전체 주소 공간을 커버해야 하며 커널과 기타 프로그램은 메모리에서 실행되므로~해야 한다효과적으로 시스템을 충돌시킵니다. 실제로는 한계가 있습니다. 동일한 매뉴얼 페이지에서:

Linux 2.6.26부터 아키텍처에 따라 CONFIG_STRICT_DEVMEM 커널 구성 옵션은 이 파일을 통해 액세스할 수 있는 영역을 제한합니다.

dd: writing to '/dev/mem': Operation not permitted가상 머신 Ubuntu 18.04에서 이것을 시도했는데 sudo루트 권한이 있어도 오류가 반환되었습니다 crw-r-----. ~에서우분투 위키:

/dev/mem 보호

일부 응용 프로그램(Xorg)은 사용자 공간에서 실제 메모리에 직접 액세스해야 합니다. 이 액세스를 제공하기 위해 특수 파일 /dev/mem이 존재합니다. 과거에는 루트 액세스 권한이 있는 공격자가 이 파일에서 커널 메모리를 보고 변경할 수 있었습니다. 장치 이외의 메모리 액세스를 방지하기 위해 CONFIG_STRICT_DEVMEM 커널 옵션이 도입되었습니다(원래 이름은 CONFIG_NONPROMISC_DEVMEM).

따라서 기술적으로는 안전하지 않습니다(시스템이 충돌하므로). CONFIG_STRICT_DEVMEM커널 옵션이 비활성화된 경우 보안 허점이 발생하지만 지금까지 본 바에 따르면 옵션이 활성화된 경우 명령이 실행되지 않습니다. ~에 따르면사이트 간 복제, 재부팅하면 모든 문제가 해결되지만, 물론 당시 RAM의 데이터는 손실되고 디스크로 플러시되지 않습니다(전혀 없다면).

이전에 링크된 복제에 대해 제안된 방법이 있으므로 busybox devmemRAM을 조작하기로 결정한 경우 여전히 방법이 있을 수 있습니다.