Infomation Leak in Fileswitch

Currently Fileswitch does not erase freshly allocated file buffers, and a consequence will write the previous contents of memory to the end of buffered files. This may leak private information to where it may be read by a third party.

If writing to a disc using Filecore possibly secret junk will be written to the disc and can be read from the disc by bypassing the filing system. For example:

1. Load a secret file containing your password to www.riscosopen.org.
2. Erase and format a disc
3. Write some public information to the disc.
4. Distribute the disc to a stranger at a club meeting.
5. Attacker reads the disc and finds your password.
6. Attacker logs onto www.riscosopen.org and impersonates you.

If writing to a Linux NFS server using Sunfish (or occasionally using RPCEmu HostFS) the junk will be at end files as seen by the Linux filing system API, the junk will be removed from the file (but may remain on the disc) when and if the file is closed in RISC OS. If the files are publicly accessible, for example via a web server, a lucky attacker may be able to read your passwords.

To reproduce open, write to, and flush a file, but do not close a file:

H%=OPENOUT"X"
BPUT#H%,"TESTING"
SYS "OS_Args",255,H%

Then examine the file without using it’s handle (H%), junk will be in the file after the text “TESTING”. For Filecore it is necessary to reset the computer without shutting down for this demonstration.

Alas due to a bug in RPCEmu this bug does not reliably show, here is a workaround:

diff -ur rpcemu/src/hostfs.c rpcemu2/src/hostfs.c
--- rpcemu/src/hostfs.c	2016-02-08 14:07:57.000000000 +0000
+++ rpcemu2/src/hostfs.c	2016-09-16 21:29:14.369778218 +0100
@@ -955,6 +955,7 @@
   }

fwrite(buffer, 1, state→Reg3, f);
+  fflush(f);

 }
static void

My suggested fix is to erase the buffer upon allocation to the file, junk may be appended from other parts of file but your secrets are now safe:

From 4821d81d5e8b00c96e3ea5903beaa5bde7bca5ee Mon Sep 17 00:00:00 2001
From: Timothy E Baldwin <<a href="mailto:T.E.Baldwin99@members.leeds.ac.uk">T.E.Baldwin99@members.leeds.ac.uk</a>>
Date: Fri, 16 Sep 2016 17:31:54 +0100
Subject: Fileswitch: Erase freshly allocated file buffers.

If the buffers are not zeroed the previous contents of the memory
may get written to the file.

A spy may then read said memory contents by examining the disc,
or by reading the files before they are closed (or if the files
are never closed because RISC OS is uncleanly terminated).

diff --git a/castle/RiscOS/Sources/FileSys/FileSwitch/s/StreamBits b/castle/RiscOS/Sources/FileSys/FileSwitch/s/StreamBits
index 34f25f6b..a0c95fc8 100644
--- a/castle/RiscOS/Sources/FileSys/FileSwitch/s/StreamBits
+++ b/castle/RiscOS/Sources/FileSys/FileSwitch/s/StreamBits
@@ -353,7 +353,13 @@ AllocateBuffer Entry "r0, r2-r3"
         BL      ClaimBuffer             ; Go and get a buffer
         EXIT    VS
 
-        MOV     r14, #0                 ; Buffer contents not valid
+        MOV     r14, #0                 ; Erase buffer so that previous
+        ADD     r2, bufmask, #1         ; memory contents does not leak.
+        ADD     r3, bcb, #:INDEX:bcb_bufferdata
+01      STR     r14, [r3], #4
+        SUBS    r2, r2, #4
+        BNE     %BT01
+                                        ; Buffer contents not valid
         STRB    r14, bcb_status         ; or modified (by definition)
 
         MOV     r14, #-1                ; Buffer is not in the file

ClaimBuffer will more than likely be using OS_Heap (possibly via OS_Module 6), in which case the “leak” is in the heap manager. I don’t believe it clears allocated memory which was probably done for speed. I’m sure this has been raised previously, although can’t find the thread.

If a secure OS is now a thing then OS_Module 6 should probably clean any claimed area before passing it back. OS_Heap probably doesn’t need to clean as the app using it can decide if allocations need cleaning.

Another option is to clean deallocated blocks, as it may not be so time sensitive. Generally a block is freed as the final stage, as opposed to allocation which is done as an early stage.