Issue with running wmic on Debian 12/bookworm

[ramijebara]

Found an odd issue compiling the latest code on Debian 12 vs. Debian 11. This issue is specific to the wmic CLI application

Expected behavior (Debian 11)

The behavior of the application will be the same between the two versions of Debian.

The environment is Docker using the dockerfile in the repo.

On Debian 11:

Build command:

docker buildx build --pull -t openvas-smb:11 -f .docker/.docker/prod-oldstable.Dockerfile .

# docker run -it openvas-smb:11 /bin/sh
# cd /usr/local/bin
# ./wmic -U USERNAME%PASSWORD  //10.X.X.X "select * from Win32_ComputerSystem"                                                                                
CLASS: Win32_ComputerSystem
AdminPasswordStatus|AutomaticManagedPagefile|AutomaticResetBootOption|AutomaticResetCapability|BootOptionOnLimit|BootOptionOnWatchDog|BootROMSupported|BootStatus|BootupState|Caption|ChassisBootupState|ChassisSKUNumber|CreationClassName|CurrentTimeZone|DaylightInEffect|Description|DNSHostName|Domain|DomainRole|EnableDaylightSavingsTime|FrontPanelResetStatus|HypervisorPresent|InfraredSupported|InitialLoadInfo|InstallDate|KeyboardPasswordStatus|LastLoadInfo|Manufacturer|Model|Name|NameFormat|NetworkServerModeEnabled|NumberOfLogicalProcessors|NumberOfProcessors|OEMLogoBitmap|OEMStringArray|PartOfDomain|PauseAfterReset|PCSystemType|PCSystemTypeEx|PowerManagementCapabilities|PowerManagementSupported|PowerOnPasswordStatus|PowerState|PowerSupplyState|PrimaryOwnerContact|PrimaryOwnerName|ResetCapability|ResetCount|ResetLimit|Roles|Status|SupportContactDescription|SystemFamily|SystemSKUNumber|SystemStartupDelay|SystemStartupOptions|SystemStartupSetting|SystemType|ThermalState|TotalPhysicalMemory|UserName|WakeUpType|Workgroup
3|True|True|True|0|0|True|(0,0,0,127,4,0,127,0,0,0)|Normal boot|WINS2019-2|3|(null)|Win32_ComputerSystem|-420|True|AT/AT COMPATIBLE|wins2019-2|WORKGROUP|2|True|3|True|False|NULL|(null)|3|(null)|QEMU|Standard PC (i440FX + PIIX, 1996)|WINS2019-2|(null)|True|4|4|NULL|NULL|False|-1|1|1|NULL|False|3|0|3|(null)|Windows User|1|-1|-1|(LM_Workstation,LM_Server,NT,Server_NT)|OK|NULL|(null)|(null)|0|NULL|0|x64-based PC|3|8589393920|(null)|6|WORKGROUP

Actual behavior (Debian 12)

On a Debian 12:

Build command:

docker buildx build --pull -t openvas-smb:12 -f .docker/.docker/prod.Dockerfile .

# docker run -it openvas-smb:12 /bin/sh
# cd /usr/local/bin
# ./wmic -U USERNAME%PASSWORD  //10.X.X.X "select * from Win32_ComputerSystem" 
[/source/samba/librpc/rpc/dcerpc_connect.c:337:dcerpc_pipe_connect_ncacn_ip_tcp_recv()] failed NT status (c00000b5) in dcerpc_pipe_connect_ncacn_ip_tcp_recv
[/source/samba/librpc/rpc/dcerpc_connect.c:798:dcerpc_pipe_connect_b_recv()] failed NT status (c00000b5) in dcerpc_pipe_connect_b_recv
[/source/wmi/wmic.c:201:main()] ERROR: Login to remote object.
NTSTATUS: NT_STATUS_IO_TIMEOUT - NT_STATUS_IO_TIMEOUT

Hypothesis on the cause of the issue

I did some basic troubleshooting of the issue with a colleague of mine and we believe this issue is related to popt.

Debian 11 uses popt 1.18 and debian 12 uses popt 1.19. In fact, if you compile popt 1.18 manually on Debian 12 and link it statically to the code the issue goes away. I realize this is hacky, it does however indicate that the issue is somehow related to the version of popt.

If you want to test this yourself here are some instructions.

1) install dependencies 2) download and build popt 1.18 from source

wget http://ftp.rpm.org/popt/releases/popt-1.x/popt-1.18.tar.gz
tar xf popt-1.18.tar.gz
cd popt-1.18/
mkdir build
cd build
CFLAGS="-fPIC -static" ../configure --enable-shared=no
make -j6

The static library ends up in popt-1.18/build/src/.libs/libpopt.a

3) in openvas-smb/wmi/CMakeList.txt, above "add_executable(wmic wmic.c...", add:

add_library(popt STATIC IMPORTED)
set_target_properties(popt PROPERTIES IMPORTED_LOCATION /path/to/your/libpopt.a)

4) create a build directory, "cmake .. && make -j6"

Run the test command above on the test machine.

Environment

Docker using official docker files, Though it is easy to reproduce this issue on a VM.

[cfi-gb]

Nice analysis :+1:

It seems this could be a duplicate of greenbone/openvas-scanner#1491, at least the messages looks quite similar.

[jjnicola]

Thanks a lot @ramijebara !