Syscalls linux32 #1170

Te-k · 2020-03-30T23:58:05Z

Hi,

I have implemented a few more syscalls for Linux 32 (and some generic for Linux 64b too).
I am able to emulate several Linux 32b shellcodes with it, like :

[DEBUG   ]: socket(AF_INET, SOCK_STREAM, 0)
[DEBUG   ]: -> 3
WARNING: address 0x1240000 is not mapped in virtual memory:
[DEBUG   ]: socket_connect(fd, [AF_INET, 1234, 10.2.2.14], 102)
[DEBUG   ]: -> 0
Done

What do you think ?

serpilliere · 2020-03-31T10:44:24Z

miasm/os_dep/linux/environment.py

+    def read(self, count):
+        return b""
+


Maybe it's not a good idea to have a default read here. Maybe we can raise an error with pure abstract function, in order to for the user subclass this in order to implements it's own read.
See for example

miasm/miasm/ir/translators/translator.py

Line 50 in 4c2320b

raise NotImplementedError("Abstract method")

The user can subclass its own LinuxEnvironement and set a brand new self.network

I like the idea, but it seems hard to subclass, it means you have to implement a subclass of FileDescriptorSocket, Network and LinuxEnvironment, and make all this work together, right ?

Kind of. It will give something like:

class CustomFileDescriptorSocket(FileDescriptorSocket): def read(self, count): print("Turlututu") class CustomNetworking(Networking): def socket(self, family, type_, protocol): fd = self.linux_env.next_fd() fdesc = CustomFileDescriptorSocket(fd, family, type_, protocol) self.linux_env.file_descriptors[fd] = fdesc return fd class CustomLinuxEnvironment(LinuxEnvironment): def __init__(self): super(CustomLinuxEnvironment, self).__init__() self.network = CustomNetworking(self)

But maybe there is better: we could modify those classes to have a class variable which embed their needs. For example, for Networking:

class Networking(object): """Network abstraction""" fd_generator = FileDescriptorSocket def __init__(self, linux_env): self.linux_env = linux_env def socket(self, family, type_, protocol): fd = self.linux_env.next_fd() fdesc = self.fd_generator(fd, family, type_, protocol) self.linux_env.file_descriptors[fd] = fdesc return fd

So the "overhead" may just be:

class CustomNetworking(Networking): fd_generator = CustomFileDescriptorSocket

But I am not really sure if this is a suitable python pattern.
Or maybe Networking should take it's generator as init argument ?
It's a problem we already face in the SandBox object, which depends on os, arch, ...

@commial @p-l- I am interested if you have some feed on this.

I'm not sure this is the same problem than the multiple inheritance of Sandbox. IMHO, it looks like more what we've done in Jitcore with Cgen or SymbExecClass, which reflects your last proposal.

In my opinion, the question is "what we want to provides, and what customization should be reasonably easy to implements?".
I agree with the fact that it should be easy to modify what the socket returns, its state, etc. i'm not sure that the more global Networking part needs that kind of customization possibility.

A pattern we can use would be to provides a kind of "socket factory" (sorry for this word, but it is what it is) that the Network would use to creates its sockets.
It could be a function, taking as input the socket parameters and returning an instance with the socket "interface", ie. a subclass of the socket fd.
It could also be a class, taking as __init__ these parameters, and asked just after for successful creation or not (to keep the possibility to easiliy deny socket creation). I rather prefer the function solution, as it could be easier to return default implementation or several socket families implementation.

This "factory function" is then an attribute of the Networking class, and could be replaced with a dedicated function / property.

If this pattern become more frequent for the Linux kernel stub implementation, we could have a "config-like" class containing several factories functions, or hooks.

What do you think?

So the socket factory would be an attribute of Network ?

Using it would be something like :

class CustomFileDescriptorSocket(FileDescriptorSocket): def read(self, count): print("Chapeau pointu") env = environment.LinuxEnvironment_x86_32() env.network.socket_class = CustomFileDescriptorSocket

Is that correct ?

serpilliere · 2020-03-31T10:51:27Z

miasm/os_dep/linux/syscall.py

+    while envp_addr != 0:
+        argv.append(jitter.get_c_str(envp_addr))
+        i += 4
+        argv_addr = jitter.vm.get_u32(jitter.cpu.EDX+i)


maybe it's envp_addr here instead of argv_addr?

serpilliere · 2020-03-31T10:52:23Z

miasm/os_dep/linux/syscall.py

+    envp = []
+    i = 0
+    while envp_addr != 0:
+        argv.append(jitter.get_c_str(envp_addr))


Maybe it's envp instead of argv here?

serpilliere · 2020-03-31T10:52:45Z

miasm/os_dep/linux/syscall.py

+    envp = []
+    i = 0
+    while envp_addr != 0:
+        argv.append(jitter.get_c_str(envp_addr))


Same remarks here for argv

Damn copy paste

serpilliere · 2020-03-31T10:52:56Z

miasm/os_dep/linux/syscall.py

+    while envp_addr != 0:
+        argv.append(jitter.get_c_str(envp_addr))
+        i += 8
+        argv_addr = jitter.vm.get_u64(jitter.cpu.EDX+i)


Same remarks here for argv_addr

serpilliere · 2020-03-31T10:58:10Z

miasm/os_dep/linux/syscall.py

+        raise NotImplemented()
+
+
+def sys_generic_chmod(jitter, linux_env):


