SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Intel Corporation (INTC) -- Ignore unavailable to you. Want to Upgrade?


To: StockMan who wrote (40138)11/12/1997 12:51:00 PM
From: Fridrik Skulason  Read Replies (1) | Respond to of 186894
 
Re fork/malloc bombs and other ways to crash OSes

>These are not easy to come by. The fork/malloc scenario has undergone >extensive usage.

fork/malloc is well known and anybody with a C compiler and reasonable knowledge of the OS can make such a program in a few minutes. Now, some operating systems have proper resource usage monitoring, but Linux is not one of them, and crashing it in this way is trivial.

>One possible software workaround may be to detect invalid opcodes F0, >in compilers/assemblers.

Sorry, but that won't work - it would be easy to get around that with
self-modifying code.



To: StockMan who wrote (40138)11/12/1997 12:59:00 PM
From: Fridrik Skulason  Respond to of 186894
 
Actually, I thought of something else, regarding malicious code, and unlike the F0 bug, it is a *real* threat.

Imagine two trojans: One contains the F0 code. The user runs it...CRASH! He will not run it again.

The other one contains code that changes one bit at random, somewhere in the FLASH BIOS of the system (or better yet - in the processor's microcode). Neat, huh ? All of a sudden various programs on the system will start crashing in mysterious ways.....