바로 어제 우리는 Google Pixel 휴대전화의 버그에 대해 썼습니다. 지금 패치, 잠재적으로 위험한 결과를 초래합니다.

버그를 발견한 사람들은 그들이 발견한 것에 당연히 흥분(그리고 우려)했고 BWAIN 원칙을 최대로 따르기로 결정했습니다. 인상적인 이름을 가진 버그: 크로팔립스.

궁금한 점이 있다면 묵시록이라는 단어는 말 그대로 모든 종류의 계시를 의미하지만 일반적으로 성 요한의 계시, 세상의 끝을 묘사합니다.

따라서 New Oxford American Dictionary의 표현에 따르면 그 은유적 의미는 “굉장하거나 파국적인 규모의 파괴 또는 피해를 포함하는 사건”입니다.

우리는 이 버그가 종말론적인 이름을 가질 자격이 있는지 확신하지 못하지만 awesome이 "아주 좋은"을 의미할 수 있는 세상에서 그 이름이 완전히 예외는 아니지만 아마도 수용될 수 있다는 점을 기꺼이 인정합니다.

"aCropalypse"의 "Crop"

이름의 "자르기" 부분은 버그를 유발할 가능성이 가장 높은 활동에서 가져옵니다. CVE-2023-20136 Google의 화신: 공유하기 전에 민감하거나 원치 않는 부분을 제거하기 위해 사진이나 스크린샷을 자릅니다.

대략적으로 말하자면, 예를 들어 휴대전화 전체 화면의 1080×1980 스크린샷을 찍는다면 전체 이미지를 온라인에 게시하거나 전체를 친구에게 보내고 싶지 않을 것입니다.

대부분의 사람들은 적어도 스크린샷의 상단을 잘라내어 이동통신사 이름, 날짜 및 시간과 같은 세부 정보를 제거하는 것을 선호합니다.

예를 들어 목록 중간에 있는 이메일이나 소셜 미디어 게시물을 스냅하는 경우 관심 있는 부분 바로 위나 바로 아래에 나타나는 이메일이나 게시물을 가리고 싶을 것입니다.

이미지를 자른 후에도 발신자 이름, 이메일 주소, 전화번호 등 위에 블랙박스를 놓는 등 이미지의 일부(문서의 일부를 가리거나 검열하는 것을 의미하는 전문 용어)를 교정할 수도 있습니다. .

어쨌든 원본의 일부를 잘라내고 단색 블록으로 일부 세부 사항을 가리고(일반 이미지 데이터보다 훨씬 더 쉽게 압축됨) 이전 이미지 위에 새 이미지를 저장했다고 가정할 수 있습니다.

… 새 이미지는 거의 확실하게 원본보다 작거나 훨씬 작을 수 있습니다.

당신이 빠뜨린 모든 것들 때문에!

그러나 적어도 2023년 XNUMX월 Android 보안 업데이트까지는 Google Pixel 휴대전화에서 그런 일이 발생하지 않았습니다.

덮어쓰지만 잘리지 않음

새롭고 더 작은 이미지 파일은 이전 파일의 시작 부분에 기록되지만 파일 크기는 동일하게 유지되고 원본 파일의 끝에 있는 현재 중복되고 원치 않는 데이터는 원래 위치에 그대로 유지됩니다.

해당 파일을 다른 사람에게 보내고 그들이 기존의 이미지 보기 또는 편집 도구로 파일을 열면 해당 소프트웨어는 "그게 다야. 지금 중지하고 파일의 후행 데이터를 무시할 수 있습니다.”

즉, 파일 끝에 원치 않는 데이터가 남게 만든 코딩 결함은 일반적으로 명백한 오류를 유발하지 않으며, 이는 아마도 최근까지 버그가 발견되지 않은 이유를 설명할 것입니다.

그러나 받는 사람이 XNUMX진수 편집기나 교묘하게 수정된 이미지 편집기와 같은 보다 호기심 많은 소프트웨어 도구로 열면 공식 종료가 지난 후에도 몇 바이트에서 방대한 양의 원본 이미지가 여전히 남아 있을 것입니다. 탐색되고 잠재적으로 노출되기를 기다리는 이미지 마커.

대부분의 스크린샷은 PNG 파일로 저장됩니다. 휴대용 네트워크 그래픽, 일반적으로 알려진 압축 알고리즘을 사용하여 내부적으로 압축됩니다. 꺾다.

따라서 남은 데이터는 분명히 픽셀의 행과 열처럼 보이지 않으며 압축된 데이터 스트림을 손상된 것으로 간주하고 일반적으로 거부하는 기존의 압축 해제 도구로 직접 압축을 풀 수 없습니다. 압축을 풀기 위해.

