Preventing attacks on devices with multiple CPUs

Disclosed are systems and methods to utilize two different processing units (e.g., CPUs) to monitor each other. The processing units may have limited visibility and/or read only access to each other to reduce the possibility that one affected processing unit could compromise the second processing unit. Devices containing multiple processing units of different architectures could be configured so that one type of processing unit monitors another type of processing unit. When the processing units are different architectures a single piece of malicious software (malware) is unlikely to affect both processing units. Each processing unit can be configured to detect rootkits and other types of malware on the other processor(s) of the system/device.

TECHNICAL FIELD

This disclosure relates generally to a system and method for utilizing two distinct processing units to monitor each other and detect abnormalities which could indicate the other processing unit has been compromised. More particularly, but not by way of limitation, this disclosure relates to systems and methods to utilize processing units of different architectures and operating environments to monitor each other and detect viruses and other malicious software even if the infecting software includes stealth like mechanisms.

BACKGROUND

Contemporary mobile devices typically use two processing units. A first of the processing units can be used for communication (e.g., transmission/receiving, encoding/decoding, protocol support, etc.) while a second of the processing units can be used for user interface or application support (e.g., screen, keyboard, interfaces, Operating System, applications). Because there are two processing units a hacker could attempt to compromise either one.

Rootkits are a stealthy type of malicious software (malware) designed to hide the existence of certain processes or programs from normal methods of detection. Rootkits typically enable continued privileged access to the compromised system. Rootkit installation may be either automated or activated when an attacker obtains root or Administrator access. Obtaining this access is either a result of direct attack on a system (i.e., exploiting a known vulnerability) or by getting access to a password (either by cracking, privilege escalation, or social engineering). Once installed it is typically a goal of a rootkit to hide the intrusion as well as to maintain privileged access for itself (or other processes). Like any software, rootkits can have a good purpose or a malicious purpose. Full control over a system means that existing software can be modified, including software that might otherwise be used to detect or circumvent an attack.

Rootkit detection is difficult because a rootkit may be able to subvert the software that is intended to find it. Detection methods include using an alternative, trusted operating system; behavioral-based methods; signature scanning; difference scanning; and memory dump analysis. Removal can be complicated or practically impossible, especially in cases where the rootkit resides in the kernel; reinstallation of the operating system may be the only available solution to the problem. When dealing with firmware rootkits, removal may require hardware replacement, or specialized equipment.

Modern rootkits do not necessarily elevate access, but rather are used to make another software payload undetectable by adding stealth capabilities. Most rootkits are classified as malware, because the payloads they are bundled with are malicious. For example, a payload might covertly steal user passwords, credit card information, computing resources, or conduct other unauthorized activities. A small number of rootkits may be considered utility applications by their users: for example, a rootkit might cloak a CD-ROM-emulation driver, allowing video game users to defeat anti-piracy measures that require insertion of the original installation media into a physical optical drive to verify that the software was legitimately purchased.

Rootkits can run at different privilege levels (e.g., modes) of a computer environment. User-mode rootkits run at the same mode as most other user applications, rather than low-level system processes. They have a number of possible installation vectors to intercept and modify the standard behavior of application programming interfaces (APIs). Some inject a dynamically-linked library (such as a .DLL file, .dylib file, a .so file, or a .shlib file) into other processes, and are thereby able to execute inside any target process to spoof it; others with sufficient privileges simply overwrite the memory of a target application.

Kernel-mode rootkits run with the highest operating system privileges by adding code or replacing portions of the core operating system, including both the kernel and associated device drivers. Most operating systems support kernel-mode device drivers, which execute with the same privileges as the operating system itself. As such, many kernel-mode rootkits are developed as device drivers or loadable modules, such as loadable kernel modules or device drivers. This class of rootkit has unrestricted security access. Kernel rootkits can be especially difficult to detect and remove because they operate at the same security level as the operating system itself, and are thus able to intercept or subvert the most trusted operating system operations and thereby “hide” themselves in a stealth-like manner.

Because rootkits and other viruses (which include all types of malicious code: Trojan horses, exploits, shellcodes, keyloggers, backdoors, spyware, botnets, adware, information stealers, etc.) operate in the above described stealth-like manners (among others) they are difficult to detect and/or clean from within the scope of the infected operating environment. This disclosure addresses these and other issues to provide methods and systems to detect active rootkits and other viruses (i.e., malicious code) that attempt to conceal themselves from detection on the infected processing unit.

DETAILED DESCRIPTION

