[cap-talk] Capabilities - the rub, another account

coderman coderman at gmail.com
Wed Nov 22 18:08:03 CST 2006

On 11/22/06, Marc Stiegler <marcs at skyhunter.com> wrote:
> ...
> "Considerable overhead", oh, lordy, yes. I'm sorry,  but this is a
> rationalization of a situation which is fundamentally broken. I have
> earlier told the story, for this specific thread, of how I one day
> learned that I had authority to edit the entire app-server for HP Labs.

i'll raise you this account from mid to late 90's time frame:

years ago i used to contract on oracle and other ERP integration
projects for manufacturing companies.  they needed to use hand held
wireless barcode scanners on the floor for inventory tracking and
shipping tied to the ERP system.

these systems used console based interfaces at the time (curses style)
or raw database API's.  in order to wrap the console interfaces into
our custom API's (for actions which had no database interface) the
application had to open a pseudo tty and "screen scrape" VT100 off a
character device talking to the ERP system.

obviously the ability to open and attach tty's needs root or system
privileges, so our program was setuid root upon installation.  (note
that none of our clients ever asked for or saw source code attesting
to the security of our setuid apps).

because all of the ERP systems supported the console interfaces as a
secondary / fail back method of interaction, these interfaces usually
required an account on the database and/or ERP host itself.

to top off the insanity, there was an undocumented command to launch
an arbitrary command from the setuid program binding pseudo-tty's,
rather than the usual text mode client.

the end result (which fortunately never played out or was exploited):

Un-authenticated, un-encrypted wireless (900 or 2.4FHSS pre-802.11)
devices connected to the private internal network with the
ERP/Database host granting root privileged shells without login.

all to screen scrape a console...

those installs really drove home the "weakest link" difficulties of
strong security.

More information about the cap-talk mailing list