Multiple realPlayer ActiveX controls fail to properly handle properties, which can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system. The risk is MEDIUM. By convincing a user to view a specially crafted HTML document (e.g., a web page or an HTML email message or attachment), an attacker may be able to execute arbitrary code with the privileges of the user.
VILEGET(1) User Contributed Perl Documentation VILEGET(1)NAME
vileget - Pass file edit requests to a Vile editor running Vileserv.
SYNOPSIS
vileget [-n] [-d] [-w] [-s socket-path] [-c command] [-C command] [file ...]
DESCRIPTION
Vileget can be used to load files into an already running instance of Vile or XVile. The editor should have already loaded and started the
Vileserv perl module. (See the Vileserv documentation for more detail.)
By default, if vileget cannot connect to a running instance of the editor it tries to start a new one. This will only work correctly if
you have configured Vile to start Vileserv automatically. (Vileget will try to find an XVile binary first, then look for a Vile binary.)
Vileget looks for the Vileserv socket in the user's home directory ($HOME/.vilesock) by default. This can be changed by setting the
VILESOCK environment variable, or by using the -s option.
If vileget is handed a directory name, it trys to get the target Vile to load the directory.pm module and popup the appropriate directory
listing. This only works for the first directory mentioned on the command line, and it only works if the target Vile is configured to
accept remote commands (see the -c/-C options).
COMMAND-LINE OPTIONS-d With this option, vileget will change the current working directory of the running Vile to be the directory in which vileget is being
run, in addition to loading any requested files.
-n This tells vileget NOT to try starting a new instance of Vile if necessary. If vileget cannot connect to a running Vile, it will just
die with a connection error instead.
-w Vileget waits for given file(s) to be written by Vile before exiting.
-s socket-path
Tells vileget to use the socket given by socket-path. This overrides the default and the environment variable VILESOCK.
-c command
-C command
The -c and -C options can be used to pass arbitrary Vile commands to a running instance of Vile. These can be used at the same time
that file edits are being requested, or without giving any files at all. When file arguments are used, the -c option can be used to
execute a Vile command before the requested files are loaded. The -C option is used to execute a Vile command after the requested
files are loaded. If no file arguments are given, then -c and -C are basically the same, except that -c has precedence. These
options are non-repeatable, so you can only execute two Vile commands per invocation of vileget. Of course, there are always
procedures...
You can have a lot of mindless fun with these two options. For example, you can popup and close the buffer list by repeatedly
executing:
vileget -c '*'
As a nod towards security, command execution is disabled by default in Vileserv. To enable it, you can use
setv %vileserv-accept-commands true
in your .vilerc file. Note that running something like
vileget -c 'setv %vileserv-accept-commands false'
can be used to disable remote commands dynamically. Naturally, this is considered to be both a security violation *and* a feature...
Passing arbitrary commands to Vile may well produce arbitrary results. The author assumes no liability for edit sessions that have
collapsed into singularities, or, as a matter of fact, for anything else.
SEE ALSO vileserv(3), vile(1)AUTHOR
J. Chris Coppick, 1998 (last updated: July 26, 2000)
perl v5.14.2 2012-06-03 VILEGET(1)