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.

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

Check if syscall table is faked #37

Open
alexandernst opened this issue Dec 5, 2013 · 15 comments
Open

Check if syscall table is faked #37

alexandernst opened this issue Dec 5, 2013 · 15 comments
Assignees
Milestone

Comments

@alexandernst
Copy link
Owner

Procmon should check if the syscall table is already patched by something else (or even by a remaining stub from procmon itself, as of #31). If the syscall table is patched, procmon should do nothing.

@ghost ghost assigned alexandernst Dec 5, 2013
@alexandernst
Copy link
Owner Author

Scratch last phrase. Procmon should be able to determine if the syscall table is already patched, and if it is, it should be possible to guess if it's patched by procmon's stubs. If so, it should be possible to get the real syscall address and re-patch.

@alexandernst
Copy link
Owner Author

Also scratch that last thing! It should be possible to do so, BUT, if user really wants to re-patch the syscalls (meaning patch the stubs with another stubs) tell him clearly why that it's not a good idea. Anyways, give him the option to do so... We won't fight against brave people! 😃

@milabs
Copy link
Contributor

milabs commented Dec 25, 2013

@alexandernst Alexander, what do you think about the option of restore original system call table using the vmlinux (or packed vmlinuz) images? Procmon may be used as a simple "anti-rootkit" solution in that case :)

@alexandernst
Copy link
Owner Author

@milabs Oh, that's an interesting point! You mean something like scan (with udis? 😝 ) a vmlinux binary, check where syscalls should be and then check the current syscall table, right?

@milabs
Copy link
Contributor

milabs commented Dec 26, 2013

@alexandernst Yes!

@alexandernst
Copy link
Owner Author

@milabs Procmon (Monks!) could expose the address of each syscall the same way it exposes the state of each syscall (via sysctl). That way we could do the checking part in the viewer rather than the kernel module. What do you think?

@milabs
Copy link
Contributor

milabs commented Dec 26, 2013

@alexandernst How do you intend to scan kernel's memory from the viewer?

@alexandernst
Copy link
Owner Author

@milabs No need.

1. Load the kernel.
2. Create entries for each syscall (currently we do that already) in ```procmon.syscalls.__NR_read.realsc_addr```
3. Start the viewer and check those values from ```sysctl``` while reading a binary vmlinux image.

I think it could work.

@milabs
Copy link
Contributor

milabs commented Dec 26, 2013

@alexandernst OK, I've got it. Do you think that sysctl is a good information exporting interface?

@alexandernst
Copy link
Owner Author

@milabs Maybe not the best one. sysctl is the first thing I thought, but it could be replaced with anything :)
The main idea is to keep as little logic as possible in the kernel module. The kernel module itself should just expose information and swap real with fake syscalls.

@milabs
Copy link
Contributor

milabs commented Dec 26, 2013

@alexandernst I think proc interface is a good choice for that purporse. Sysctl not the best one as I see it.

@alexandernst
Copy link
Owner Author

In the end they both are quite the same. They place some files inside /proc, just that they place them in different locations.
Ok, I'll open an issue for this

@milabs
Copy link
Contributor

milabs commented Dec 26, 2013

@alexandernst procfs allows to read one file to get meny things (list of broken syscalls, for ex.) I don't think that sysctl does it as well as proc besides of the same back interface :)

@alexandernst
Copy link
Owner Author

@milabs Ah, indeed! Good point :)
If no other alternative shows up, procfs will it be

@milabs
Copy link
Contributor

milabs commented Dec 26, 2013

@alexandernst procfs is the simplier one :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants