Off-topic (was: Update: MAJOR SECURITY RISK (Re: RSWUWFML - with attachment t o la unch user's SAP inbox))

Thu Nov 27 01:23:18 EST 2003

> Don't try this at home.  hee hee hee hee ;-)

I believe the link could become a manifesto for the latest wave of disregard
to Microsoft in this list :-)

> If someone does try it, please keep the list informed so we can all laugh.

I am afraid this will come with a delay, as the person will not be ready to
do so immediately :-)

Have a jolly good day,
Tomasz

-----Ursprungliche Nachricht-----
Von: Soady, Phil [mailto:phil.soady at sap.com]
Gesendet: Donnerstag, 27. November 2003 01:48
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: Re: Update: MAJOR SECURITY RISK (Re: RSWUWFML - with attachment
t o la unch user's SAP inbox)

Don't try this at home.  hee hee hee hee ;-)
Sound advise.
If someone does try it, please keep the list informed so we can all laugh.

On a more serious note.
I still missed the jump from shortcut to URL file://cmd.exe

Why are we doing file://cmd.exe ?

I still don't understand why attachments don't work ?
I also don't believe there is a justification for including user id and
Password.

Can someone explain that to me ?

regards
Phil Soady
Senior Consultant - Business Technologies
Professional Services
SAP Australia
Level 1, 168 Walker Street, North Sydney 2060, Australia.
M   +61 412 213 079
E   phil.soady at sap.com

-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of
Zmudzin,Tomasz,FRANKFURT,Extern LG-DM
Sent: Wednesday, November 26, 2003 1:28 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Update: MAJOR SECURITY RISK (Re: RSWUWFML - with attachment to la
unch user's SAP inbox)

I were so shocked by what I've seen that I've misread the print. The
analysis would thus be slightly different. However this still is a security
threat.

The details:
1. The file:// prefix instead of the usual CGI http://..../cgi-bin prefix
would actually mean that the command interpreter file is transferred to the
user's client machine before being executed. In other words -- the command
would be executed ON THE CLIENT MACHINE, NOT ON THE SERVER -- which is less
of a threat, but still dangerous.

2. The web browsers usually request that file:// requests be confirmed by
the users who can either save or execute the file.
-- Saving it won't help perform any operation, and is misleading to the user
-- Executing the file will take where you need to go -- but opens the gate
to shell-level execution of system commands
-- The worst thing that can happen is that the bored user will tell the
browser to ALWAYS open .exe files by default (which is quite likely without
the technical background). This is a serious security threat as it will also
work for external sites, which may (and will) contain malicious programs.

3. This approach also makes command shell available to the users -- which
may conflict with your company's policy anyway (think about Citrix access --
Windows terminals often have cmd.exe disabled)

4. On very legal terms -- I'm not quite sure if it is legal to distribute a
part of Windows (cmd.exe) via the Web from the web server to other PCs!
Judging by the copyright disclaimer -- not really.

Best regards,
Tomasz

-----Ursprungliche Nachricht-----
Von: Zmudzin,Tomasz,FRANKFURT,Extern LG-DM
Gesendet: Dienstag, 25. November 2003 15:07
An: 'SAP Workflow Users' Group'
Betreff: MAJOR SECURITY RISK (Re: RSWUWFML - with attachment to launch
user's SAP inbox)
Wichtigkeit: Hoch

Dear all,

please note that the solution below requires that CMD.EXE (the command
interpreter) be available from within the URL. However this is a MAJOR
security flaw (a textbook one!!) that should be avoided at all costs.

If you allow

   file:///cmd.exe "c:\...\sapshcut.exe"

there's no meaningful way of disabling

   file:///cmd.exe del c:\winnt\system\... -- DON'T TRY THIS AT HOME!!!

so in fact ANY user with access to your webserver can execute ANY command on
it -- something definitely not to be recommended. Don't do this.  If you
really need something similar, wrap your call in a specialized CGI script
that will be made available to the users. But NEVER EVER make the command
interpreter available this way.

Best regards,
Tomasz

-----Ursprungliche Nachricht-----
Von: Workflow99 at aol.com [mailto:Workflow99 at aol.com]
Gesendet: Dienstag, 25. November 2003 14:54
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: Re: RSWUWFML - with attachment to launch user's SAP inbox

Nichloas,

Try making the URL exactly what you pasted into the DOS prompt. (Remove the
file:///cmd.exe and the quotes)

Regards,
Ramki Maley
Workflow Developer, USCBP.
248-613-1287 (C)

In a message dated 11/25/2003 8:02:22 AM Eastern Standard Time,
nicholas.n.brand at uk.ibm.com writes: Hello,

A quick question on the email notification program.

We're using SAP v4.7.

Here's what we want to happen:

Users get notified by email when they have new workitems - the email has an
attachment or URL that when executed launches SAP, after logging on the user
is taken directly to his Business Workplace.

We've copied RSWUWFML and made some additions to it.
We can send an email with a url to the user's MSOutlook address. The URL
looks like this: <file:///cmd.exe "c:\Program
Files\SAP\FrontEnd\sapgui\SAP\FrontEnd\sapgui\sapshcut.exe" -user=nberkland
-language=en -system=SRD -client=140 -sysname=R/3 DEV -command=SO01>

The <> enclosing the URL means MSOutlook interprets the whole string as a
URL.

If we click the URL from MSOutlook we get the message 'Cannot find
file...followed by the parameter list'

This URL does not work; yet if we paste part of it into a DOS prompt it does
work - i.e. "c:\Program
Files\SAP\FrontEnd\sapgui\SAP\FrontEnd\sapgui\sapshcut.exe"
-user=nberkland -language=en -system=SRD -client=140 -sysname=R/3 DEV
-command=SO01

Our ABAP developer assumed the <file:///cmd.exe command was an http command
to execute a file.

So, the question is how can we launch the same program (the SAPGUI
shortcut) from a URL, including passing the necessary parameters (e.g.
userid) from MSOutlook.

Can anyone provide the missing link? Hmmm

Kind regards,
Nicholas Brand