Executing stdin/stdout

[oscoder]

Hi there!
I've been wondering recently if, since unix treats everything as a file, it would be possible to execute stdin or stdout. I cannot, however, think how do it! Would it be possible? If so how?

OScoder

[AJ]

I don't know if it's possible, but I would have a look at the normal process creation system calls. As process creation may involve some amount of lazy loading and new stdout/in creation for the new process, it may cause problems - but why not try it in the same way you would execute anything else? It may be that the streams are protected as non-code areas (no execute bit and so on) or that there are general checks to prevent this.

Out of interest, what virus are you trying to inject?

Cheers,
Adam

[Brendan]

Hi,

I've been wondering recently if, since unix treats everything as a file, it would be possible to execute stdin or stdout. I cannot, however, think how do it! Would it be possible? If so how?

STDIN and STDOUT aren't files - they're pipes.

A pipe isn't a file either - it doesn't have a size (and there may not be an "end of file"), you can't "seek()", you can't "mmap()", you can't use POSIX asynchronous file I/O functions, and you'll never find a pipe in the file system anywhere.

For Unix, "everything is a hack that's pretending to be slightly similar to a file if/when it's convenient"....


Cheers,

Brendan

[JamesM]

Hi,

Hi,

I've been wondering recently if, since unix treats everything as a file, it would be possible to execute stdin or stdout. I cannot, however, think how do it! Would it be possible? If so how?

STDIN and STDOUT aren't files - they're pipes.

A pipe isn't a file either - it doesn't have a size (and there may not be an "end of file"), you can't "seek()", you can't "mmap()", you can't use POSIX asynchronous file I/O functions, and you'll never find a pipe in the file system anywhere.

For Unix, "everything is a hack that's pretending to be slightly similar to a file if/when it's convenient"....


Cheers,

Brendan

Sorry Brendan, but I'll have to disagree with you there!

STDIN and STDOUT are pipes, correct. A pipe isn't a file - correct. They are, however represented in the filesystem. Depending which UNIX OS you're using, unnamed pipes can be either invisible in the filesystem or in the filesystem using a driver called "pipefs" - I believe that linux uses this method, however I may be wrong.

In UNIX, any filesystem object can be one of several things - a regular file, a character device, block device, pipe, socket or symbolic link. Named pipes exist and are used heavily - I believe the command/C function "mknod" creates them although it could be "mkpipe" - Can't check at the moment as I'm not on a UNIX box.

Finally, you can use POSIX asynchronous reads and writes on a pipe. See O_NONBLOCK in the POSIX specification for the open() function, and note the special case it makes for how to deal with FIFOs in nonblocking mode.

To the OP: stdin and stdout are usually piped to the process that spawned yours - i.e. the shell. You must therefore use the shell to store and execute those streams. The easiest solution is if you know in which language the code your'e spewing out is written in. If it's a scripting language, like Perl, you can usually run the output through the script interpreter for that language manually, instructing the interpreter to read from STDIN:

Code: Select all

./runMyProg | perl -

If you're outputting a binary file however, and wish to run it as a native executable, you must store it and then add the "executable" permission like so:

Code: Select all

./runMyProg >/tmp/$$; chmod +x /tmp/$$; /tmp/$$

I hope this answers your question.

Cheers,

James

[DeletedAccount]

For Unix, "everything is a hack that's pretending to be slightly similar to a file if/when it's convenient"....

Yes thats the idea , everything is abstracted into a file . But i really am not sure whether STDIN and STDOUT "physically" exists . For example in my OS , STDIN and STDOUT are defined as macros and input is buffered and sent to whichever device needed depending upon the parameters . Does STDIN and STDOUT really exist as physicall files ??? My os is crappy os anyways .

Regards
Sherk

[JamesM]

For Unix, "everything is a hack that's pretending to be slightly similar to a file if/when it's convenient"....

Yes thats the idea , everything is abstracted into a file . But i really am not sure whether STDIN and STDOUT "physically" exists . For example in my OS , STDIN and STDOUT are defined as macros and input is buffered and sent to whichever device needed depending upon the parameters . Does STDIN and STDOUT really exist as physicall files ??? My os is crappy os anyways .

Regards
Sherk

STDIN is file descriptor zero. STDOUT is file descriptor 1. STDERR is file descriptor 2. This is how they are defined. What those file descriptors point to, be it a named/unnamed pipe, socket, file or character/block device is decided initially by the parent process (when it sets up the child's environment - if not explicitly changed this defaults to a clone of the parent's environment) and then by the process itself (any process can close and dup2 stdin/stdout/stderr to change where it points to.)

James

[Owen]

On Linux you can find the pipes under /proc/*pid*/fd/*process file descriptor number*

[Solar]

...you could, of course, simply reopen() stdin to point to a file, and then execute that file through "normal" means...

In any case, stdin has to terminate (EOF) before you start executing, as otherwise there's no telling if the code might jump to a portion of code you haven't received yet... and then what?

[oscoder]

Thanks for your responses so far!

On Linux you can find the pipes under /proc/*pid*/fd/*process file descriptor number*

Any idea if theres something similar on OpenBSD

STDIN is file descriptor zero. STDOUT is file descriptor 1. STDERR is file descriptor 2. This is how they are defined. What those file descriptors point to, be it a named/unnamed pipe, socket, file or character/block device is decided initially by the parent process (when it sets up the child's environment - if not explicitly changed this defaults to a clone of the parent's environment) and then by the process itself (any process can close and dup2 stdin/stdout/stderr to change where it points to.)

I see. Is there a system call to form a process from a file descriptor? When I looked, it seemed there were only ones that used the file name.

Thanks again,
OScoder

[JamesM]

Is there a system call to form a process from a file descriptor?

I don't understand - it appears you have your concepts totally mixed up. Describe the problem and we will give you the optimal solution.

[Combuster]

or at least, try to

[Solar]

I see. Is there a system call to form a process from a file descriptor?

I didn't think so, but browsed the man pages nevertheless... actually, there is one - fexecve().

[JamesM]

I see. Is there a system call to form a process from a file descriptor?

I didn't think so, but browsed the man pages nevertheless... actually, there is one - fexecve().

I don't think that fexecve is quite what the OP is looking for - it seems to take a file descriptor and use that to work out the name of the file to execute, whereas the OP seems to want to execute the stream as a sequence of bytes.

[DeletedAccount]

Hi,
I think there is a round about way to do this , I guess . I might be thinking crazy however ...

1) Overflow a buffer

2) overwrite the return address with a value you know

3) put the contents of the stream in the return adress .

Tired after work around 2:00 am . . Correct me if am wrong or my comments are stupid .I am a stupid guy

Regards
Shrek