Xlera8

Chrome 제로데이: "이 익스플로잇은 야생에 있습니다." 지금 버전을 확인하세요.

구글의 최신 크롬 업데이트가 나왔고 이번에는 회사에서 말을 다듬지 않았다 포함된 두 가지 보안 패치 중 하나에 대해:

Google은 CVE-2023-3079 야생에 존재합니다.

이전에 Google에서 자주 보았듯이 회사가 익스플로잇에 대한 "보고를 알고 있다"고 말하는 XNUMX단계 분리 표현은 없습니다.

이번에는 "우리 스스로 모든 것을 알고 있습니다." 버그 보고서가 Google 자체의 Threat Research Group에서 직접 온 것을 감안할 때 "우리는 사기꾼이 우리가 말하는 대로 이것을 악용하고 있음을 알고 있습니다."로 훨씬 더 직설적으로 번역됩니다.

평소와 같이 이는 Google이 이전에 알려지지 않은 보안 허점에 의해 Chrome이 소유된 활성 공격(Google 자체 또는 일부 외부 조직에 대한 것인지는 알 수 없음)을 조사하고 있음을 의미합니다.

버그는 다음과 같이 간단하게 설명됩니다. V8에 Confusion을 입력합니다. (당연히 Google은 이 단계에서 그 이상을 말하지 않습니다.)

이전에 설명했듯이, 유형 혼동 한 가지 방식으로 구문 분석, 유효성 검사, 처리 및 작업을 수행해야 하는 데이터 청크를 프로그램에 제공할 때 버그가 발생합니다.

...하지만 나중에 프로그램을 속여 승인되지 않고 검증되지 않았으며 잠재적으로 위험한 다른 방식으로 데이터를 해석하도록 합니다.

유형 혼동 위험 설명

C로 프로그램을 작성한다고 상상해 보십시오.

C에서는 일반적으로 변수를 개별적으로 선언하므로 저장할 수 있는 메모리를 예약할 뿐만 아니라 이러한 변수가 사용되는 방법을 프로그램에 알립니다.

예 :

 long long int JulianDayNumber; 서명된 문자* CustomerName;