As explained above, rootkit detection from within an infected computing environment can be difficult to detect. This is mainly because once active a rootkit typically actively conceals itself from detection by intercepting attempts to detect it and returning manufactured results to the process attempting to perform the detection. Actions such as requesting a list of running processes, or a list of files in a directory, cannot be trusted to behave as expected. Prior art methods for operating-system-level rootkit detection typically require a user to shut down the computer suspected of infection, and then to check its storage by booting from an alternative trusted medium (e.g. a rescue CD-ROM or USB flash drive). The technique is effective because a rootkit cannot actively hide its presence if it is not running. However, this type of remedial action is not typically available for mobile devices (e.g., cell phones) and they typically require expensive repair up to and including returning to the factory for service. As explained further below, disclosed are techniques to address these and other problems by using systems and methods for monitoring a first processing unit from a second processing unit, where the access between the two processing units can be defined and the monitoring information can be updated in a secure manner.

Referring now toFIG. 1, infrastructure100is shown schematically. Infrastructure100contains computer networks102. Computer networks102include many different types of computer networks available today such as the Internet, a corporate network or a Local Area Network (LAN). Each of these networks can contain wired or wireless devices and operate using any number of network protocols (e.g., TCP/IP). Networks102are connected to gateways and routers (represented by108), end user computers106and computer servers104. Also shown in infrastructure100is cellular network103for use with cellular communication. As is known in the art, cellular networks support cell phones and many other types of devices (e.g., tablet computers not shown). Cellular devices in the infrastructure100are illustrated as cell phones110.

Referring now toFIG. 2, an example processing device200for use in providing disclosed detection techniques according to one embodiment is illustrated in block diagram form. Processing device200may serve as processor in a cellular phone110, gateway or router108, client computer106, or a server computer104. Example processing device200comprises a system unit210which may be optionally connected to an input device for system260(e.g., keyboard, mouse, touch screen, etc.) and display270. A program storage device (PSD)280(sometimes referred to as a hard disc, flash memory, or computer readable medium) is included with the system unit210. Also included with system unit210is a network interface240for communication via a network (either cellular or computer) with other computing and corporate infrastructure devices (not shown) or other cellular communication devices. Network interface240may be included within system unit210or be external to system unit210. In either case, system unit210will be communicatively coupled to network interface240. Program storage device280represents any form of non-volatile storage including, but not limited to, all forms of optical and magnetic memory, including solid-state, storage elements, including removable media, and may be included within system unit210or be external to system unit210. Program storage device280may be used for storage of software to control system unit210, data for use by the processing device200, or both.

System unit210may be programmed to perform methods in accordance with this disclosure. System unit210comprises one or more processing units (represented by PU1220and PU2225), input-output (I/O) bus250, memory230, and shared memory231. Memory access to memory230can be accomplished using the communication bus250. Shared memory231represents a shared memory or memory area that can be directly accessed by either processing unit. Processing units220and225may include any programmable controller device including, for example, a mainframe processor, a cellular phone processor, or one or more members of the Intel Atom®, Core®, Pentium® and Celeron® processor families from Intel Corporation and the Cortex and ARM processor families from ARM. (INTEL, INTEL ATOM, CORE, PENTIUM, and CELERON are registered trademarks of the Intel Corporation. CORTEX is a registered trademark of the ARM Limited Corporation. ARM is a registered trademark of the ARM Limited Company). Memory230may include one or more memory modules and comprise random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), programmable read-write memory, and solid-state memory. PUs220and225may also include some internal memory including, for example, cache memory or memory dedicated to a particular processing unit and isolated from other processing units for use in maintaining monitoring information for use with disclosed embodiments of rootkit detection.

Processing device200may have resident thereon any desired operating system. Embodiments of disclosed detection techniques may be implemented using any desired programming language, and may be implemented as one or more executable programs, which may link to external libraries of executable routines that may be supplied by the provider of the detection software/firmware, the provider of the operating system, or any other desired provider of suitable library routines. As used herein, the term “a computer system” can refer to a single computer or a plurality of computers working together to perform the function described as being performed on or by a computer system.

In preparation for performing disclosed embodiments on processing device200, program instructions to configure processing device200to perform disclosed embodiments may be provided stored on any type of non-transitory computer-readable media, or may be downloaded from a server104onto program storage device280. It is important to note that even though PUs (220and225) are shown on a single processing device200it is envisioned and may be desirable to have more than one processing device200in a device configured for rootkit detection according to disclosed embodiments. That is, PU220and225could monitor each other from within a single processing device200or processing units from different processing devices (e.g., multiple processing devices200) could monitor each other.

