Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, the Lua filter is vulnerable to denial of service. Attackers can send large request bodies for routes that have Lua filter enabled and trigger crashes. As of versions versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, Envoy no longer invokes the Lua coroutine if the filter has been reset. As a workaround for those whose Lua filter is buffering all requests/ responses, mitigate by using the buffer filter to avoid triggering the local reply in the Lua filter.

**Impact**

Denial of service (crash).

**Affected components**

Lua filter.

**Attack vector/s**

Attackers can send large request bodies for routes that have Lua filter enabled and trigger crashes.

**Description**

The Lua filter can resume processing of the coroutine after we've sent a local reply due to request/response body being too large. This mitigation prevents coroutine invocation if we’re doing a local reply.

**Example exploit or proof-of-concept**

1 Configure a route that has Lua filter enabled.  
2 Send a request with a large body that is beyond the buffer limit.  
3 Have the Lua script request the request body, this will cause us to buffer the entire request body.  
4 The request body buffering can go over the limit here: https://sourcegraph.com/github.com/envoyproxy/envoy@991cde892ff88b7aca04adb7fc44e14f6c0ee0fe/-/blob/source/extensions/filters/http/lua/lua\_filter.cc?L263&subtree=true#tab=references and send the local reply, but the Lua filter is oblivious and continues the coroutine.  
5 The Lua script kicks off a HTTP request that points to the Lua filter.  
6 The Lua filter is destroyed as Envoy has completed the local reply and destroyed the related objects.  
7 The HTTP request that the Lua script kicked off in step 5 has a response, and calls the Lua filter. The filter will already be destroyed, so Envoy will segfault.

**Detection**

Given enough traffic of this type, Envoy would be crashing especially when the body buffered is larger.

**Mitigation**

For versions updated with the patch, we no longer invoke the Lua coroutine if the filter has been reset.

For older unpatched versions you can mitigate by:  
If your Lua filter is buffering all requests/ responses you can guard by using the buffer filter to avoid triggering the local reply in the Lua filter.

**Discoverer/credit**

Dan Tulovsky dant@wetsnow.com

CVE-2023-27492: Crash when a large request body is processed in Lua filter

Envoy is an open source edge and service proxy designed for cloud-native applications. Compliant HTTP/1 service should reject malformed request lines. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, There is a possibility that non compliant HTTP/1 service may allow malformed requests, potentially leading to a bypass of security policies. This issue is fixed in versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9.

CVE-2023-27491: RFC ft-ietf-quic-http: HTTP/3

Cross Site Scripting vulnerability found in Ehuacui BBS allows attackers to cause a denial of service via a crafted payload in the login parameter.

ehuacui-bbs代码审计  
项目介绍  
使用 springboot2+beetl+beetsql+elasticsearch 开发的论坛，该项目源于pybbs,使用Spring等框架进行服务端重写，优化了 源工程部分实现逻辑，前台模板和数据库表结构目前大体与pybbs 保持一致。  
开源地址  
https://gitee.com/ehuacui/ehuacui-bbs  
使用技术  
jdk1.7  
tomcat8  
Spring+MyBatias+SpringMVC  
freemarker  
mysql  
bootstrap  
ehcache  
scribejava  
Nginx  
工程简介  
bbs-doc 文档相关  
bbs-front 前端逻辑实现(部署到Nginx)  
bbs-server 后台逻辑实现(部署到Tomcat)  
bbs-sql 数据库脚本相关

漏洞复现  
手动打包  
mvn clean package  
打包完成后，会在项目根目录下的target目录里生成一个pybbs.jar文件，解压运行 java -jar pybbs.jar 即可启动论坛服务  
其实手动打包后生成的tar.gz文件就是github上release里最新的发布包，下载后解压内容是一样的  
配置本地tomcat服务

可以在数据库中看到成功注册名为<script>alert(document.cookie)</script>的用户  
漏洞分析  
用户名存储型xss  
登录成功后，未经过滤直接将用户信息在前台展示

用户注册一个用户名为<script>alert(document.cookie)</script>的用户，前台直接显示  

信息泄露：  
在用户登录成功后，cookie中的信息遭到泄露

CVE-2023-27089: ehuacui-bbs storage XSS · Issue #3 · ehuacui/ehuacui-bbs

An issue found in Directus API v.2.2.0 allows a remote attacker to cause a denial of service via a great amount of HTTP requests.

**Directus API vulnerable to denial of service**

Moderate severity GitHub Reviewed Published Apr 4, 2023 to the GitHub Advisory Database • Updated Apr 7, 2023

