Caught in passing -- "trojaned" mp3 file targeted at SuSE
This is kind of along the lines of, "I never thought I'd see the day when..." but it seems some sick wacko out there has stepped over the line and made a dangerous data file -- from the symantec site: http://securityresponse.symantec.com/avcenter/venc/data/trojan.linux.jbellz.... basic synopsis: there is an MP3 file floating about with an intentionally malformed header field; this causes /specific/ versions of mpg123 to "do bad things", namely, deletes the files in the user's home directory (~) and subdirectories. Obviously, it won't kill your system, but it'll still be a PITA... Since SuSE 8.0 is on the "specific versions targeted" list, I'm surprised I hadn't seen note of it [on the plus side, however, I rarely play christmas music in January, mp3 or otherwise] Also, I use XMMS for most of my mp3 playing [or konquerer's built in player, which I think is noatun?] This was listed AND fixed in one day [gotta love that whole "open" source bit... ;) ] but it is still a sad day to realize that a linux multimedia program can be considered in the same class as windows-media-player-7 (8? 9? could you take over version 6?) when it comes to "vulnerabilities" [yes, I know that is a bit harsh, but I'm calling it as I see it.] OTOH, this is no different than any other "buffer overrun" error -- anytime you allow "data" to overwrite "code" you're in for a world of hurt... [that's part of the reason I've liked working on a particular mainframe I've been associated with for the last 15-20 years -- "code" and "data" are identified by seperate registers, it is functionally impossible to allow a "buffer overrun" to write to "code" memory]
The 03.01.16 at 23:59, Tom Emerson wrote:
OTOH, this is no different than any other "buffer overrun" error -- anytime you allow "data" to overwrite "code" you're in for a world of hurt... [that's part of the reason I've liked working on a particular mainframe I've been associated with for the last 15-20 years -- "code" and "data" are identified by seperate registers, it is functionally impossible to allow a "buffer overrun" to write to "code" memory]
If I'm not mistaken, intel 386 processors and up do have that kind of protection available, by marking the code segment as read only. I think that faults of this kind caused many programs in windows to be stopped by the system, with an error like segment violation, or something similar. Perhaps somebody else can expand on this, and how it is handled in linux? -- Cheers, Carlos Robinson
"Carlos E. R."
If I'm not mistaken, intel 386 processors and up do have that kind of protection available, by marking the code segment as read only. I think that faults of this kind caused many programs in windows to be stopped by the system, with an error like segment violation, or something similar.
While the i286 and later do have this protection but you also have to make the stack non-executable, but it is almost never used (the only OS I have seen which uses it was Digital Research Concurrent DOS/CPM for 80286.) Most current operating systems, including Windows and Linux, run the processor in 'flat' memory mode rather than segmented mode. Which means that areas of memory only have page-level protection not segment level.
On Sun, 19 Jan 2003 09:53:49 +0000
Graham Murray
"Carlos E. R."
writes: If I'm not mistaken, intel 386 processors and up do have that kind of protection available, by marking the code segment as read only. I think that faults of this kind caused many programs in windows to be stopped by the system, with an error like segment violation, or something similar.
While the i286 and later do have this protection but you also have to make the stack non-executable, but it is almost never used (the only OS I have seen which uses it was Digital Research Concurrent DOS/CPM for 80286.) Most current operating systems, including Windows and Linux, run the processor in 'flat' memory mode rather than segmented mode. Which means that areas of memory only have page-level protection not segment level.
Off the top of my head, I think the grsecurity kernel patch has an option to allow you to make the stack non-executable. BUT it breaks alot of programs, notably X. The grsecurity system does allow you to specifically exempt certain programs though. -- use Perl; #powerful programmable prestidigitation
The 03.01.19 at 07:52, zentara wrote:
Off the top of my head, I think the grsecurity kernel patch has an option to allow you to make the stack non-executable. BUT it breaks alot of programs, notably X. The grsecurity system does allow you to specifically exempt certain programs though.
Now that makes me wonder... why would the stack need to be executable? It should only be needed for local data and return address for subroutines, and things lke that, no? Or does somebody uses hacks like selfmodifying code? -- Cheers, Carlos Robinson
On Sunday 19 January 2003 6:24 pm, Carlos E. R. wrote:
The 03.01.19 at 07:52, zentara wrote:
... grsecurity kernel patch ... make the stack non-executable. BUT it breaks alot of programs, notably X. ...
Now that makes me wonder... why would the stack need to be executable? It should only be needed for local data and return address for subroutines, and things lke that, no? Or does somebody uses hacks like selfmodifying code?
hence the point of my original comment on program vs. data segmentation -- "self modifying code" has never [in my book at least], been "good", and with the advent of virii, I've downgraded such actions as "very bad indeed" [OTOH, I do recall once making a text editor macro for a mini/mainframe that essentially worked as a mail-merge operation in which the only way to practically create it was to make it self modifying, but that doesn't really count :) :) :) ] My point is that DATA should never be considered EXECUTABLE CODE -- if that simple restriction were built into various OS's [and/or Unix in particular], then an entire segment of "buffer overrun" cracks would never exist to be reported in the various security/bug tracking reports. [OTOH, "buffer overruns" might cause a program to do something unexpected, like build, purge, or just plain access the wrong file, but you couldn't "execute arbitrary code" because of such an attack] Tom minor point: "return addresses for subroutines" -- you'd have to be very clever indeed to modify a "return address" so that a different function gets called to "do the dirty work" you intend "as a trojan" and yet still appear to "function normally" so far as the end-user is concerned -- most likely any such attempt would make the program simply abort, which would raise suspicion...
The 03.01.20 at 01:11, Tom Emerson wrote:
Now that makes me wonder... why would the stack need to be executable? It should only be needed for local data and return address for subroutines, and things lke that, no? Or does somebody uses hacks like selfmodifying code?
hence the point of my original comment on program vs. data segmentation -- "self modifying code" has never [in my book at least], been "good", and with the advent of virii, I've downgraded such actions as "very bad indeed"
Exactly.
minor point: "return addresses for subroutines" -- you'd have to be very clever indeed to modify a "return address" so that a different function gets called to "do the dirty work" you intend "as a trojan" and yet still appear to "function normally" so far as the end-user is concerned -- most likely any such attempt would make the program simply abort, which would raise suspicion...
Not really... If I could write arbitrary data to the stack, I would have to replace the return address with mine, and save the old one somewhere, so as to repair the stack to an apparent pristine state before returning. But that's theory, and I don't know much about linux programming. -- Cheers, Carlos Robinson
On Mon, 20 Jan 2003 03:24:45 +0100 (CET)
"Carlos E. R."
The 03.01.19 at 07:52, zentara wrote:
Off the top of my head, I think the grsecurity kernel patch has an option to allow you to make the stack non-executable. BUT it breaks alot of programs, notably X. The grsecurity system does allow you to specifically exempt certain programs though.
Now that makes me wonder... why would the stack need to be executable? It should only be needed for local data and return address for subroutines, and things lke that, no? Or does somebody uses hacks like selfmodifying code?
Here is the "help" from the grsecurity patch menuconfig section. CONFIG_GRKERNSEC_PAX_NOEXEC: By design the IA-32 architecture does not allow for protecting memory pages against execution, i.e. if a page is readable (such as the stack or heap) it is also executable. There is a well known exploit technique that makes use of this fact and a common programming mistake where an attacker can introduce executable code of his choice somewhere in the attacked program's memory (typically the stack or the heap) and then execute it. If the attacked program was running with different (typically higher) privileges than that of the attacker, then he can elevate his own privilege level (e.g. get a root shell, write to files for which he does not have write access to, etc). There are two implementations provided here, each with its own impact on performance and usability. You should enable at least one of them to enforce the non-executable flag on memory pages thereby making it harder to execute 'foreign' code in a program. This will also break programs that rely on the old behaviour and expect that dynamically allocated memory via the malloc() family of functions is executable (which it is not). Notable examples are the XFree86 4.x server, the java runtime and wine. NOTE: you can use the 'chpax' utility to enable/disable this feature on a per file basis. chpax is available at http://pageexec.virtualave.net -- use Perl; #powerful programmable prestidigitation
The 03.01.20 at 07:42, zentara wrote:
Here is the "help" from the grsecurity patch menuconfig section.
I'll save this to my "interesting" folder :-) As for using it... well, not for home; perhaps for a fulltime firewall. Unless it become part of the kernel, and all programs adapt to it... -- Cheers, Carlos Robinson
On Mon, 20 Jan 2003 21:18:26 +0100 (CET)
"Carlos E. R."
The 03.01.20 at 07:42, zentara wrote:
Here is the "help" from the grsecurity patch menuconfig section.
I'll save this to my "interesting" folder :-) As for using it... well, not for home; perhaps for a fulltime firewall. Unless it become part of the kernel, and all programs adapt to it...
Well the grsecurity patch is a whole collection of useful patches to tighten-up your system. The "executable pages" patch is just one of them. It is still worth looking at even for a home system, it includes things like "randomized pids", "trampoline protection", and various proc and socket restrictions, which are useful if you have other users working from the console. You can limit users from opening sockets, etc. I don't know if it applies cleanly to suse kernel sources though, probably not. ;-( http://grsecurity.net It's been around awhile, and is scrutinized by alot of people. -- use Perl; #powerful programmable prestidigitation
participants (4)
-
Carlos E. R.
-
Graham Murray
-
Tom Emerson
-
zentara