Alibek Baxtiyorov

Um erro de precedência de operador existe no validador `cv.url()` em `esphome/config validation.py`. Devido ao fato de o operador `and` ter maior precedência que o `or`, qualquer URI `file:` passa na validação, independentemente do local da rede. Este validador controla o campo `url:` da diretiva YAML `external components` do esquema de fonte git, que é posteriormente passado para o `git clone`. Um invasor pode usar um bloco `external components` manipulado com uma `url` apontando para um caminho local, como `file:///attacker/repo`, para clonar um diretório local controlado pelo invasor. Este diretório é então adicionado ao mecanismo de importação do Python via carregador de componentes do ESPHome, permitindo a execução de código Python arbitrário quando a configuração YAML é processada por meio de comandos como `esphome config` ou `esphome run`.

O componente `web server` expõe senhas em texto simples. Na função `WebServer::text json ()`, entidades de texto configuradas com `mode: password` têm seu campo `state` do JSON mascarado, mas a senha bruta é gravada no campo `value` do JSON através de `set json icon state value()` e `set json value()`. Como o servidor web escuta na porta 80 sem autenticação por padrão, um invasor na rede local pode recuperar informações sensíveis, como credenciais de WiFi ou tokens de API, através do endpoint `GET /text/<entity id>` ou do fluxo EventSource `/events`.

Um estouro de inteiro ocorre no processamento de metadados do chunk CUE W64. Na função `drwav metadata process chunk()`, uma estimativa de capacidade de estágio 1 trunca o `sizeInBytes` do chunk W64 de 64 bits para `size t` antes de dividir por `DRWAV CUE POINT BYTES`. Em compilações de 32 bits, esse truncamento causa o cálculo incorreto da capacidade de metadados extra pré-alocada. Posteriormente, a função `drwav read cue to metadata obj()` calcula a contagem real de pontos de dica e o tamanho da alocação usando o campo `cuePointCount` controlado por um invasor, sem a devida verificação contra a estimativa de capacidade inicial. Como a aplicação de limites em `drwav metadata get memory()` depende de um `DRWAV ASSERT` que é desativado em versões de lançamento, um arquivo WAV W64 manipulado pode causar um estouro de buffer de heap em qualquer aplicativo de 32 bits que processe metadados WAV não confiáveis.

O componente `BlobStorageController.cs` carece do atributo `[Authorize]` e não possui uma `FallbackPolicy` de autorização global configurada no `Startup.cs`. Isso permite que atacantes remotos não autenticados acessem os endpoints 'Upload', 'Download', 'List', 'Modify' e 'Delete'. Além disso, os parâmetros `path` e `filename` passados para esses endpoints são utilizados sem sanitização na função ` blob.WriteFileAsync()`. Isso resulta em path traversal, permitindo que atacantes leiam, gravem, modifiquem e excluam arquivos arbitrários fora do diretório de armazenamento de blob pretendido. Se caminhos acessíveis via web forem visados, isso pode ser explorado para alcançar a execução remota de código através do upload de um webshell.

A porta LINUXTCP do FreeModbus contém uma verificação de limite off-by-one na função `xMBPortTCPPool()` localizada em `demo/LINUXTCP/port/porttcp.c`. O problema ocorre porque a verificação `if (usTCPFrameBytesLeft > MB TCP BUF SIZE)` utiliza uma comparação de maior estrito em vez de maior ou igual ao limite de 263 bytes de `MB TCP BUF SIZE`. Um quadro MBAP (Modbus Application Protocol) com um campo de comprimento de 264 faz com que `usTCPFrameBytesLeft` seja 263, o que ignora a verificação. Consequentemente, a função `recv()` grava até 263 bytes a partir do deslocamento de buffer 7 no buffer estático `aucTCPBuf` de 263 bytes, causando um estouro de 7 bytes na variável estática adjacente `usTCPBufPos`. Isso pode ser acionado por um único pacote Modbus TCP manipulado e não autenticado.

O software contém duas falhas de segurança. Primeiro, o endpoint 'GET /json/cfg' chama a função `serveJson()` sem verificar o PIN de configurações, permitindo que qualquer cliente não autenticado na rede visualize detalhes da configuração geral, incluindo rede, hardware e configuração de LED. Segundo, o estado de desbloqueio do PIN de configurações é gerenciado por uma única variável booleana global `correctPIN` em vez de um estado por sessão. Consequentemente, se qualquer cliente fornecer o PIN de 4 dígitos correto através do endpoint 'POST /json', a variável `correctPIN` torna-se verdadeira para todos os usuários. Isso concede a todos os clientes não autenticados subsequentes acesso total de escrita à configuração, permitindo ações como atualizações de firmware OTA, reconfiguração de WiFi e reset de fábrica até que o dispositivo seja reiniciado.

