WordPerfect security flaws documentation

[hackerb9]

I understand that it is not a priority for this project, but it would be helpful if there was a list of the security flaws to be aware of in WordPerfect. As I recall, it was designed for a single-user computer and did not have any thought to security. For example, https://insecure.org/sploits/wordperfect7.fileperms.html mentions files being created in /tmp with permissions 666.

Also, if there is any advice on hardening an install of WordPerfect, I'd appreciate it. For example, has anybody had experience using running it confined by AppArmor / firejail? Are there pre-made profiles? I presume networking can be disabled, but what capabilities does WordPerfect actually require to run?

[taviso]

Hah, yes, I think that report is correct - although there's an easy workaround, you can do export TMPDIR=~/.wptmp or something to use a non-shared tmp directory. I suppose I could fix this, I have patching infrastructure in place, and could rewrite it safely. I'll look into it!

I don't have an AppArmor profile, however the only untrusted data it parses is if you open an untrusted document - writing and managing your own documents should be fine. I think networking isn't necessary, but printing does use UNIX domain sockets for IPC.

[taviso]

Incidentally, that advisory is a fun find, interesting history!

[hackerb9]

Thanks. It'd be great if you fix that issue. As you probably have already noticed, TMPDIR works, but wp will still use /tmp/wpc-`hostname` if the directory doesn't exist.

export TMPDIR=~/.wprc/tmpdir
mkdir -p $TMPDIR
chmod 700 $TMPDIR

I tried running wp in firejail since that's the easiest and it immediately failed. Apparently, I can't have both 64-bit and 32-bit firejail installed at the same time. Instead, I created a user account ("wpjail") just for running wp and am satisfied that it is secure enough for my needs. I use it with su - wpjail -c wp.

By the way, if you do create a security/flaws document, you may want to mention a few other things I noticed:

• File locking is correctly handled when multiple instances of wp try to open the same document. (Nice!)
• The mysterious wpexc process that persists after quitting (and even logging out) is related to printing.
  • It appears to be an optimization WordPerfect intentionally added, not a bug.
  • I believe wpexec was supposed to be a daemon, but whoever wrote it may not have been well versed in Unix.
  • The first user to print creates a directory /tmp/wpc-`hostname` which contains the socket for the wpexc process running as that user.
  • All users can write to the socket.
  • If that first user kills the process, then the next user will run it, but still using the first user's directory and socket.
  • I can only presume that the reason behind this is that on DOS there is no lpr/lpd.
  • Starting up a new daemon each time is surprisingly slow.
  • The fix is to use a per-user TMPDIR in a non-shared directory, however it will fill up with junk files.
• In addition to the normal settings saved in ~/.wprc/, WordPerfect leaves fewmets in the tmp directory that are mostly harmless: /tmp/junk*, /tmp/_wp*, and of course the aforementioned /tmp/wpc-`hostname`. On most UNIX boxes, /tmp is cleared on reboot, so these wouldn't normally be a problem.
• Setting TMPDIR does not fix all WordPerfect programs as some are still hardcoded to write to /tmp, as can be seen with grep -L TMPDIR $(rgrep -l /tmp).
  • the shell scripts embedded in wpdest write to /tmp/.WPXX_tmp*. I believe that program is intended to be run by root, so this could lead to privilege escalation.
  • wpinstc does ypcat hosts > /tmp/tmphosts; chmod 666 /tmp/tmphosts. It is unclear how that could be a security issue.
  • wpped and wpmergec are shell scripts which could be fixed to use TMPDIR.
• It is easy to corrupt WordPerfect's memory in at least one place: it presumes an 80x24 minimum screen, but only checks that that is the case at startup. It does not handle SIGWINCH which would have let it detect a window size change.
• The suspicious looking hidden files in the distribution appear to be remnants of the install process, not Trojan horses. (See /opt/wp80/shbin10/install.wp.)
  • /opt/wp80/wpgraphics/.junk
  • /opt/wp80/wpmacros/.junk
  • /opt/wp80/shlib10/.def.lang
  • /opt/wp80/shlib10/.wp8.lm
  • /opt/wp80/wpexpdocs/.junk
  • /opt/wp80/wplib/.wpbuildc
  • /opt/wp80/wplib/.def.lang
  • /opt/wp80/wplib/.wpbuildx
  • /opt/wp80/wplib/.wp8c.set

(Whoops, that list went way longer than I thought it would. Sorry.)

[taviso]

There were some notes about how printing works in the wiki, it's here https://github.com/taviso/wpunix/wiki/Hacking#printing

I'll think about moving things to per-user tmp directories, I'm not sure if there are any features that will break yet (not that I think anyone is using multi-user features 😂).

Maybe the .junk files are a bug, they're in the shipping manifest (i.e. Corel intended for it them to be included), but there were other bugs I had to fix, so that doesn't mean very much!

The .lm files are related to flexlm, the licensing system. This was really only for the graphical version, because the character version works fine in demonstration mode.

The .set files are default settings, and the .def.lang is (you guessed it) the default interface language name. Not sure how complete the other languages are though, some strings don't seem translated - but they might not be important.