그러나 꺾다 압축은 일반적으로 알고리즘을 실행하는 데 필요한 메모리 양을 줄이기 위해 반복되는 텍스트(최대 32KB, 일치 항목의 경우 최대 258바이트 길이)에 대한 입력에서 지금까지만 되돌아보면서 일련의 블록으로 입력 데이터를 압착합니다. .

이러한 제한은 형식이 1990s, 메모리 공간이 오늘날보다 훨씬 더 소중했던 때.

압축기를 정기적으로 "재동기화"하면 시작 부분에서 단 몇 바이트만 손상되더라도 압축 파일의 모든 것을 잃을 위험을 줄일 수 있습니다.

상당한 재건축 가능

즉, 압축된 PNG 형식으로 저장된 이미지 파일은 원본의 상당 부분을 덮어쓰거나 파괴하더라도 상당 부분 재구성할 수 있는 경우가 많습니다.

잘리거나 편집된 파일에서 재구성할 수 있는 이미지 조각에 대해 이야기하는 경우…

…잘려야 할 마지막 데이터에 복구 가능한 이미지 부분이 포함될 가능성이 분명히 있습니다. 이미지에서 영구적으로 제거하려는 부분이 드러납니다!

확실히 운이 좋을 수 있습니다. 이미지가 행별로 저장되어 있고(따라서 이미지 상단의 데이터가 파일 시작 부분에 가깝고 하단 데이터가 끝에 있음) 잘라낼 수 있습니다. 파일의 "공식" 부분에 있는 이전 이미지의 아래쪽 절반과 원래 이미지의 나머지 데이터에서 반복되는 아래쪽 절반으로 구성된 새 이미지로 끝날 것입니다. 잘랐지만 아니었다.

그러나 이미지의 하단을 자르면 새 파일의 이전 상단 부분이 "공식적으로" 다시 인코딩되어 시작 부분에 기록되고 잘린 이미지 하단 절반이 생깁니다. 이전에 있던 곳을 정확히 남겨두고, 새 파일의 비공식 끝에서 공격자가 추출하기를 기다리고 있습니다.

Windows 11도 영향을 받음

글쎄, 거래는 파일이 새 버전으로 교체될 때 잘리지 않는 이 문제가 Windows 11에도 적용된다는 것입니다. 자르는 도구는 Google Pixel Markup 앱과 마찬가지로 이미지가 저장된 파일을 올바르게 자르지 않고도 이미지를 자를 수 있습니다.

예를 들어 다음은 김프로 만든 PNG 파일이며 압축 없이 최소한의 헤더 집합으로 저장했습니다.

이 파일은 320비트 RGB 데이터(픽셀당 200바이트)의 8×320픽셀이므로 파일 길이는 200×3×192,000바이트(192,590)이고 여기에 몇 백 바이트의 헤더 및 기타 제한된 메타데이터가 더해져 총 XNUMX바이트입니다. .

아래 예시적인 0진수 덤프에서 데이터 길이가 20x04F192,590E 바이트이며 십진수로 XNUMX임을 알 수 있습니다.

그런 다음 캡처 도구가 허용하는 한 작게 자르고(48×48픽셀이 최소인 것 같음) 자체적으로 다시 저장했지만 "새" 파일은 압축되지 않은 320×200 파일과 같은 크기가 되었습니다!

아래의 0진수 덤프에서 상단에 분홍색으로 강조 표시된 부분은 잘린 파일에 포함되어야 하는 전체 내용이며 길이는 189xBD 바이트, 십진수로는 XNUMX입니다.

새로운 데이터는 IEND 데이터 블록은 새 파일이 끝나야 하는 곳이지만 이전의 남은 데이터로 계속되는 것을 볼 수 있습니다. IEND 거의 모든 이미지 데이터와 함께 이전 파일에서 이월된 블록:

우리가 사용했을 때 찜하기 버튼을 눌러 새 파일 이름으로 작성하면 압축된 48×48 파일이 실제로 189바이트 길이로 나왔습니다.

파일의 데이터가 이전 이미지에서 분홍색으로 강조 표시된 189바이트와 어떻게 일치하는지 확인합니다.

따라서 버그는 기존 파일 이름 위에 파일을 다시 저장해도 이전 파일이 먼저 잘리지 않고 예상 크기로 새 파일이 생성되지 않는다는 것입니다.

간단히 말해서 자른 파일은 부분적으로 덮어쓴, 실제로보다는 대체.