A função `MochadTCP::MatchLine()` no arquivo `hardware/MochadTCP.cpp` não realiza verificações de comprimento ao copiar dados do `m mochadbuffer` (até 1028 bytes) para um buffer de pilha fixo de 50 bytes chamado `tempRFSECbuf` usando `strcpy()`. Isso ocorre em três ramificações de código para os tipos de dispositivo DS10A, KR10A e MS10A. Um invasor na rede local pode enviar um pacote manipulado para a ponte Mochad TCP na porta 1099, que não requer autenticação, para causar um estouro no `tempRFSECbuf` e corromper a pilha da thread de trabalho.

A função `tinyobj parse and index mtl file()` em `tinyobj loader c.h` lê linhas de um arquivo de material .mtl para um buffer de pilha fixo de 4096 bytes `linebuf` usando `memcpy(linebuf, p, p len)`. A operação é protegida por `assert(p len < 4095)`, mas como o `assert()` é desativado em compilações de release (compiladas com -DNDEBUG), um arquivo .mtl manipulado com uma linha superior a 4096 bytes pode causar um estouro de pilha. Isso permite que o `linebuf` transborde para a variável `namebuf` adjacente e outras memórias da pilha, potencialmente corrompendo a pilha de aplicativos que carregam arquivos de modelos ou materiais 3D maliciosos. Este mesmo padrão ocorre em outra função no mesmo arquivo.

As funções `mtar write file header()` e `mtar write dir header()` em `src/microtar.c` contêm um estouro de buffer de pilha (stack buffer overflow). Isso ocorre porque um nome de entrada fornecido pelo chamador é copiado para o campo `name` de 100 bytes de um `mtar header t` alocado na pilha via `strcpy(h.name, name)`, sem verificar se o comprimento da variável `name` é inferior a 100 caracteres. Aplicações que utilizam essas funções para arquivar nomes de arquivos influenciados por usuários externos ou atacantes com mais de 99 caracteres podem disparar esse estouro.

A função `compile program()` em `webserver/openplc.py` não valida a variável `file path` ao processar diretivas `(*FILE:path content*)` de arquivos de programa Structured Text (.st) carregados. Isso permite que um invasor utilize sequências de traversal de caminho para gravar conteúdo arbitrário em qualquer caminho do sistema de arquivos fora do diretório `./core` pretendido, resultando em execução remota de código por meio de mecanismos como cron jobs ou chaves autorizadas do SSH. O software também possui credenciais padrão fixas (openplc:openplc), o que facilita a exploração.

O módulo de armazenamento de biblioteca local-filesystem contém uma falha de traversal de caminho nas funções `getLibraryEntry()` e `saveLibraryEntry()`. Este problema ocorre porque o parâmetro de caminho fornecido pelo usuário é unido diretamente ao caminho do sistema de arquivos via `fspath.join(libDir, type, path)` sem sanitização, verificações de contenção ou normalização de caminho. A falha é acessível através dos endpoints GET e POST `/library/:lib/:type/*path`. Um usuário autenticado pode usar sequências `../` para ler arquivos arbitrários fora do diretório da biblioteca. Usuários com acesso de escrita podem gravar arquivos arbitrários, o que pode levar à execução remota de código por meio de injeção de cron ou modificação de authorized keys do SSH.

O endpoint `POST /api/v1/convert/url/pdf` em `ConvertWebsiteToPDF.java` carece de proteções contra Server-Side Request Forgery (SSRF). Embora o endpoint verifique se a URL inicial resolve para um IP público, ele busca o HTML e o entrega sem sanitização para um subprocesso WeasyPrint. Isso permite que um invasor utilize referências de recursos incorporados, como tags `<img>`, para forçar o servidor a recuperar recursos de rede interna ou endpoints de metadados de nuvem e incluir seus conteúdos no PDF gerado.

Ocorre uma validação insuficiente de URLs de webhook na função `isReservedIP()` localizada em `internal/webhook/validate.go`. A função verifica IPs candidatos em uma lista de CIDR reservada, mas omite a faixa 0.0.0.0/8 e não chama `ip.IsUnspecified()`. Como o Linux redireciona conexões para 0.0.0.0 para a interface de loopback (127.0.0.1), um invasor pode registrar uma URL de webhook como 'http://0.0.0.0:PORT/' para ignorar as verificações de IP reservado. Isso permite que o servidor faça requisições HTTP externas para sua própria interface de loopback, expondo potencialmente serviços internos.

A função de despacho de webhook `safeDialContext()` (internal/webhook/webhook.go) resolve o nome do host de destino usando `net.DefaultResolver.LookupHost` e valida os IPs resultantes contra intervalos reservados. No entanto, ela subsequentemente chama `net.JoinHostPort(host, port)` usando o nome do host original em vez do endereço IP validado. Como o `net.Dialer.DialContext()` realiza sua própria resolução de DNS, um invasor que controle o DNS do nome do host do webhook pode empregar uma técnica de DNS-rebinding. Ao usar um Time-to-Live (TTL) curto, o invasor pode fornecer um IP público permitido durante a fase de validação e um IP interno diferente durante a fase de conexão real, ignorando as proteções de Server-Side Request Forgery (SSRF). DNS-rebinding é uma técnica usada para burlar controles de segurança alterando o registro de DNS entre o momento da verificação e o momento do uso.

O endpoint '/cfg wifi set' em 'src/httpserver/http fns.c' permite alterações de configuração por meio de uma requisição GET sem a necessidade de um token Cross-Site Request Forgery (CSRF). CSRF é um tipo de ataque que engana a vítima para enviar uma requisição maliciosa. Se o parâmetro `web admin password enabled` estiver ausente na requisição, o sistema limpa a senha do administrador web, definindo-a como uma string vazia. Isso permite que um invasor utilize um payload de um clique para sequestrar a configuração do WiFi e desativar a proteção por senha caso um administrador autenticado visite um link malicioso.

O software não sanitiza rótulos de canais recebidos via comando MQTT SetChannelLabel na função `CHANNEL SetLabel()` (src/cmnds/cmd channels.c). Esses rótulos são armazenados usando `strdup()` e posteriormente retornados sem sanitização por `CHANNEL GetLabel()`. Em seguida, os rótulos são renderizados via `hprintf255()` em mais de 15 locais em src/httpserver/http fns.c sem codificação HTML. Um invasor com acesso ao broker MQTT pode injetar um payload `<script>` em um rótulo de canal, que é executado quando um usuário visualiza o painel web do dispositivo. Trata-se de um problema de Cross-Site Scripting (XSS) armazenado, onde scripts maliciosos são permanentemente armazenados no servidor alvo e servidos a outros usuários.

A função `http fn ota exec()` em `src/httpserver/http fns.c` não realiza a codificação HTML ao processar o parâmetro de consulta `host`. Isso permite que o parâmetro seja refletido diretamente em uma resposta HTML através da função `hprintf255()`. Um invasor pode usar uma URL manipulada direcionada ao endpoint `/ota exec` para executar JavaScript arbitrário no navegador de um administrador autenticado.

A API de leitura de mensagens (message-readers API) lê um valor `format` da string de consulta HTTP em `readers/api/http/transport.go` sem validação. Este valor é interpolado diretamente em consultas SQL brutas usando `fmt.Sprintf()` no leitor PostgreSQL (`readers/postgres/messages.go`) e no leitor TimescaleDB (`readers/timescale/messages.go`). Esta falha permite que um usuário autenticado com permissões para consultar mensagens de canal realize a injeção de SQL (SQL injection), uma técnica onde instruções SQL maliciosas são inseridas em campos de entrada para execução pelo banco de dados.

A implementação do request-guard `AuthToken` em `api/src/main.rs` não valida o valor do cabeçalho HTTP `Authorization` em relação a uma sessão, armazenamento de tokens ou assinatura. Ela apenas verifica se o cabeçalho está presente. Consequentemente, qualquer requisição que contenha um cabeçalho `Authorization` não vazio pode ignorar a guarda e obter acesso a todos os endpoints protegidos.

Um invasor não autenticado pode alcançar a execução arbitrária de JavaScript no processo do servidor ao criar e acionar uma regra de cálculo maliciosa. O endpoint 'POST /calc-rule/create' não possui o guardião de requisição AuthToken, permitindo o acesso sem autenticação para criar uma regra contendo um campo `script` arbitrário. Este script armazenado é posteriormente executado através da função `quick js::Context::eval()` sem sandboxing.