Referring now toFIG. 3, cellular phone300(an example of cellular devices110fromFIG. 1) is shown. Cellular phone300can be configured with one or more processing devices200and thus have a plurality of processing units (e.g.,220,225). Cellular phone300also has a user interface screen310, a user input mechanism320and an antenna330. Cellular phone300can also have multiple antennas for cellular, WiFi, radio frequency identification (RFID), near filed communication (NFC), etc. In modern cellular phones, user interface310and a communication interface (not shown) that communicates with a cellular network via antenna330can be controlled by different processing units or processing devices. Among other things, this enables a user of the cellular phone to interact with applications executing on the cellular phone while still engaged in a communication session via the cellular network. Additionally, different processing units can be configured into cellular phone300based on power consumption requirements and be configured to allow for extended battery life of cellular phone300when it is monitoring the cellular network but not actively being interacted with by a user. A cellular phone300with multiple (somewhat isolated) processing units provides a suitable environment to utilize the detection techniques disclosed herein.

Because modern cellular telephones (i.e., smartphones) typically have both a cellular network interface and a computer network interface they can be infected in many different ways. A phone (e.g.,300) could be infected via the cellular network by a process of impersonating a mobile mast to infect and exploit the communication processing unit. Once infected this type of attack may allow for a propagation of “worms” across phones leading to severe impact. Also, when a cellular phone connects to a computer network malicious code could be transferred to the phone in the context of a data download or an application download.

With the above explained details regarding rootkits, their detection issues, infrastructure details, and device configurations, we now turn to a discussion of various embodiments to provide improved rootkit detection techniques. As will be seen below, different processing units from within a single device (e.g., mobile phone300) can monitor each other and their monitoring will be unaffected by a rootkit infecting the processor being monitored. As will be understood by one of ordinary skill in the art, given this disclosure, the stealth-like detection avoidance mechanisms of the rootkit cannot affect or distort the monitoring being performed by an independent processing unit.

Referring now toFIG. 4, flow chart400illustrates a cross processing unit monitoring process according to one disclosed embodiment. In the following example the numbering of the CPUs is just an example for two processing units. Of course, any number of processing units with different numbering is also possible. Beginning at block405a first processing unit (PU10on a device such as cellular phone300is initialized (e.g., “boots”). Next, at block410, a second processing unit (PU2) on the device is initialized. Of course, each of the processing units can be initialized in parallel or sequentially depending on software or hardware design. At block415, PU2becomes affected (e.g., infected) with a rootkit, a stealth type virus (any type of malicious software). As these types of viruses and malware typically do the rootkit (or virus) conceals itself within the context of PU2and PU2's operating system (block420). At some later time (block425), PU1interrogates PU2and because PU1is not affected by the stealth like concealment capabilities the rootkit or virus is detected. After detection (block430) the user can be informed of the detection and an attempt to clean the environment of PU2can be attempted.

Referring now toFIG. 5, flow chart500illustrates an update process for the monitoring code or monitoring information required by one processing unit to monitor another. It is envisioned that at processing device manufacture time, a processing device could be built such that firmware based monitoring code (e.g., code to monitor a different type of processor) could be integrated with the processing device (block505). This could typically be done by putting the code in firmware of the device or other methods known to those of skill in the art of processor manufacture. Additionally, a “secure” memory area could be defined and dedicated to maintaining monitoring information about the operating environment of the other processing unit to be monitored by this processing unit. This information could include information about global interrupt table contents, specific memory address values, etc. The monitoring information would be specifically defined for the operating environment to be monitored (e.g., particular operating system and relevant device software version information). Because, operating systems and software are updated periodically via upgrades or patches, it may be desirable for an operating system (or device software) vendor to update the monitoring code and/or the monitoring information as shown in block510. The updated code and/or information can be made available on an update server and a communication link established between the update server and the device containing both the monitoring PU and the monitored PU (block515). After establishment of the communication link a secure update process can be performed as necessary (block520). As will be apparent, any update process to update the operating environment being monitored may have to be coordinated with the update process outlined in process500.

In different embodiments, the processing unit being monitored and the processing unit performing the monitoring may be of different architectures and run completely different environments. The minimum requirement is a suitable level of visibility into the monitored environment from the monitoring environment. In a configuration where both environments have similar operating conditions it may be important to isolate them sufficiently so as to not allow infection of both the monitored and monitoring environment at the same time. Obviously, if both environments are infected simultaneously a sophisticated rootkit or virus could attempt to actively conceal attempts at the cross monitor. It is also conceivable to have more than two PUs where one watches multiple others (and they can each watch each other) in a fashion similar to the presented embodiment of two PUs.

It is also to be understood that the above description is intended to be illustrative, and not restrictive. For example, above-described embodiments may be used in combination with each other and illustrative process steps may be performed in an order different than shown. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention therefore should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, terms “including” and “in which” are used as plain-English equivalents of the respective terms “comprising” and “wherein.”

The following examples pertain to further embodiments of this disclosure. Specifics in the examples may be used anywhere in one or more embodiments.