위에서 언급했듯이 이미지 보기 및 편집 프로그램이 첫 번째까지 읽기 때문에 지금까지 아무도 이 결함을 발견하지 못한 것으로 추측됩니다. IEND 태그(위 스크린샷의 오른쪽 하단에서 볼 수 있음)를 추가하고 이상이나 오류를 보고하지 않고 끝에 있는 모든 추가 항목을 자동으로 무시합니다.

무엇을해야 하는가?

• Windows 11 사용자라면. 원본 콘텐츠가 남지 않도록 Snipping Tool로 만든 잘린 파일을 항상 새 파일 이름으로 저장하십시오.
• 당신이 프로그래머라면. 기존 파일을 덮어써서 "새" 파일을 생성하는 모든 곳을 검토하여 다시 쓰기 위해 파일을 열 때 원본 파일이 실제로 잘리는지 확인하십시오. 또는 먼저 완전히 새로운 파일에 저장한 다음(안전하게 생성된 고유한 파일 이름 사용) 원본 파일을 명시적으로 삭제하고 새 파일의 이름을 바꾸는 방식으로만 새 파일을 만드십시오.

그건 그렇고, 우리는 Microsoft Paint를 테스트했으며 우리가 볼 수 있는 한 해당 프로그램은 사용 여부에 관계없이 이전의 남은 데이터 없이 잘린 파일을 생성합니다. 찜하기 (기존 파일 교체) 또는 다른 이름으로 저장 (새 것을 생산하기 위해).

파일 열기 모드에 대해 직접 알아보기

이 코드를 컴파일하고 실행합니다.

Windows에서는 다음을 사용할 수 있습니다. 미니멀리즘-C, 우리 자신의 선별된 빌드 자유의 작은 C 컴파일러, 개발 시스템이 설치되어 있지 않은 경우.

Visual Studio 또는 Windows용 Clang의 경우 각각 기가바이트인 것과 비교하여 전체 소스 코드를 포함하여 크기가 500KB(!) 미만입니다.

#포함하다 #포함하다 int main(void) { char* az = "ABCDEFGHIJLKMNOPQRSTUVWXYZ"; 정수 fd; // AZ가 포함된 파일 생성 // 0666진수 1은 "모든 사람을 위한 읽기/쓰기"를 의미합니다. // O_CREAT는 필요한 경우 생성을 의미합니다. fd = open("blah0666.txt",O_WRONLY+O_CREAT,26); 쓰기(fd,az,2); 닫기(fd); // AZ가 포함된 다른 파일 생성 fd = open("blah0666.txt",O_WRONLY+O_CREAT,26); 쓰기(fd,az,10); 닫기(fd); // O_TRUNC를 설정하지 않고 16바이트 쓰기 // 나머지 1바이트는 그대로 유지 fd = open("blah10.txt",O_WRONLY); write(fd,"----------",10); 닫기(fd); // O_TRUNC가 설정된 *와 함께* 2바이트를 씁니다. // 남은 오래된 데이터는 잘려야 합니다. fd = open("blah10.txt",O_WRONLY+O_TRUNC); 쓰기(fd,"==========",0); 닫기(fd); XNUMX을 반환합니다. }

쓰기를 위해 기존 파일을 여는 것(O_WRONLY) 설정 유무 O_TRUNC 깃발.

의 내용을 출력 blah1.txt 과 blah2.txt 테스트 프로그램 실행 후:

C:UsersduckCROP> petcc64 -stdinc -stdlib test.c Tiny C 컴파일러 - Copyright (C) 2001-2023 Fabrice Bellard 학습 도구로 사용하기 위해 Paul Ducklin이 제거 버전 petcc64-0.9.27 [0006] - 64비트 생성 PE 전용 -> t1.c -> c:/users/duck/tcc/petccinc/fcntl.h . . . . -> C:/Windows/system32/msvcrt.dll -> C:/Windows/system32/kernel32.dll ----------- ----- virt 파일 크기 섹션 1000 200 2a0 .text 2000 600 1cc .data 3000 800 18 .pdata ----------- ----- <- t1.exe (2560 바이트) C:UsersduckCROP> t1.exe C:UsersduckCROP>dir blah*.txt C 드라이브의 볼륨에 레이블이 없습니다. 볼륨 일련 번호는 C001-D00D입니다 C:UsersduckCROP의 디렉토리 22/03/2023 07:20 pm 26 blah1.txt 22/03/2023 07:20 pm 10 blah2.txt 2 파일 36바이트 C:UsersduckCROP> 유형 blah1.txt ----------KLMNOPQRSTUVWXYZ C:UsersduckCROP> 유형 blah2.txt ==========

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• 플라토 블록체인. Web3 메타버스 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 출처: https://nakedsecurity.sophos.com/2023/03/22/windows-11-also-vulnerable-to-acropalypse-image-data-leakage/