Minha equipe descobriu recentemente , a biblioteca gráfica amplamente popular – (com de alta severidade de NVD). Essas vulnerabilidades causam negação de serviço e execução remota de código. As versões mais recentes do X11 contêm correções para essas vulnerabilidades. duas vulnerabilidades de segurança no X.Org libX11 CVE-2023-43786 e CVE-2023-43787 CVSS 7.8 A equipe monitora constantemente projetos de código aberto para encontrar novas vulnerabilidades e pacotes maliciosos e os compartilha com a comunidade em geral para ajudar a melhorar sua postura geral de segurança. Esta série de blog em duas partes fornece detalhes sobre o funcionamento interno do formato de arquivo Xpm vulnerável e se aprofunda na exploração dessas vulnerabilidades. O que é libX11? Xorg X11, muitas vezes referido como X Window System, é um protocolo de servidor gráfico que permite a criação e gerenciamento de interfaces gráficas de usuário em sistemas operacionais do tipo Unix. Ele fornece uma estrutura para executar aplicativos gráficos, gerenciar o Windows e manipular a entrada do usuário em um ambiente de rede. de código aberto O pacote libx11 oferece as bibliotecas compartilhadas essenciais que os aplicativos clientes exigem para renderizar e apresentar dados em seu desktop. O que é libXpm? libXpm fornece funções para ler, escrever e exibir imagens no formato (XPM). X Pixmap O XPM visa principalmente gerar mapas de pixels de ícones com suporte para pixels transparentes. Ele é baseado na sintaxe XBM e pode ser um arquivo de texto simples no formato XPM2 ou usar uma sintaxe de linguagem de programação C, tornando-o adequado para inclusão em um arquivo de programa C. Formato de imagem XPM – versões Antecessor – XBM Antes do XPM (X PixMap) existir em 1989, existia o formato XBM (X BitMap). Um formato de imagem binária de texto simples, usado para armazenar bitmaps de ícones e cursores que foram usados na GUI do X. Os arquivos XBM são estruturados como arquivos de origem C. Esta é a sua principal distinção em relação à maioria dos formatos de imagem atuais. Dessa forma, eles podem ser incorporados diretamente nos aplicativos. No entanto, devido a isso e ao fato de nenhuma compactação poder ser empregada (mapeamento de 1 caractere para 1 byte), eles também são muito maiores do que seus dados brutos de pixel. Os dados X BitMap (XBM) compreendem uma sequência de matrizes estáticas de caracteres não assinados que armazenam as informações brutas de pixels monocromáticos. Por exemplo, o código C a seguir é o arquivo XBM para na imagem: hello #define hello_width 35 #define hello_height 25 static char hello_bits[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x88, 0x00, 0x00, 0x10, 0x00, 0x88, 0x00, 0x00, 0x10, 0x00, 0x88, 0x00, 0x00, 0xD0, 0xE1, 0x88, 0x78, 0x00, 0x30, 0x13, 0x89, 0xC4, 0x00, 0x10, 0x12, 0x89, 0x84, 0x00, 0x10, 0xF2, 0x89, 0x84, 0x00, 0x10, 0x12, 0x88, 0x84, 0x00, 0x10, 0x12, 0x88, 0x44, 0x00, 0x10, 0xE2, 0x89, 0x38, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; Em vez dos cabeçalhos usuais de formato de arquivo de imagem, os arquivos XBM possuem instruções . O primeiro par de valores define as dimensões em pixels do bitmap, indicando sua altura e largura. #define Os dados de imagem X BitMap (XBM) são estruturados como uma sequência contínua de valores de pixel, que são armazenados em uma matriz estática. Dado que cada pixel é simbolizado por um único bit (com 0 indicando branco e 1 representando preto), cada byte na matriz abrange os dados de oito pixels individuais. Notavelmente, o bit menos significativo do primeiro byte serve como âncora para o pixel superior esquerdo do bitmap. XPM1 Conheça a versão XPM Lançado pela primeira vez em 1989, compartilha muitas semelhanças com o formato XBM descrito acima. Enquanto o XBM era monocromático, o XPM1 introduziu cores nas imagens. Ele usa macros e variáveis adicionais para cores e substitui bytes por caracteres para dados de pixel. Por exemplo, aqui está a mesma imagem e branco no formato XPM1: hello /* XPM */ static char *_hello[] = { /* columns rows colors chars-per-pixel */ "35 25 2 1 ", " c white", "bc black", /* pixels */ " ", " ", " ", " ", " ", " ", " ", " bbb ", " bbb ", " bbb ", " b bbb bbb bb bbbb ", " bb bb bbbbb bb ", " bbbbbbbb ", " bb bbbbb bbbb ", " bbbbbbb ", " bbbbbbb ", " bb bbbb bb bbb ", " ", " ", " ", " ", " ", " ", " ", " " }; aqui denota o número de cores na imagem e denota o número de caracteres por pixel. XFACE_ncolors XFACE_chars_per_pixel Cada será substituído pela cor branca “#ffffff” e cada será substituído pela cor preta “#000000”. a b XPM2 Um ano depois, em 1990, a segunda versão do formato foi criada para melhorar as coisas. Simplificou as coisas e removeu todo o código C do formato de imagem. A estrutura simplificada: ! XPM2 <Header> <Colors> <Pixels> A linha do cabeçalho indica as dimensões da imagem semelhantes às instruções #define do XPM1. A seção de cores define os valores dos caracteres. Um novo conceito de tipo foi introduzido: – é para pixel colorido c – é para monocromático m – gelo para escala de cinza g – é para simbólico s O recurso simbólico é usado para atribuir cores por contexto e criar nomes de variáveis para facilitar a leitura. Exemplo de imagem XPM2, com o mesmo mostrado nos exemplos anteriores: hello ! XPM2 35 25 2 1 ac #000000 bc #ffffff aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaabaaaaaaaaaaaaaabaaabaaaaaaaaaaa aaaabaaaaaaaaaaaaaabaaabaaaaaaaaaaa aaaabaaaaaaaaaaaaaabaaabaaaaaaaaaaa aaaababbbaaaabbbaaabaaabaaabbbbaaaa aaaabbaabbaabaaabaabaaabaabaaabbaaa aaaabaaaabaabaaabaabaaabaabaaaabaaa aaaabaaaabaabbbbbaabaaabaabaaaabaaa aaaabaaaabaabaaaaaabaaabaabaaaabaaa aaaabaaaabaabaaaaaabaaabaabaaabaaaa aaaabaaaabaaabbbbaabaaabaaabbbaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Além dos códigos de cores hexadecimais, as cores também podem ser especificadas usando qualquer um dos nomes de cores X11 (por exemplo, ), com indicando transparência. red None XPM3 Esta é a versão atual do formato XPM. A versão lançada em 1991 trouxe de volta o código C, mas em vez de usar um estilo de código C puro, os valores internos são essencialmente os mesmos do formato XPM2. Exemplo: /* XPM */ static char *_hello[] = { /* columns rows colors chars-per-pixel */ "35 25 2 1 ", " c white", "bc black", /* pixels */ " ", " ", " ", " ", " ", " ", " ", " bbb ", " bbb ", " bbb ", " b bbb bbb bb bbbb ", " bb bb bbbbb bb ", " bbbbbbbb ", " bb bbbbb bbbb ", " bbbbbbb ", " bbbbbbb ", " bb bbbb bb bbb ", " ", " ", " ", " ", " ", " ", " ", " " }; Conforme discutido, o formato XPM também pode representar imagens mais sofisticadas, como o logotipo JFrog: Vulnerabilidade DoS – CVE-2023-43786 A vulnerabilidade CVE-2023-43786 é essencialmente um loop infinito resultante de um cálculo incorreto da condição de parada de recursão. Confirmação fixa: https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/204c3393c4c90a29ed6bef64e43849536e863a86 é uma função na libX11 que permite colocar imagens em um X Drawable, geralmente um X Window. Com esta função, é possível transferir informações de pixel de uma estrutura XImage para um drawable designado, como uma janela ou um pixmap, e posicioná-lo conforme necessário. XPutImage xpmCreatePixmapFromImage A função libXpm chama esta função : xpmCreatePixmapFromImage XPutImage void xpmCreatePixmapFromImage( Display *display, Drawable d, XImage *ximage, Pixmap *pixmap_return) { GC gc; XGCValues values; *pixmap_return = XCreatePixmap(display, d, ximage->width, ximage->height, ximage->depth); /* set fg and bg in case we have an XYBitmap */ values.foreground = 1; values.background = 0; gc = XCreateGC(display, *pixmap_return, GCForeground | GCBackground, &values); XPutImage(display, *pixmap_return, gc, ximage, 0, 0, 0, 0, ximage->width, ximage->height); XFreeGC(display, gc); } Nesta função, são os dados de pixel da imagem de origem a serem exibidos e são copiados para o objeto (neste caso ). ximage X Drawable pixmap_return XPutImage Aqui está a função libX11: XPutImage int XPutImage ( register Display *dpy, Drawable d, GC gc, register XImage *image, int req_xoffset, int req_yoffset, int x, int y, unsigned int req_width, unsigned int req_height){ ..... PutSubImage(dpy, d, gc, &img, 0, 0, x, y, (unsigned int) width, (unsigned int) height, dest_bits_per_pixel, dest_scanline_pad); UnlockDisplay(dpy); SyncHandle(); Xfree(img.data); return 0; } } LockDisplay(dpy); FlushGC(dpy, gc); PutSubImage(dpy, d, gc, image, req_xoffset, req_yoffset, x, y, (unsigned int) width, (unsigned int) height, dest_bits_per_pixel, dest_scanline_pad);......... } Ele chama a função : PutSubImage static void PutSubImage ( register Display *dpy, Drawable d, GC gc, register XImage *image, int req_xoffset, int req_yoffset, int x, int y, unsigned int req_width, unsigned int req_height, int dest_bits_per_pixel, int dest_scanline_pad) { int left_pad, BytesPerRow, Available; if ((req_width == 0) || (req_height == 0)) return; Available = ((65536 < dpy->max_request_size) ? (65536 << 2) : (dpy->max_request_size << 2)) - SIZEOF(xPutImageReq); if ((image->bits_per_pixel == 1) || (image->format != ZPixmap)) { [1] left_pad = (image->xoffset + req_xoffset) & (dpy->bitmap_unit - 1); BytesPerRow = (ROUNDUP((long)req_width + left_pad, dpy->bitmap_pad) >> 3) * image->depth; } else { [2] left_pad = 0; BytesPerRow = ROUNDUP((long)req_width * dest_bits_per_pixel, [3] dest_scanline_pad) >> 3; } if ((BytesPerRow * req_height) <= Available) { [4] PutImageRequest(dpy, d, gc, image, req_xoffset, req_yoffset, x, y, req_width, req_height, dest_bits_per_pixel, dest_scanline_pad); } else if (req_height > 1) { int SubImageHeight = Available / BytesPerRow; if (SubImageHeight == 0) SubImageHeight = 1; PutSubImage(dpy, d, gc, image, req_xoffset, req_yoffset, x, y, req_width, (unsigned int) SubImageHeight, dest_bits_per_pixel, dest_scanline_pad); PutSubImage(dpy, d, gc, image, req_xoffset, req_yoffset + SubImageHeight, x, y + SubImageHeight, req_width, req_height - SubImageHeight, dest_bits_per_pixel, dest_scanline_pad); } else { [5] int SubImageWidth = (((Available << 3) / dest_scanline_pad) [6] * dest_scanline_pad) - left_pad; PutSubImage(dpy, d, gc, image, req_xoffset, req_yoffset, x, y, (unsigned int) SubImageWidth, 1, dest_bits_per_pixel, dest_scanline_pad); PutSubImage(dpy, d, gc, image, req_xoffset + SubImageWidth, req_yoffset, x + SubImageWidth, y, req_width - SubImageWidth, 1, dest_bits_per_pixel, dest_scanline_pad); } } Detalhes técnicos da vulnerabilidade Tomemos a seguinte imagem de exemplo: Available [the requested size] = (65,536 * 4) - 28 = 262,116 bits_per_pixel = 32 width = 90,000 pixels height = 1 pixel Como a imagem é 32, a instrução condicional em [1] não será aprovada, levando-nos a inserir o bloco de código alternativo definido em [2]. bits_per_pixel Em seguida, ele calcula em [3] e depois divide por 8. Em nosso exemplo: BytesPerRow = 90000 * 32/8 = 360,0 BytesPerRow No exemplo, a verificação em [4] não seria aprovada, pois 360000 não é menor que o tamanho solicitado 262116 e não é capaz de encaixar uma única linha da largura solicitada em uma única solicitação – isso inicia o em [5 ]. else Isso determina o número de pixels que podem ser incluídos em uma única solicitação. Em seguida, ele inicia uma chamada recursiva para a função para passar apenas esse subconjunto, seguida por uma chamada recursiva subsequente para gerenciar a parte restante da linha. Se necessário, esta parte restante também pode ser dividida através de chamadas recursivas adicionais. PutSubImage No entanto, o cálculo em [6] não leva em consideração os bits por pixel, e a chamada recursiva faz solicitações enviando 2.096.928 pixels em vez de 2.096.928 bits – o que é maior do que pode caber em uma única solicitação. Isso leva a , resultando consistentemente em um número muito grande para caber e tentando novamente o processo para tentar novamente com os mesmos valores. Essa recursão persiste até que a pilha de chamadas se esgote. um loop infinito de tentativas de dividir a linha de pixels A alterou o cálculo em [6] e levou em consideração . No exemplo, resultaria em uma chamada recursiva solicitando o envio de apenas 65529 pixels, resultando em um BytesPerRow de 262116 que cabe perfeitamente no espaço disponível, permitindo assim que a recursão avance e termine em apenas 2 chamadas. correção do bug bits_per_pixel Exemplo de imagem de prova de conceito para acionar o bug: https://github.com/jfrog/jfrog-CVE-2023-43786-libX11_DoS/blob/main/cve-2023-43786.xpm Como o bug pode ser acionado Um exemplo de aplicativo que chama a função vulnerável da biblioteca libXpm é o utilitário CLI , que é usado para exibir imagens Xpm na tela. sxpm Ele chama a função vulnerável XPM, que então chama as funções vulneráveis da libX11 e depois . xpmCreatePixmapFromImage XPutImage PutSubImage Também publicado aqui.