GHSA-3gvp-54v2-2jrp: Directus API vulnerable to denial of service

You have these 2 options in the api config which can restict access and add a rate limit.

    'cors' => [
            'enabled' => true,
            'origin' => ['*'],
            'methods' => [
                'GET',
                'POST',
                'PUT',
                'PATCH',
                'DELETE',
                'HEAD',
            ],
            'headers' => [],
            'exposed_headers' => [],
            'max_age' => null, // in seconds
            'credentials' => false,
        ],
    
        'rate_limit' => [
            'enabled' => false,
            'limit' => 100, // number of request
            'interval' => 60, // seconds
            'adapter' => 'redis',
            'host' => '127.0.0.1',
            'port' => 6379,
            'timeout' => 10
        ],

CVE-2020-19850: [SECURITY] Replay Attack · Issue #982 · directus/v8-archive

Buffer Overflow vulnerability found in tinyTIFF v.3.0 allows a local attacker to cause a denial of service via the TinyTiffReader_readNextFrame function in tinytiffreader.c file.

**Project Address**

https://github.com/jkriege2/TinyTIFF

**Security Issue Report**

A global-buffer-overflow issue was discovered in TinyTIFF in tinytiffreader.c file. The flow allows an attacker to cause a denial of service (abort) via a crafted file.

**OS information**

    ubuntu@ubuntu:~/Documents/TinyTIFF/src$ uname -a
    Linux ubuntu 5.15.0-58-generic #64~20.04.1-Ubuntu SMP Fri Jan 6 16:42:31 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
    

**Summary**

AddressSanitizer: global-buffer-overflow (/home/ubuntu/Desktop/TinyTIFF/src/asan\_tinytiffreader+0x4969c6) in \_\_asan\_memcpy

**Problem Code location**

        #0 0x4969c6 in __asan_memcpy (/home/ubuntu/Desktop/TinyTIFF/src/asan_tinytiffreader+0x4969c6)
        #1 0x4cdff4 in TinyTIFFReader_readNextFrame /home/ubuntu/Desktop/TinyTIFF/src/tinytiffreader.c
        #2 0x4cb3e9 in TinyTIFFReader_open /home/ubuntu/Desktop/TinyTIFF/src/tinytiffreader.c:921:9
        #3 0x4d10ea in main /home/ubuntu/Desktop/TinyTIFF/src/tinytiffreader.c:1058:10
        #4 0x7ffff7c4a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
        #5 0x41c3bd in _start (/home/ubuntu/Desktop/TinyTIFF/src/asan_tinytiffreader+0x41c3bd)
    

Poc file: id8

asan\_tinytiffreader

**compile the test case in the source**

cd TinyTIFF/
cmake .
make -j4
cd src/

modified the tinytiffreader.c file, add harness

int main(int argc, char \*argv\[\]){
       TinyTIFFReaderFile\* tiffr=NULL;
   tiffr=TinyTIFFReader\_open(argv\[1\]); 
   if (!tiffr) { 
	   printf("ERROR reading (not existent, not accessible or no TIFF file)\\n");
   } else { 
        const uint32\_t width=TinyTIFFReader\_getWidth(tiffr); 
        const uint32\_t height=TinyTIFFReader\_getHeight(tiffr);
        const uint16\_t bitspersample=TinyTIFFReader\_getBitsPerSample(tiffr, 0);		
        uint8\_t\* image=(uint8\_t\*)calloc(width\*height, bitspersample/8);  
        TinyTIFFReader\_getSampleData(tiffr, image, 0); 

	printf("%ld\\n",width);
        printf("%ld\\n",height);
        printf("%u\\n",bitspersample);

							///////////////////////////////////////////////////////////////////
							// HERE WE CAN DO SOMETHING WITH THE SAMPLE FROM THE IMAGE 
							// IN image (ROW-MAJOR!)
							// Note: That you may have to typecast the array image to the
							// datatype used in the TIFF-file. You can get the size of each
							// sample in bits by calling TinyTIFFReader\_getBitsPerSample() and
							// the datatype by calling TinyTIFFReader\_getSampleFormat().
							///////////////////////////////////////////////////////////////////
                
        free(image); 
    } 
    TinyTIFFReader\_close(tiffr); 

}

then,complie the tinytiffreader.c

gcc -o tinytiffreader tinytiffreader.c

test with poc

this program will trigger global-buffer-overflow crash. The asan complie program is asan\_tinytiffreader.

**ASAN Report:**