Maybe we could really apply the chmod on the file located in the file sandbox file_sb ?

serpilliere · 2020-03-31T10:59:10Z

miasm/os_dep/linux/syscall.py

+    status, = jitter.syscall_args_systemv(1)
+    log.debug("sys_exit(%i)", status)
+    jitter.run = False
+    jitter.pc = 0


Maybe you don't need to set pc to 0 here

serpilliere · 2020-03-31T11:03:23Z

miasm/os_dep/linux/syscall.py

+def sys_generic_setreuid(jitter, linux_env):
+    # Parse arguments
+    ruid, euid = jitter.syscall_args_systemv(2)
+    log.debug("sys_setreuid(%x, %x)", ruid, euid)


We could use the current Linux env uid/euid/gid of the linux env here?

serpilliere · 2020-03-31T11:04:49Z

miasm/os_dep/linux/syscall.py

@@ -169,14 +176,22 @@ def sys_x86_32_socket(jitter, linux_env):
        #           socklen_t addrlen);
        fd = jitter.vm.get_u32(jitter.cpu.ESP)
        socklen = jitter.vm.get_u32(jitter.cpu.ESP+8)
-        # Not the exact size because shellcodes won't provide the full struct
-        sockaddr = jitter.vm.get_mem(jitter.vm.get_u32(jitter.cpu.ESP+4), 8)
+        try:


What about using the socklen instead of a fixed length?

In some cases, a shellcode would not have a full sockaddr struct but just the needed fields, what I have done in the next commit is getting the socklen and if it fails, I only get the first 8 bytes. Is that an ok trick to have it work ?

In fact, maybe we should behave like the kernel does so we will be close to a real environment.
If the kernel is ok with semi structures, maybe your patch is ok.

I have added a first get_mem for the full structure and fallback to 8 bytes if the memory if not that large, it should be close to what the kernel is doing I guess

miasm/os_dep/linux/syscall.py

Te-k · 2020-03-31T12:16:11Z

All good points, thanks. I will fix these later this week.

serpilliere · 2020-03-31T12:31:57Z

Thank you for you PR @Te-k !
If you really want to be sure we won't break anything in the future, maybe we could add a regression test of one of your shellcode (if you can share them, obvisouly), but put it in the https://github.com/cea-sec/miasm-extended-tests repository. Those tests are currently executed by the Miasm travis file.
The reason is simple:
Some times ago, we put a shellcode directly in the main repository, and the travis environment has flagged Miasm as malware and refused to run regression tests.
Maybe we should definitively not commit any shellcode/malware in the main repo, as it may be flagged as malware by PIP or distributions.

Another reason is to not add too many weight to the main repo.

Te-k · 2020-04-07T20:57:23Z

I have made some fix based on your suggestions, two are still unresolved :

Whether or not to implement read on sockets
~~Should it create a socket on connect ? (not sure why it would)~~

Just one warning : I have added a change on uid and euid in sys_generic_setreuid and it does not check for privileges to do that, should I implement privileges here ?

Let me know what you think

Te-k · 2020-04-07T21:05:53Z

And I have added a script in the examples to emulate Linux shellcodes, which is needed to add test cases to miasm-extended-tests

Te-k · 2020-04-07T21:12:35Z

And here is the PR for the test cea-sec/miasm-extended-tests#1 along with the update of travis config file (I have not tested it but it should be simple enough to work)

Te-k added 3 commits March 29, 2020 00:18

add several syscalls

1a8b917

Merge branch 'master' into syscall_linux32

20e9a75

fixes bugs in socket

eca3635

serpilliere reviewed Mar 31, 2020

View reviewed changes

Improve linux syscalls

13e8a4f

add example script of shellcode emulation on linux

c3854c5

Te-k mentioned this pull request Apr 7, 2020

Add test of linux syscalls cea-sec/miasm-extended-tests#1

Open

Add additional test

84d96a1

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Syscalls linux32 #1170

Syscalls linux32 #1170

Te-k commented Mar 30, 2020

serpilliere Mar 31, 2020

Te-k Apr 7, 2020

serpilliere Apr 8, 2020

commial Apr 8, 2020

Te-k Apr 8, 2020

serpilliere Mar 31, 2020

Te-k Apr 7, 2020

serpilliere Mar 31, 2020

Te-k Apr 7, 2020

serpilliere Mar 31, 2020

Te-k Apr 7, 2020

serpilliere Mar 31, 2020

serpilliere Mar 31, 2020

serpilliere Mar 31, 2020

serpilliere Mar 31, 2020

serpilliere Mar 31, 2020

Te-k Mar 31, 2020

serpilliere Mar 31, 2020

Te-k Apr 7, 2020

Te-k commented Mar 31, 2020

serpilliere commented Mar 31, 2020

Te-k commented Apr 7, 2020 •

edited

Te-k commented Apr 7, 2020

Te-k commented Apr 7, 2020

		raise NotImplemented()


		def sys_generic_chmod(jitter, linux_env):

Syscalls linux32 #1170

Are you sure you want to change the base?

Syscalls linux32 #1170

Conversation

Te-k commented Mar 30, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Te-k commented Mar 31, 2020

serpilliere commented Mar 31, 2020

Te-k commented Apr 7, 2020 • edited

Te-k commented Apr 7, 2020

Te-k commented Apr 7, 2020

Te-k commented Apr 7, 2020 •

edited