full-disclosure - Patch Integration Engine (PIE) alpha release

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: ben.hawkes at paradise.net.nz (Ben Hawkes)
Subject: Patch Integration Engine (PIE) alpha release

The Patch Integration Engine (PIE) is a system for the insertion of
patches into a runtime process, allowing for the immediate correction of
security vulnerabilities. This is an announcement of the public alpha
release of PIE, version 0.2, which currently supports i386 Linux.

PIE was created from a personal research interest, the potential uses
for runtime code insertion. The abstract goal of the project was to
offer a platform by which a vulnerable service may be patched without
any substantial downtime. For more information regarding the project
see:

http://pie.sourceforge.net/documentation.html

PIE 0.2 can be attained from:

http://prdownloads.sourceforge.net/pie/pie-0.2.tar.gz?download

Bugs can be reported at the PIE bug tracking system:

http://sourceforge.net/tracker/?atid=644382&group_id=106501&func=browse

I have to stress that this is an ALPHA release and should NOT be used on
a production server. In its current state PIE is primarily a research
interest in the sense that it does not fully solve the proposed problem,
but merely presents a possible solution.

The primary reason that PIE cannot claim to reach the goal mentioned
above is due to the unknown reliability of PIE itself. As I see it, the
common reason that a service remains unpatched is the risk that the
newly introduced changes will break some existing functionality. Just as
a patch needs to be tested before deployment, so too does a PIE
prepatch.

If there is sufficient interest, testing and feedback then it is likely
that the development of PIE should continue, with focus on the
following:

- Stronger function fingerprinting. At this stage the fingerprinting
  techniques used by PIE are not technically reliable. The first step in
  improving this is to give PIE "opcode awareness" and then the 
  integration of Halvar Flake's method of function signatures (or a 
  similar method).
- The development of prepatches for publicly released vulnerabilities.
- Extension of the prepatch development library.
- Alternative prepatch insertion methods.

A note should be given to OpenSSH and Sendmail which reload a process
image from disk when a HUP signal is delivered. In this situation PIE is
not necessary for the immediate patching of a vulnerability. I
personally found Sendmail's implementation of HUP reexecution to be
excessively flakey. Most other common internet services have no HUP
reexcution at all. 

I hope to get some of these ideas in to a FAQ in the recent future, but
for the moment it would be great to get some feedback on the list on
whether PIE might have a use beyond research experimentation.

-- 
Ben Hawkes
(fiver)