ubuntu@ubuntu:~/Desktop/TinyTIFF/src$ ./asan\_tinytiffreader out/default/crashes/id\\:000008\\,sig\\:11\\,src\\:000016+000007\\,time\\:306221\\,execs\\:34950\\,op\\:splice\\,rep\\:16 
=================================================================
==3817392==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000004e82c3 at pc 0x0000004969c7 bp 0x7fffffffd890 sp 0x7fffffffd058
READ of size 2082441480 at 0x0000004e82c3 thread T0
    #0 0x4969c6 in \_\_asan\_memcpy (/home/ubuntu/Desktop/TinyTIFF/src/asan\_tinytiffreader+0x4969c6)
    #1 0x4cdff4 in TinyTIFFReader\_readNextFrame /home/ubuntu/Desktop/TinyTIFF/src/tinytiffreader.c
    #2 0x4cb3e9 in TinyTIFFReader\_open /home/ubuntu/Desktop/TinyTIFF/src/tinytiffreader.c:921:9
    #3 0x4d10ea in main /home/ubuntu/Desktop/TinyTIFF/src/tinytiffreader.c:1058:10
    #4 0x7ffff7c4a082 in \_\_libc\_start\_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
    #5 0x41c3bd in \_start (/home/ubuntu/Desktop/TinyTIFF/src/asan\_tinytiffreader+0x41c3bd)

0x0000004e82c3 is located 61 bytes to the left of global variable '<string literal>' defined in 'tinytiffreader.c:653:13' (0x4e8300) of size 62
0x0000004e82c3 is located 0 bytes to the right of global variable '<string literal>' defined in 'tinytiffreader.c:214:32' (0x4e82c0) of size 3
  '<string literal>' is ascii string 'rb'
SUMMARY: AddressSanitizer: global-buffer-overflow (/home/ubuntu/Desktop/TinyTIFF/src/asan\_tinytiffreader+0x4969c6) in \_\_asan\_memcpy
Shadow bytes around the buggy address:
  0x000080095000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080095010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080095020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080095030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080095040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=\>0x000080095050: 00 00 00 00 00 00 00 00\[03\]f9 f9 f9 f9 f9 f9 f9
  0x000080095060: 00 00 00 00 00 00 00 06 f9 f9 f9 f9 00 00 00 00
  0x000080095070: 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 07
  0x000080095080: f9 f9 f9 f9 00 00 00 00 00 00 00 03 f9 f9 f9 f9
  0x000080095090: 00 00 00 00 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0000800950a0: 00 00 00 02 f9 f9 f9 f9 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==3817392==ABORTING

**use gdb debug this crah**

ubuntu@ubuntu:~/Documents/TinyTIFF/src$ gdb --args ./tinytiffreader id8
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html\>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86\_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/\>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/\>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./tinytiffreader...
(No debugging symbols found in ./tinytiffreader)
gdb-peda$ r id8
Starting program: /home/ubuntu/Documents/TinyTIFF/src/tinytiffreader id8

Program received signal SIGSEGV, Segmentation fault.
\[----------------------------------registers-----------------------------------\]
RAX: 0x7ffdfdd09010 --\> 0x0 
RBX: 0x55555555b2a0 --\> 0x55555555b720 --\> 0xfbad2488 
RCX: 0x0 
RDX: 0x1fa0b8878 
RSI: 0x0 
RDI: 0x7ffdfdd09010 --\> 0x0 
RBP: 0x7fffffffdcd0 --\> 0x7fffffffdda0 --\> 0x7fffffffdef0 --\> 0x7fffffffdf30 --\> 0x0 
RSP: 0x7fffffffdca8 --\> 0x555555555663 (<TinyTIFFReader\_memcpy\_s+51>:	mov    eax,0x0)
RIP: 0x7ffff7f4d8f5 (<\_\_memmove\_avx\_unaligned\_erms+533>:	vmovdqu ymm4,YMMWORD PTR \[rsi\])
R8 : 0x7ffdfdd09010 --\> 0x0 
R9 : 0x0 
R10: 0x22 ('"')
R11: 0x246 
R12: 0x555555555240 (<\_start\>:	endbr64)
R13: 0x7fffffffe020 --\> 0x2 
R14: 0x0 
R15: 0x0
EFLAGS: 0x10202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
\[-------------------------------------code-------------------------------------\]
   0x7ffff7f4d8ec <\_\_memmove\_avx\_unaligned\_erms+524>:	vmovdqu YMMWORD PTR \[r11\],ymm4
   0x7ffff7f4d8f1 <\_\_memmove\_avx\_unaligned\_erms+529>:	vzeroupper 
   0x7ffff7f4d8f4 <\_\_memmove\_avx\_unaligned\_erms+532>:	ret    
=\> 0x7ffff7f4d8f5 <\_\_memmove\_avx\_unaligned\_erms+533>:	vmovdqu ymm4,YMMWORD PTR \[rsi\]
   0x7ffff7f4d8f9 <\_\_memmove\_avx\_unaligned\_erms+537>:	vmovdqu ymm5,YMMWORD PTR \[rsi+0x20\]
   0x7ffff7f4d8fe <\_\_memmove\_avx\_unaligned\_erms+542>:	vmovdqu ymm6,YMMWORD PTR \[rsi+0x40\]
   0x7ffff7f4d903 <\_\_memmove\_avx\_unaligned\_erms+547>:	vmovdqu ymm7,YMMWORD PTR \[rsi+0x60\]
   0x7ffff7f4d908 <\_\_memmove\_avx\_unaligned\_erms+552>:	vmovdqu ymm8,YMMWORD PTR \[rsi+rdx\*1-0x20\]
\[------------------------------------stack-------------------------------------\]
0000| 0x7fffffffdca8 --\> 0x555555555663 (<TinyTIFFReader\_memcpy\_s+51>:	mov    eax,0x0)
0008| 0x7fffffffdcb0 --\> 0x1fa0b8878 
0016| 0x7fffffffdcb8 --\> 0x0 
0024| 0x7fffffffdcc0 --\> 0x1fa0b8878 
0032| 0x7fffffffdcc8 --\> 0x7ffdfdd09010 --\> 0x0 
0040| 0x7fffffffdcd0 --\> 0x7fffffffdda0 --\> 0x7fffffffdef0 --\> 0x7fffffffdf30 --\> 0x0 
0048| 0x7fffffffdcd8 --\> 0x5555555563fb (<TinyTIFFReader\_readNextFrame+886>:	jmp    0x555555556683 <TinyTIFFReader\_readNextFrame+1534>)
0056| 0x7fffffffdce0 --\> 0x0 
\[------------------------------------------------------------------------------\]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
\_\_memmove\_avx\_unaligned\_erms () at ../sysdeps/x86\_64/multiarch/memmove-vec-unaligned-erms.S:436
436	../sysdeps/x86\_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.

you can see "../sysdeps/x86\_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.", I think this problem is caused by abnormal references to Pointers, See this link.This one bug I tested on multiple systems crashed.

CVE-2023-26733: Security-Issue-Report-of-TinyTIFF/README.md at main · 10cksYiqiyinHangzhouTechnology/Security-Issue-Report-of-TinyTIFF

An issue found in Jsish v.3.0.11 and before allows an attacker to cause a denial of service via the StringReplaceCmd function in the src/jsiChar.c file.

CVE-2020-23260

Denial of service vulnerability in PowerDNS Recursor allows authoritative servers to be marked unavailable.This issue affects Recursor: through 4.6.5, through 4.7.4 , through 4.8.3.

*   CVE: CVE-2023-26437
*   Date: 29th of March 2023
*   Affects: PowerDNS Recursor up to and including 4.6.5, 4.7.4 and 4.8.3
*   Not affected: PowerDNS Recursor 4.6.6, 4.7.5 and 4.8.4
*   Severity: Low
*   Impact: Denial of service
*   Exploit: Successful spoofing may lead to authoritative servers being marked unavailable
*   Risk of system compromise: None
*   Solution: Upgrade to patched version

When the recursor detects and deters a spoofing attempt or receives certain malformed DNS packets, it throttles the server that was the target of the impersonation attempt so that other authoritative servers for the same zone will be more likely to be used in the future, in case the attacker controls the path to one server only. Unfortunately this mechanism can be used by an attacker with the ability to send queries to the recursor, guess the correct source port of the corresponding outgoing query and inject packets with a spoofed IP address to force the recursor to mark specific authoritative servers as not available, leading a denial of service for the zones served by those servers.

CVSS 3.0 score: 3.7 (Low) https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:N/I:N/A:L

Thanks to Xiang Li from Network and Information Security Laboratory, Tsinghua University for reporting this issue.

CVE-2023-26437: Deterred spoofing attempts can lead to authoritative servers being marked unavailable — PowerDNS Recursor documentation

An issue found in Jsish v.3.0.11 and before allows an attacker to cause a denial of service via the Jsi_Strlen function in the src/jsiChar.c file.

CVE-2020-23259

An issue found in Jsish v.3.0.11 allows a remote attacker to cause a denial of service via the Jsi_ValueIsNumber function in ./src/jsiValue.c file.

Tag

#dos