1

I would like to know if there is a way to run an app to exhaustion in terms of all possible outcomes that it can provide.

What do I mean by that:

Let's assume that someone has an (Apache) HTTP Server. What I am trying to do is to create profiles of nominal execution of this http server. These profiles will then be used as a sandbox/wrapper for this specific app and if the app executes anything else other than that (due to malicious activity to the app such as code injection) to halt the execution and throw a warning.

So to make it more clear let's assume that the execution of an app is completely deterministic.

We know from the start that the app will output either the number 30, either the number -5 or the number 0. If the app, for example, outputs any other number other than the aforementioned ones then I need to show an error. Or maybe if it outputs a string or a char then again I need to throw an error, because we are expecting only the numbers 30, -5 or 0.

To make it more realistic:

What I am trying to do is to somehow exhaust all possible execution outcomes of an http server and audit what calls it makes on the linux kernel. That way, I could profile how it normally interacts with the kernel considering all normal executions and then compare these/this profile(s) with real life executions. If at some point, the real-life executions diverge from these/this profile(s) then I should display a message that something is off.

Now you may wonder that if for example the server receives a software update then its execution may diverge because the source code changed from the previous version. And you are right. But let's assume that we stick with a specific version and we do not move from there no matter if there are updates or not. So we profile only one version of the http server.

What I have tried to do so far is to download apache and run an strace and at the same time send http requests via postman. But it seems that it is not very helpful as I do not see much difference in the strace logs.

So is it possible to create such profiles?

You could provide real-life scenarios with apache server (if possible) or any other http server that may be easier.

---UPDATE---

CLARIFICATIONS:

I understand that I have not made the problem very clear. I apologize for any confusion that my question has created. I was not in the right mind when I was writing this. So, to clarify things:

Basically if I have an http server (apache or any other) according to the different possible executions of the server I want to observe/audit how it interacts with the Linux Kernel.

Let me give you an example:

Lets assume that I run an http server on 10.0.0.2 on a Ubuntu machine and I make a GET request like this: http://10.0.0.2/log/log.txt.

I want to see on the level of linux kernel how the http server interacts with the kernel for this request. For example did the server tried to call some version of alloc (malloc,calloc,etc...). If yes, what were the parameters? Or maybe it called system(). Why? What were the parameters, if any?

Now according to what functions it calls and what type of parameters it passes through the calls I want to profile the server.

I get the fact that there are tons of different requests on http servers with different parameters and false-positives, false-negatives, etc... are very much possible. But at least I want to try and see what data could I possibly trace.

Sorry again for the confusion and I hope it clarify things a little bit more.

7
  • You question isn't clear to me: Asking for all different outcomes (first sentence) is very different than asking about all different executions (i.e. execution profile, as asked in the title) since there might be multiple ways which result in the same output. And "execution profile" is too unspecific: this can be at the level of exact CPU instructions, of accessed files, of used system calls, of specific timing, ... Commented May 19 at 4:20
  • As long as do good error handling and as far as I understood you correctly for primitive use cases it should work more or less.. Commented May 19 at 8:58
  • @SteffenUllrich: Please take a look on the updated question. I am sorry for the confusion. Commented May 19 at 20:16
  • @SirMuffington Please take a look on the updated question. I am sorry for the confusion. Commented May 19 at 20:16
  • You can trace what the http server is doing this way - but is your application even the same process as the http server? In lots of cases the internet facing HTTP server is just a reverse proxy for the application or will execute CGI scripts in separate processes - in which case you will not see the application specific behavior when watching only the HTTP server. As for malloc etc - these are not system calls but memory managment is implement in the user space library (libc) and is done by managing larger blocks it got from the kernel using sbrk or mmap. Commented May 19 at 20:21

1 Answer 1

0

It would be great if there was a way to automatically and reliably distinguish between malicious and benign behavior. This would immediately solve a large number of problems in IT security. Unfortunately, there's no such thing.

The problem already becomes clear when you try to define “normal” behavior. You first talk about how a program output might deviate from the expected output. But in your Apache example, you suddenly consider all possible execution paths to be “normal” – this would include unexpected, faulty and even malicious behavior.

So obvious not every possible execution path is benign. If the program has vulnerabilities or bugs in general, then some input will lead to behavior which you consider unwanted. If you want a tool to distinguish between those two cases, then you need very specific criteria. There are several options.

  • You can let the program authors or package maintainers define what's “normal”. For example, many webservers already come with an SELinux policy which specifies exactly what the server should be allowed to do.
  • If the user of the webserver has a clear understanding what should and shouldn't happen, it's possible to write a policy by hand.
  • You could run the webserver in a staging environment (which should be as close to production as possible), perform all kinds of common tasks and record the program behavior. Note that you then have to review the results and decide what is and what isn't “normal”, because you may already have triggered unwanted behavior by accident.
  • You could try anomaly detection. For example, you could train a classifier with example behaviors and then have it have it predict whether an observed behavior is “normal”.

In any case, don't expect perfect results. Webservers are very complex applications which cannot fully be described with a few simple rules. There's always the risk of false negatives and false positives, i.e., you may miss malicious behavior, and you may incorrectly classify benign behavior as malicious.

2
  • Thanks for the input please take a look on the updated version of my question. It somehow narrows down in what sense I want to observe anomalies. I completely understand what you are saying about different requests and the complexity of an http server and you are absolutely correct. I keep your input so far, but if you have any ideas specifically on the updated version or/and maybe suggest a very simple/tiny http server (instead of more complex ones) I would very much appreciate it also. Commented May 19 at 20:20
  • @und3rd06012: Even after the edit, you don't seem to have a clear understanding of what exactly you want to trace (the webserver itself? a particular web application?), what a syscall is and what you can (and cannot) expect as a result. It might be a good idea to do some research on the basics and write down a clear concept before you discuss your ideas. Some of the questions also seem to be more about Linux basics than security, so maybe other Stack Exchange communities (like Unix & Linux) are more suitable.
    – Ja1024
    Commented May 19 at 21:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .