4 ms·

> why allow file() to open sockets If by "open sockets" you mean open existing sockets in read-only mode, it's so that it can identify them as sockets. If by "

by raldi 12y ago

> why allow file() to open sockets If by "open sockets" you mean open existing sockets in read-only mode, it's so that it can identify them as sockets. If by "open sockets" you mean create new sockets, I don't think it does do that: https://github.com/threatstack/libmagic/search?utf8=%E2%9C%93&q=socket https://github.com/threatstack/libmagic/search?utf8=%E2%9C%9... > write to arbitrary files It appears it only does this if running on OS/2 and investigating what's inside a compressed file. Under these conditions, a temporary file is necessary for platform-specific reasons: https://github.com/threatstack/libmagic/blob/3dea7072b8d7e927e6f9b1ef381a70271376f322/src/file.h#L466 https://github.com/threatstack/libmagic/blob/3dea7072b8d7e92... https://github.com/threatstack/libmagic/blob/3dea7072b8d7e927e6f9b1ef381a70271376f322/src/apptype.c#L68 https://github.com/threatstack/libmagic/blob/3dea7072b8d7e92... It also writes to a non-arbitrary mmapped file (the magic database), because that's how such databases work; you query them by writing to them in a particular way: https://github.com/threatstack/libmagic/blob/3dea7072b8d7e927e6f9b1ef381a70271376f322/src/apprentice.c#L2782 https://github.com/threatstack/libmagic/blob/3dea7072b8d7e92... > run external programs I can't find any examples where it does that. Do you know of any?

IvyMike 12y ago
"It may be possible for such an attacker to execute arbitrary code with the privileges of the user running file(1)." This is what I am saying...given the right input, file(1) could do anything and everything. Yes, it's only due to a bug in file(1), but still that's kind of ridiculous. We have all sorts of things in place to protect against other bugs (for example, segmentation faults), and there's 27 years of evidence that we need some more help.
- bandrami 12y ago
  Yes, it's only due to a bug in file(1), but still that's kind of ridiculous I point again to: http://en.wikipedia.org/wiki/Halting_problem http://en.wikipedia.org/wiki/Halting_problem If you are reading in from a file, and you make decisions that are complex enough to be S- and K- combinators (or a concept of "if" and "jump", or some other minimal set), then you have given an attacker a Turing machine.
  - IvyMike 12y ago
    I agree. But what I'm saying is that the Turing machine should not be connected to a gun. And being hooked up to an idle gun should not be the default for every program.

by raldi 12y ago

IvyMike 12y ago

"It may be possible for such an attacker to execute arbitrary code with the privileges of the user running file(1)." This is what I am saying...given the right input, file(1) could do anything and everything. Yes, it's only due to a bug in file(1), but still that's kind of ridiculous. We have all sorts of things in place to protect against other bugs (for example, segmentation faults), and there's 27 years of evidence that we need some more help.

bandrami 12y ago
Yes, it's only due to a bug in file(1), but still that's kind of ridiculous I point again to: http://en.wikipedia.org/wiki/Halting_problem http://en.wikipedia.org/wiki/Halting_problem If you are reading in from a file, and you make decisions that are complex enough to be S- and K- combinators (or a concept of "if" and "jump", or some other minimal set), then you have given an attacker a Turing machine.
- IvyMike 12y ago
  I agree. But what I'm saying is that the Turing machine should not be connected to a gun. And being hooked up to an idle gun should not be the default for every program.