The Trouble With Live Data
live data, n. 1. Data that is written to be interpreted and takes over program flow when triggered by some un-obvious operation, such as viewing it. One use of such hacks is to break security. For example, some smart terminals have commands that allow one to download strings to program keys; this can be used to write live data that, when listed to the terminal, infects it with a security-breaking virus that is triggered the next time a hapless user strikes that key. For another, there are some well-known bugs in vi that allow certain texts to send arbitrary commands back to the machine when they are simply viewed. 2. In C code, data that includes pointers to function hooks (executable code). 3. An object, such as a trampoline, that is constructed on the fly by a program and intended to be executed as code. --From the Jargon file, version 3.2.0
The link seemed innocent enough. All it said was:
Crusty the Clown fans should click here!!!
Perhaps I was a bit naive—or just stupid. But I clicked on the damned link. The actual transfer didn't take very long, and pageview (Sun's PostScript viewer) quickly brought up a picture of Crusty the Clown (from The Simpsons). The first inkling of any trouble was that my disk drive light came on. And stayed on. That almost never happens, especially without me doing something. I pulled up another xterm. Something was really funny; my tcsh configuration was all wrong...
My drive light went off. My home directory was gone.
Some fancy footwork with my sysadmin got my home directory back (fortunately it had been backed up the night before). Since the catastrophe happened early in the morning, nothing except the previous evening's e-mail was lost.
I was damned lucky.
All that had happened was that someone had embedded a command line in the PostScript image. The PostScript viewer I was using happily executed the command and 200 megabytes of my files were simply erased.
As the Internet becomes more and more sophisticated, rich and complex schemes of data interpretation become more common. Each of these schemes is a potential security hole. Conventional security mechanisms are less than effective at dealing with these problems.
The breadth of use of live data makes finding an effective solution quite hard. Users are demanding the newer, richer Internet services and site administrators cannot delay adding such services for very long. The widespread deployment of web browsers and MIME e-mail involves fairly substantial security risks which have many unintended consequences.
The (true) nightmare story introducing this article is a good example. Most PostScript viewers have a secure mode which disables the file writing and program-launching operations that are part of the PostScript language. However, my local configuration did not use the secure mode and I got burned by someone's idea of humor. Problems with embedded PostScript are well-known, however. Other tools which (at first) seem innocuous may also have potential problems.
The infamous Internet Worm of 1987 used a simple buffer-overrun bug in the finger daemon to compromise security on a great many computers. Historically, a great many C programs have had similar flaws—maybe not as dangerous to security as the finger bug, but often quite catastrophic in their own right.
Consider the current state-of-the-art in web browsers. The vast majority of the web browsers currently on the market share a common ancestry with NCSA's Mosaic. Given the intense market pressures to bring web clients to market in today's Internet feeding frenzy and greased-pig-catching contest, it seems unlikely that extreme care has been taken in ensuring that web browsers securely interpret HTML. Buffer overflow problems (which seem particularly likely in anchors) could give unscrupulous individuals a way to execute any arbitrary code sequence on target machines.
This problem is only getting worse. The Java language is currently exploding through the Internet world, and it seems likely that there will be a great many surprises associated with Java. Even though Java is intended to provide security mechanisms to prevent abuse, all it takes is one flaw to cause a major problem.
Another example of live data (which few people have considered) is the local variables list in Emacs. This is a highly convenient feature, as it allows per-file customization for the Emacs editor. For example, programmers can code their bracing and indentation preferences into the file, so other emacs users who edited the file are automatically able to follow those same bracing conventions. However, since many of the local “variables” are typically Emacs Lisp functions, there could be a substantial risk associated with merely viewing a file in Emacs—the same risks associated with viewing PostScript files with an unsafe viewer.
The Emacs problem is fairly manageable. If you set the variable enable-local-variables to nil, this feature of Emacs is disabled.
It seems that the biggest risks are associated with the most complex services. MIME e-mail provides a mechanism for launching viewer programs based on the contents of the e-mail. So, if you send a JPEG picture, a JPEG viewer will be launched. Thus, a very large (and rapidly expanding) set of programs can be involved—too many to ensure reasonable security. Some MIME configurations even allow the transmission and execution of shell scripts or Perl programs.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- Interview with Patrick Volkerding
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide