po6ix/poc-for-cve-2023-41993Exploit de prova de conceito para CVE-2023-41993, uma confusão de tipo JIT do WebKit no Safari. Fornece primitivas addrof/fakeobj via manipulação de heap e confusão GetterSetter, permitindo leitura/escrita arbitrária no processo WebContent.
PoC exploit para CVE-2023-41993. Está escrito apenas até addrof/fakeobj. A confiabilidade não é muito boa. Se você quiser melhorá-lo, tente pulverizar os IDs de estrutura.
https://po6ix.github.io/POC-for-CVE-2023-41993/pwn.html
Decidi hospedar com GitHub Pages devido a múltiplos pedidos.
Desejem-me sorte para que o GitHub não me bloqueie...
É porque o valor do fator definido na função pwn não está correto para o seu dispositivo.
Para esse caso, eu o fiz usar um valor aleatório entre 87 e 1088.
Então você pode encontrar o valor do fator correto apenas atualizando algumas vezes.
Provavelmente funcionará em até 100 tentativas.
Também seria bom se você pudesse me enviar as informações exibidas no caso de sucesso.
Isso fornece uma primitiva de leitura/escrita para o processo webcontent do Safari.
Mas para realmente torná-lo útil, você precisará encadear com outros componentes.
Você pode querer um artigo detalhado sobre isso, mas infelizmente não tenho tempo para escrever.
Então, escrevo algumas anotações aqui para que você possa entender como isso funciona.
Se você olhar o commit, é sobre a mudança no HeapLocation.
Um novo fator foi adicionado para saber se os nós são iguais ou não.
Isso nos diz que nós como GetByOffset, MultiGetByOffset podem ser confundidos.
Mas na verdade é apenas sobre o offset.
Digamos que existam dois nós GetByOffset com offsets diferentes.
Um deles será submetido a CSE e o restante será usado em seu lugar.
Então é basicamente uma confusão de offset, mas não fornece acesso a um offset arbitrário,
pois para que esse tipo de nó passe por CSE, eles precisam ser içados pelo LICMPhase.
Para os tipos de nó que realizam operações de escrita, não é permitido serem içados nesta fase.
Portanto, a mesma confusão não ocorre com nós PutByOffset, MultiPutByOffset.
Além disso, quando GetByOffset é içado, a função safeToExecute é chamada para verificar se o nó é legítimo para execução e permite acesso apenas ao offset menor que a capacidade de armazenamento (inline/ool).
Então a ideia para explorar isso foi GetterSetter.
Se você chamar Object.__defineGetter__ para definir uma propriedade, um objeto GetterSetter é criado, mas armazenado no armazenamento de propriedades e não é acessível normalmente.
Mas você pode com essa manipulação de offset que possui.
Então você chama a função Object para desencadear uma confusão de tipos.
JSObject* JSCell::toObjectSlow(JSGlobalObject* globalObject) const
{
Integrity::auditStructureID(structureID());
ASSERT(!isObject());
if (isString())
return static_cast<const JSString*>(this)->toObject(globalObject);
if (isHeapBigInt())
return static_cast<const JSBigInt*>(this)->toObject(globalObject);
ASSERT(isSymbol());
return static_cast<const Symbol*>(this)->toObject(globalObject);
}
Isso criará um SymbolObject que tem o GetterSetter como valor interno. E isso está incorreto, pois esse valor interno de SymbolObject deveria ser uma instância de Symbol, não GetterSetter.
let getterSetter = jitme(1);
let symbolObject = Object(getterSetter);
symbolObject.description; // call the getter
String Symbol::description() const
{
auto& uid = m_privateName.uid();
return uid.isNullSymbol() ? String() : uid;
}
Então, quando você chama o getter description, ele retorna uma instância de String. Isso é uma confusão de tipos entre Symbol.m_privateName e GetterSetter.m_getter. Cada vez que você chama esse getter, ele incrementa o campo de contador de referência de m_privateName.m_uid, que está no offset 0x0. Isso é muito útil, porque esse offset é onde está o ID de estrutura da função getter. Ao chamar essa função algumas vezes, você pode alterar o ID de estrutura de uma instância JSFunction. Preparei outro tipo que possui muitas propriedades. Então, se você sincronizar o ID de estrutura para que seja igual ao dele, você pode fazer uma escrita fora dos limites no armazenamento de propriedades. Isso fornece diretamente a primitiva addrof/fakeobj.