Browse Prior Art Database

Heuristic Application Run Time Signature

IP.com Disclosure Number: IPCOM000031372D
Original Publication Date: 2004-Sep-22
Included in the Prior Art Database: 2004-Sep-22
Document File: 2 page(s) / 33K

Publishing Venue

IBM

Abstract

The current state of the art of CPU enabled Buffer Overflow protection, used by computer chip manufacturers, is to set a no execution bit on the stack/heap segment. This causes an exception error whenever this segment is accessed for execution. The prohibiting factor in this technology is that Java* and C- compiled programs often place code in this segment for legitimate execution. Thus, this technology has met with limited acceptance.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Heuristic Application Run Time Signature

The obvious work around for this limitation is to have a configuration option, which enables this segment protection on a per program basis. Even with this work around, it is still not possible to protect a large class of programs; e.g. Java* and C-compiled programs.

The idea of Heuristic Application Run Time Signature (HARTS), is to record the running of a program and its' use of valid stack execution in a known save environment. This heuristic profile is then set with the production run of the program. If stack execution occurs during the production run of the program and it matches one of the valid heuristic profile instances of stack execution for this program, then execution is permitted. Otherwise, it is outside of the programs HARTS profile, and the execution handler throws a sig-bus error causing a coredump.

There are two phases in the HARTS technology:
1. Heuristic profile of stack segment execution policy creation and
2. Production run time enforcement policy.

A heuristic profile is created for a program that may legitimately execute code on the stack. In this mode the program is run in a known save environment and a Recording Exception Handler (REH). The REH is registered as the exception handler callout program in the case of stack segment execution. The REH does not terminate the running of the program but instead records the execution call path at the instant of the stack execution. In AIX*, the kernel calls used by REP would be getcaller(), getcaller1(), and getcaller2. With this set of getcaller() functions, the procedures which legitimately execute on the stack can be recorded in the heuristic profile.

It is envisioned t...