첫 번째 변수 선언은 천문일 수를 나타내는 일반 이전 정수 값을 저장하기 위해 64비트를 예약합니다. (궁금하신 분들을 위해 오늘 오후는 JDN 23157입니다. 줄리안 데이는 자정이 아닌 정오에 시작합니다. 왜냐하면 천문학자들은 종종 밤에 일하기 때문입니다.

두 번째는 고객 이름의 텍스트 문자열을 찾을 수 있는 메모리 주소를 저장하기 위해 64비트를 예약합니다.

상상할 수 있듯이 이 두 값을 섞지 않는 것이 좋습니다. 왜냐하면 23157과 같이 일의 숫자로 사용하기에 적합하고 안전한 숫자는 메모리 주소로 사용하기에 거의 안전하지 않을 것이기 때문입니다.

실행 중인 Windows 프로그램의 이 메모리 덤프에서 볼 수 있듯이 사용을 위해 할당된 가장 낮은 메모리 주소는 0x00370000, 이는 십진수로 3,604,480이며, 어떤 합리적인 날짜보다 훨씬 큽니다.

Windows에서 사용하는 실제 메모리 주소는 사기꾼이 메모리 레이아웃을 추측하기 어렵게 하기 위해 시간이 지남에 따라 무작위로 변경되므로 동일한 프로그램을 실행하는 경우 값을 얻을 수 있지만 그럼에도 불구하고 비슷합니다.

그리고 (위 이미지의 맨 아래에 있지만) 이 프로그램이 실행될 때 런타임 사용자 데이터 섹션의 메모리 주소 0x011300000x01134FFF, 22년 44631월 16일에서 44687년 XNUMX월 XNUMX일 사이의 예상 밖의 날짜 범위를 나타냅니다.

실제로 이 두 변수를 혼합하려고 하면 컴파일러에서 예를 들어 다음과 같이 경고해야 합니다.

 JulianDayNumber = 고객 이름; CustomerName = JulianDayNumber; 경고: 할당은 캐스트 없이 포인터에서 정수를 만듭니다. 경고: 할당은 캐스트 없이 정수에서 포인터를 만듭니다.

이제 C로 프로그래밍한 적이 있다면 편의를 위해 union 다음과 같은 키워드:

 합집합 { long long int JulianDayNumer; 서명된 문자* CustomerName; } 데이터;

이제 메모리에서 정확히 동일한 변수를 두 가지 방법으로 참조할 수 있습니다.

당신이 쓰면 data.JulianDayNumber, 저장된 데이터를 정수로 마술처럼 해석하지만 data.CustomerName 동일한 저장된 데이터에 액세스하더라도 메모리 주소를 참조하고 있음을 컴파일러에 알립니다.

여러분이 하고 있는 일은 여러분이 가지고 있는 데이터를 때때로 날짜로, 다른 때에는 메모리 주소로 취급할 것이라는 점을 컴파일러에 인정하는 것입니다. 어떤 해석이 어떤 순간에 적용되는지 기억할 책임이 있습니다. 코드에서.

다음으로 알려진 두 번째 변수를 사용하기로 결정할 수 있습니다. tag (일반적으로 정수) union 예를 들어 다음과 같이 현재 작업 중인 데이터의 종류를 추적합니다.

 구조체 { int 태그; 합집합 { long long int JulianDayNumer; 서명된 문자* CustomerName; } 데이터; } 값;

언제 결정할 수 있습니다. value.tag0, 데이터가 아직 사용을 위해 초기화되지 않았습니다. 1 날짜를 저장하고 있다는 뜻입니다. 2 메모리 주소임을 의미하고 그 밖의 모든 것은 오류를 나타냅니다.

글쎄, 당신은 다른 사람이 그것을 엉망으로 만들지 않는 것이 좋습니다 value.tag 그렇지 않으면 프로그램이 극적으로 오작동하게 될 수 있습니다.

더 걱정스러운 예는 다음과 같습니다.

 구조체 { int 태그; // 1 = 해시, 2 = 함수 포인터 union { unsigned char hash[16]; // 임의의 해시 저장 struct { void* openfunc; // 또는 신중하게 검증된 두 개의 void* closefunc; // 나중에 실행할 코드 포인터 } 유효성 검사; } } 값;

이제 우리는 동일한 메모리 블록을 오버로드하여 때때로 16바이트 해시를 저장하는 데 사용할 수 있고 때로는 프로그램이 나중에 호출할 함수에 대한 두 개의 8바이트 포인터를 저장하는 데 사용할 수 있습니다.

분명히, 언제 value.tag == 1, 해시는 의사 난수이므로 모든 바이트 모음이 동일할 가능성이 있기 때문에 소프트웨어가 합집합에 할당된 메모리에 16바이트 문자열을 저장하게 되어 기쁩니다.

하지만 때 value.tag == 2, 우리 코드는 사용자가 나중에 실행하기 위해 검증되지 않고 신뢰할 수 없고 알 수 없는 함수 주소를 제공하지 않도록 매우 주의해야 합니다.

이제 태그가 1로 설정되어 있는 동안 이 코드에 값을 제출할 수 있다고 상상해보십시오.

...하지만 나중에 프로그램이 실제로 저장된 값을 사용하기 직전에 코드를 속여 태그를 2로 전환할 수 있었습니다.

그런 다음 코드는 확인되지 않은 함수 주소를 "알려지고 이미 확인된 안전"(그렇지 않은 경우에도)으로 받아들이고 프로그램 실행을 미리 몰래 선택한 메모리의 불량 위치로 전달합니다.

인위적이고 단순화된 예를 사용하더라도 유형 혼동 버그에서 발생하는 일입니다.

한 가지 방법으로 처리하는 경우 안전하게 사용할 수 있는 메모리가 안전하지 않은 다른 방법으로 처리하도록 프로그램에 악의적으로 전달됩니다.

무엇을해야 하는가?

Chrome 또는 Chromium이 최신 버전인지 확인하세요.

당신은 크롬을 원한다 114.0.5735.106 Mac 및 Linux에서 이상 114.0.5735.110 또는 나중에 Windows에서.

Chromium을 기반으로 하는 Microsoft Edge도 이 버그의 영향을 받습니다.

Microsoft는 지금까지 [2023-06-06T16:25:00Z] 주목

Microsoft는 야생에 존재하는 최근 악용 사례를 알고 있습니다. 우리는 보안 패치를 출시하기 위해 적극적으로 노력하고 있습니다.

Edge는 현재 버전 114.0.1823.37이므로 번호가 매겨진 모든 항목 그보다 늦게 Microsoft의 CVE-2023-3079 패치를 포함해야 합니다.

버전을 확인하고 아직 받지 못한 업데이트가 있는 경우 강제로 업데이트하려면 다음 단계를 따르세요.

  • Google 크롬 점 XNUMX개 메뉴 (⋮) > 도움말 > 크롬에 대해.
  • Microsoft Edge. 설정 및 기타 (…) > 도움말 및 피드백 > 마이크로소프트 엣지 정보.

천만에요.


우리와 함께 채팅

안녕하세요! 어떻게 도와 드릴까요?