OAMP Update: Secure OpenBSD, Apache, MySQL and PHP

I got tired of essentially re-writing the same article over and over again, yet it seems with each release of OpenBSD and each OAMP install I do, things get just a little more refined. So I present to you a living document on its own page here at HiR Information Report. It's been written so that it is not specific to a distinct architecture or version of OpenBSD, so long as the proper packages exist on the OpenBSD mirror sites. This has been updated and tested on OpenBSD 4.8 and the recently-released OpenBSD 4.9, i386 architecture only.

Secure OpenBSD, Chroot Apache, MySQL and Suhosin Hardened PHP Installation Guide

Why I'm coming home to OpenBSD

Although those who know me will tell you I love OpenBSD, I'm generally an operating system agnostic. I enjoy tinkering with OSes, and always have. There have been a few I tried and couldn't enjoy for the life of me (Mac OS versions prior to OS X, PalmOS, HP-UX and plan9 among them) but since 1997, OpenBSD has always felt like home to me, and I've long been a little bit of a fan.

Not long ago, my primary computer was a 13" MacBook that was bought for me by one of my consulting customers in late 2006, and prior to that, I was using OpenBSD on a crappy old Dell desktop and OS X on a G3 PowerBook. OS X is just unixy enough to geek out on. I could get most BSD-type stuff to compile. My MacBook also ran Windows 7 pretty well. I got switched on to it when my wife upgraded to 7 from Vista. It also ran OpenBSD, Backtrack and Ubuntu in VirtualBox like a champ.

When the MacBook started showing its age about 6 months ago, I went to a Toshiba NB305 netbook. It came with Windows 7 Starter edition, which really isn't much of an operating system at all. It's basically a kernel meant to launch Internet Explorer. Not amused. I didn't feel like paying to "unlock" Windows Home Premium.

Figuring that the hardware and all of the funky function keys would probably work best under Ubuntu, I went that route. Webcam aside (I never use it anyway) the hardware worked pretty well. I had to wait around for patches to get the screen brightness keys to work. Power management was always funky right after getting unplugged. Otherwise, Ubuntu worked pretty well for me. I set it up to dual-boot alongside Windows 7 Starter, just so I could use my radio programming software.

3 months ago, Ubuntu managed to corrupt the partition table on the hard drive. Recovery involved spending 4 hours restoring Windows 7 starter edition from the factory media and re-installing Ubuntu. A few days ago, the same thing happened. A co-worker has had similar trouble lately, as well.

There are a bunch of distros out there -- probably too many. Netbook-specific distributions are hot stuff. Frogman's on a Crunchbang kick. More than one person tried to tell me to go to Gentoo, Debian, Arch or some other flavor of Linux. I've used them before. Every few years, Linux has to piss me off, I suppose.

Faced with the prospect of a half-day wasted getting my netbook back to the way I thought I liked it, I decided to see what OpenBSD offered, since I haven't run it on the desktop outside of a VM in several years. The install is always quick, so if anything, it wouldn't be too much of a waste of my time.

As expected, Xorg didn't need any configuring to determine and use my display to its maximum potential. X has come a long way since the late 1990s. I was worried about things like power management (suspend, resume), hardware drivers, support for WPA2 and of course the function keys for display brightness, volume and the like, since they gave me a bit of trouble on Ubuntu.

You know what, though? Everything worked right out of the box. I had to enable apmd in /etc/rc.conf to get suspend to work, but that was it. I also found a pretty neat trick to get most flash videos to play in Firefox, with only open source tools and not actually using anything from Adobe. Youtube, vimeo, blip and even Badgers all work great. Let's face it, life would suck if you couldn't watch Lolcats, Badgers and Mythbusters.

It's way too soon to tell if OpenBSD will be any more reliable than Ubuntu in the long run, but I feel much more at home for the time being.

Moar useful OpenBSD resources I ran across this week:

OpenBSDsupport: OpenBSD Desktop For Windows Users

Using WPA on OpenBSD

That reminds me, I'm behind schedule on my OAMP guide for OpenBSD 4.9, but I'm pretty sure the existing instructions haven't changed, save for version numbers.

Using Severe Weather WX Alert on Yaesu Handhelds

I have a Yaesu VX-7R and VX-2, both of which are great handheld radios. Deep in the menu system, each one has a "WX Alert" option. It's item 20 in the VX-7R's menu, and the VX-2's menu items are in alphabetical order, so look for "WX ALT" there. After enabling this option, my radios still failed to alert me when the National Weather Service issued alerts via their NOAA Weather Radio system.  What gives? The manuals that came with my radios are very vague about how to use this feature, and Googling around, it seems like a lot of people have the same problem.

The trick is that you have to be scanning!

On the VX-7R, you have to be scanning the weather band for this to work. If you scan the weather band with WX Alert enabled, it will silently pause on any NOAA Weather Radio stations it finds, listening for the alert tone without breaking squelch. If it finds one, it will stop, open the squelch and play the weather alert. I recommend using the SUB band for this. Here's how you do it.

* Press [F] then [0] to enter the menu, and scroll to item 20. Enable WX Alert by pressing the [MAIN] or [SUB] buttons, then momentarily press PTT to exit the menu.
* If you have only the MAIN tuner up, press and hold the [MAIN] or [SUB] button to see the dual tuners. Momentarily press [SUB] to select the SUB tuner.
* Press [F] then [3] to move the SUB tuner to the WX band.
* Press [F] then [1] to start scanning the WX band for weather alerts.
* Press [MAIN] to start controlling the MAIN tuner, and use the radio as normal.

On the VX-2:
* Press and hold the H/L button to enter the menu, scroll to "WX ALT"
* Press H/L momentarily, then use the VFO knob to enable it.
* Press PTT Momentarily to save the setting.
* Press [F] followed by the [WIRES] button in the bottom left corner to enter special memory mode
* If needed, press [BAND] repeatedly until the weather band shows up.
* Press and hold the [BAND] key to scan the weather band.

The VX-2 will silently pause on any NOAA Weather Radio stations it finds, listening for the alert tone without breaking squelch. If it finds one, it will stop, open the squelch and play the weather alert. I also found that if this option is enabled on the VX-2 and you're scanning other memory frequencies, the radio will occasionally jump over to the weather band and listen for the alert tone. You should probably have the WX band tuned to the frequency of the nearest weather radio transmitter, because I don't think it scans the whole weather band, only the station that was last used in the WX Special memory mode.

Of course, not all Yaesu radios have these features, and these steps may not work exactly the same for all Yaesu radios that support WX Alert.

The Real Insider Threat

Today, I saw this interesting piece on insider threats posted to CERT, and was somewhat baffled. I stewed on it a bit, but a Google Reader comment by Carnal0wnage spun up my rant engine. Here, people are actually being urged to spy on their peers then name them and shame then, as if it's totally normal to put bear traps in the server room and roll your own ECHELON, lynching in the commons anyone who dares to raise the ire of the great and awesome security team. They titled their session "What's working to stop these attacks?" It's us versus them.

When I was still a student, years before my real career in information security would take hold, it was commonplace to hear that some unfathomable percent of attacks are from malicious insiders. Maybe it was true in the 1990s. After years of leaving corporate workstations and academic lab computers hanging out on the Internet with public IP addresses and no firewalls, administrators were finally getting a clue, NATting workstations and putting up chintzy first-generation port-blocking firewalls. Students and curious employees were suddenly the ones with unrestricted access to internal systems protected -- if you wish to call it that -- by these prototypical security systems. Maybe this logic made sense back then.

Be that as it may, I've seen more data loss from people bypassing draconian security policy than I've seen data loss from the rare disgruntled trade-secret packrat with one hand in the cookie jar and one foot out the door. That's not to say these things don't happen. They do! But they're not the typical modern insider threat.

At my last job, I would occasionally have the option to work remotely for server maintenance, or instead drive 15 miles to the office at 11:00 PM on a Saturday night, and stay there until 4:00 AM Sunday morning. Working from home meant this:

• Firing up some proprietary piece of VPN software that only ran on Windows.
• Using a 2-factor authentication token to get into the VPN.
• Using RDP to access a "secure" sandbox server, which was pretty much the only thing the VPN would let you access remotely. This required the use of the 2-factor token again, but you had to wait to make sure you didn't use the same one-time key twice in a row.
• Using RDP from that server to get to my desktop, which also ran Windows.
• SSHing from my workstation to a central administration server that was dual-homed and could actually access the servers I needed to work on.
• Performing the work on the servers.

Let's say, I usually drove to the office. How much do you want to bet that people in high-level positions were taking sensitive information home with them on external drives instead of trying to navigate that rat-maze of security on a daily basis? What about the CFO that always uses an aircard for his laptop -- even at the office -- mixing business with casual recreational web surfing just because he can't get to the things he "needs" ever since that [expletive] proxy started getting in his way.

That's how data gets lost, and there's your real insider threat.

While security sometimes impacts usability, it doesn't always have to. It's certainly not a linear scale. I could provide dozens of examples where making something harder to use causes people to make poor security decisions, but they're mostly cliché. Security is hard, and the human element of it is the most nuanced and unpredictable part.

Don't force security rhetoric down peoples' throats and try to pass it off as "awareness training." Work with people. Figure out what they want, and work to deliver solutions that provide an adequate level of risk protection while impacting usability as little as possible. Automate or document the hard parts for them. Explain things to them in terms that they can understand. I'd bet your job description called for excellent written and verbal communication skills. Put them to good use!

While threat management and network monitoring are always part of a complete information security breakfast, trusting and empowering your co-workers while providing them with education that meets them where they are will probably go a lot further toward minimizing the insider threat than playing Big Brother ever will.

OpenVAS & Greenbone Security Assistant Basics

This is the second part of a series on OpenVAS, the open-source vulnerability scanner. In my last post, I walked you through compiling the various pieces of OpenVAS and getting it up and running. Now it's time to talk about the fundamentals. For this and future posts, we'll be using the web front-end to OpenVAS, called Greenbone Security Assistant, and we'll assume it's running on your local machine.

Why bother with OpenVAS, or vulnerability scanning in general?

Vulnerability scanners are not "hacking tools!" They're very noisy. They're ungainly. They lack finesse. They're riddled with false positives (vulnerabilities you try to manually verify and turn out to be non-existent) and false negatives (vulnerabilities that it doesn't know about or can't be easily detected and are thus missed). With so many weaknesses, why would you even bother?

Simply put, running frequent vulnerability scans on your network gives you a good baseline complete with the ability to notice a change from one week to the next. At the very least, you get a good feel for the "low-hanging fruit" -- the obvious and easy targets on your network. Additionally, many vulnerability scanners including OpenVAS have the ability to use a scanner agent installed on systems, and login credentials to inspect the local security of your servers, workstations and infrastructure. In this way, you can identify software that's out of date and security settings that are out of compliance. This can be a huge asset to your IT security stance once you have the scanner configured properly and running smoothly. That's easier said than done, unfortunately.

If you'll be using this system as a vulnerability scanner regularly, I recommend a few things:

Make sure the openvas services start at boot. I just added this stuff to /etc/rc.local on Ubuntu server:

echo "Starting OpenVAS Scanner Daemon..."

/usr/local/sbin/openvassd && echo [ OK ]

echo "Starting OpenVAS Manager Daemon..."

/usr/local/sbin/openvasmd && echo [ OK ]

echo "Starting OpenVAS Administrator Daemon..."

/usr/local/sbin/openvasad && echo [ OK ]

echo "Starting Greenbone Security Assistant Web Interface..."

/usr/local/sbin/gsad --http-only && echo [ OK ]

echo "Downloading NVT Updates..."

/usr/local/sbin/openvas-nvt-sync && echo [ OK ]

Make sure you have nightly NVT Updates. I put this in root's crontab to run at 4:00AM each day:

0 4 * * * /usr/local/sbin/openvas-nvt-sync

And there you have it.

When you navigate to the web interface (usually http://localhost) and log in, you'll see the task screen, which I had shown you previously. Take note of the options on the left pane, as we'll be going through most of them.

One of the first things you'll want to do if you didn't set up daily updates is to hit the "NVT Feed" link (not shown above) and update the NVT database.

With that out of the way, our first stop is with scan configurations. OpenVAS comes with five template configurations, each of which might do something useful for you.

You don't need to create a custom scan config to get started with OpenVAS, but If you decide to create a new Scan Config, you'll have the ability to edit it (the wrench will not be greyed out)


and you'll be faced with a huge assortment of scanning options allowing you to fine-tune your scan. You'll also see options for so-called NASL Wrappers, which are scripts that help OpenVAS utilize third-party tools such as nmap, nikto, w3af and others. Tuning your scan parameters is important, but complicated enough that it's beyond the scope of this series. Most vulnerability scanners I've used (Nessus, ISS, etc...) have a configuration section like this, and it's always a very, very deep rabbit-hole. Mastering this is a bit of an art, but I usually break the enterprise up into "classes" so that like-systems are scanned with relevant checks so I'm not throwing 5,000 futile Windows checks at the Linux servers in the DMZ, for example. Feel free to leave me a comment if you want me to discuss this kind of classification setup in more detail.

When building custom configs, I recommend using the existing scan configs as a template, and tweaking things from there to get your bearings. Try the "Full and very deep" scan first if you have any doubts. It's unlikely to knock anything off the network, but be careful! The "Trend" radio button selects whether this scan config will grow and import new NVT plugins or remain static with only the plugins you selected for that particular plugin family. If you start using OpenVAS frequently, you'll probably want to become familiar with tuning scan configs to get rid of false positives or enable more features.

Schedules are triggers for one-time or recurring scans. It's not uncommon to schedule a network vulnerability scan to happen after business hours, so this option helps you there. I usually run weekly scans so that I can compare my security stance from one week to the next. Here, I've created a weekly trigger that runs at midnight (central time) every Tuesday. You can create as many schedules as you want, but none of them will actually do anything until you assign the schedule to a task. By the way, OpenVAS uses UTC for its clock. Keep that in mind.

In the introduction, I had mentioned using credentials or agents to run local security checks. OpenVAS is pretty flexible here, so experiment with the credential options. Create credentials in Greenbone Security Assistant, and make sure that they match an account on the target system. I recommend creating a dedicated account with the bare minimum privileges needed to run the local security checks. In a Windows environment, consider using an active directory service account on the domain. Authenticated scans and local checks open up some of the most powerful features of many vulnerability scanners. I may cover the use of Agents later, but for now, they're beyond the "basics" scope of this post.

Escalator is a funny word for this feature, but this robust option gives you the ability to trigger events based on the completion of a scan. Here, I'm just configuring it to send an email to me when a scan has finished running. Note: you will probably have to install the "mailutils" package or some equivalent on Ubuntu for this to work.

We can finally start picking what hosts or networks we want to scan with the "Targets" option. The target hosts can be single IP addresses, IP address ranges (192.168.0.1-192.168.0.23 or 192.168.0.1-23), CIDR networks like the example below, DNS names, or any combination of them separated by commas. I had mentioned setting up "classes" of scans earlier. Here, you may just insert a comma-separated list of similar servers, for example. The comment is optional, and the port range can also be a comma-separated list of individual port numbers or ranges. "default" uses all of the ports found in /usr/local/share/openvas/openvas-services, which contains over 8,000 ports, a far cry from 65,535. YMMV here. If you wish to use credentials, select them now.

The moment you've probably been waiting for. Create a new task. This is where you'll get to put it all together and start scanning! Here, I assigned a weekly scan schedule. This will run on its own, using the schedule I defined earlier.

If you don't define a scan schedule, you'll end up with an item on the task list, but it won't run on its own until you hit the "Play" icon (Green triangle). I added a manual scan to the task list as well. You can see both the scheduled and manual scans waiting to run here:

Clicking the spyglass icon on a task will show you a list of summaries from each time you've run the task. This weekly scan has only run one time, though, so you only see one summary here.

And clicking the spyglass on a scan summary pulls up the detailed results, which you can filter a number of ways. This page goes on and on, containing every item that was noted in the scan. You can also export the results a number of ways.

One thing that I like about OpenVAS is the fact that the web UI allows you to make remarks about the scan findings, assign arbitrary severity levels (including "false positive") and tune things so that future scans can take your professional opinion into account, if you so desire. You can perform these overrides or add notes to a single instance of a vulnerability or make sure that it applies to other hosts in the same scan. This can make OpenVAS extremely versatile.

Anyway, that's the basics of the OpenVAS scanner and Greenbone Security Assistant. Should be enough to get you started playing around in your own lab environments, or perhaps in a small office environment.

If you get serious about using OpenVAS, you may consider going with the Greenbone's Professional NVT Feed, which operates on a similar model to Tenable Security's Nessus ProfessionalFeed. Again, it's hard to compare OpenVAS and Nessus side by side, but they both try to fill the same niche. I've used both (and several other competing products) and I still can't say any one is actually better than another. The Greenbone Security Assistant Web UI seems like one of the best vulnerability scanner interfaces I've seen, though.

OpenVAS on Ubuntu 10.10 Maverick Meerkat Install Notes

When Tenable took Nessus through a code re-write and closed its source, the old code was forked a few times. As far as I can tell, OpenVAS is the strongest surviving variant. There's a really old version in most Linux distributions' package repositories, but it's out of date, the 2.x version.

I wanted to get the new version up and running. It turns out that compiling it for the first time was a gigantic clustercoitus of library dependencies and unnecessary branches in the OpenVAS subversion repository. So, I did what I usually do when I meet a challenge worth dissecting: I set up a VM, take some snapshots, and document it.

There are four components to OpenVAS: The scanner, administrator and managers, and then a client program. There are three clients to choose from:

• Greenbone Security Desktop, which looks a lot like the older Nessus GUI
• Greenbone Security Assistant, a clean web UI similar to the new Nessus, except more feature rich
• OpenVAS-cli, a tool that's good for lightweight scheduled scanning

There are well over 100 dependencies to get OpenVAS installed, but this big pile knocked them all out on both Ubuntu 10.10 server and desktop versions:

sudo apt-get install build-essential libpcap-dev subversion cmake libgpgme11-dev libglib2.0-dev uuid-dev doxygen libgnutls-dev libmicrohttpd-dev bison xmltoman libsqlite3-dev sqlfairy libxslt-dev texlive-latex-extra xsltproc

One last thing: If you really want to use the Greenbone Security Desktop GUI, there's a whole lot more you'll need, but they're all dependencies of libq4-dev. I have grown to really like the Web GUI, so you may want to play with that first before you decide to go with GSD.

sudo apt-get install libqt4-dev

If you pull up the SVN repository, you'll see the following branches. You do not need all of them, and some of them are absolutely massive. It's a big waste of bandwidth, drive space and time to check out everything.

# bindings/
# doc/
# gsa/
# gsd/
# image-packages/
# openvas-administrator/
# openvas-cli/
# openvas-client/
# openvas-compendium/
# openvas-libraries/
# openvas-manager/
# openvas-packaging/
# openvas-plugins/
# openvas-scanner/
# sladinstaller/
# tools/
# winslad/

We only want openvas-libraries, openvas-scanner, openvas-manager, openvas-administrator, openvas-cli, gsa and gsd. When you first run subversion, you'll have to accept the SSL certificate from OpenVAS.

mkdir openvas-source

cd openvas-source

svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-libraries openvas-libraries

svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-scanner openvas-scanner

svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-manager openvas-manager

svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-administrator openvas-administrator

svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-cli openvas-cli

svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/gsa gsa

svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/gsd gsd

OpenVAS uses cmake, which is actually pretty slick as long as your dependencies are in order. Simply go into each of the directories above, and run the following commands to compile and install. I'll use openvas-libraries as an example:

cd openvas-libraries

cmake .

make

sudo make install

cd ..

One thing to keep in mind is that several libraries are deployed with the openvas-libraries package, and those are needed for the other packages. Make sure you run ldconfig to update the library cache before compiling the other packages.

sudo ldconfig

Do the same for openvas-scanner, openvas-manager, openvas-administrator, openvas-cli, gsa and (if you want to use the native gui), gsd.

Once everything is installed, you need to do a few quick things to set everything up. First, start the OpenVAS Scanner Daemon:

sudo openvassd

update the plugins. This takes a long time the first time you run it.

sudo openvas-nvt-sync

Create a CA (walk through the prompts):

sudo openvas-mkcert 

Create a client certificate for OpenVAS Manager (om):

sudo openvas-mkcert-client -n om -i

Rebuild the OpenVAS Manager database, then start OpenVAS Manager

sudo openvasmd --rebuild

sudo openvasmd

Start OpenVAS Administrator, then create an administrator account for yourself:

sudo openvasmd

sudo openvasad -c 'add_user' -n Admin (or other desired username) - It will prompt you for details.

Launch a client tool. I noticed that on Ubuntu, libmicrohttpd (a library the web UI uses) had some issues with SSL. I'm generally averse to running over plain HTTP, but if you make sure you run it locally or through a tunnel, you should be fine. I had to start Greenbone Security Assistant in http-only mode:

sudo gsad --http-only

Point your browser at http://localhost/ - It looks like this, if you have everything working properly. Here, I'm in the middle of a test scan.

Alternatively, you can run GSD:

gsd

Which looks a bit like this. You use the tabs to navigate it, export reports and all that.

I had trouble getting either GSD or GSA to export the report in PDF format. There may be a library or CLI tool that I'm missing. The HTML export works like a champ.

Update: Poking through the errors I found in /tmp, I discovered that I needed some files provided by LaTeX. Installing texlive-latex-extra and its dependencies got PDF export working, thus I've included it in the list of packages to install with apt-get at the beginning of this post.

In summary, OpenVAS works, and it's come a long way since the original fork of Nessus. It's difficult (and honestly, pointless) to compare OpenVAS to Nessus in their current states. They're not the same, and they likely have different strengths. I've spent quite a bit of time working with the latest versions of Nessus, so OpenVAS is new territory for me. Now that I have it up and running, I look forward to putting it through the paces.

I'll be talking about OpenVAS more in the coming days (or weeks, if things stay as busy as they have been lately). There are some interesting aspects of OpenVAS' architecture I'm playing with.

Building 2D Movie Glasses

3D movies have gained ridiculous ubiquity in the theater lately. Some movies tend to use the effect to a more pleasant degree than others, but I think most of us can agree that many movies don't need to be released in 3D. Some people get headaches or feel distracted by the over-use and exaggeration of the stereoscopic effects of these movies.

If you've watched a 3D movie, You've probably taken your glasses off in the middle, only to see a double-vision mess caused by being able to perceive both video channels at the same time with both eyes. Watching a movie this way is likely even more frustrating than enduring the side-effects of 3D.

Obviously, I'd suggest not seeing movies in 3D if you are prone to these side-effects, but perhaps your group of friends just HAS to see this movie in 3D, or maybe your schedule makes it more convenient to see a 3D showing. Here, I'll show you how to take two normal pairs of disposable RealD glasses and hack them so that your eyes only see one of the two video channels, effectively stripping the 3D effect from the big screen. The sad part: you still have to wear the stupid glasses.

There are several families of 3D video. RealD(tm) is currently the most commonly deployed 3D cinematic technology, and it uses something called circular polarization. Some of you might be familiar with polarized lenses used in sunglasses and camera filters. Those are usually linear polarizers. Linear polarizers are also used on LCD screens and have a number of other commercial applications. It would be possible to show movies with the left and right channels polarized linearly at right angles to one other, but this would force moviegoers to hold their head in such a way so that the lenses remained perfectly level, or else video brightness and channel separation would fall to pieces, although brightness always suffers a little when using polarized lenses.

Circular polarization works similarly, but the light is polarized in a helical fashion. This is a much more complicated process that solves several of the problems with linear polarization. One channel is polarized in a clockwise helix while the other channel is polarized counter-clockwise, allowing the lenses to filter out the other channel without being constrained the way linear polarizing lenses would as I mentioned above. The easiest ways to demonstrate this are to look through a pair of these disposable goggles and into a mirror, or look at one pair of 3D glasses through another pair. Apologies in advance for using crappy camera phone pictures for this. It's all I had on hand.





You would think all we have to do is take one of the lenses out and flip it over, so that both lenses only show the clockwise or counter-clockwise channel. I thought so too, but there seems to be more at play than I suspected and that won't work. Edit: each lens contains two filters bonded together, a polarizer and a "quarter wave plate", and flipping one lens over puts these filters in the improper order.

You'll have to tear into two pairs of 3D glasses, but the good news is that you can make two pair of 2D glasses out of them and give one to a friend. In a pinch, you could probably do all of this right there in the theater with nothing more than a simple Classic Swiss Army Knife. I'd recommend making these ahead of time, though.

If done correctly, this will get rid of most of the artifacts of stereoscopic cinematography, and hopefully relieve any side effects you might suffer.

RealD frames are snapped together in two pieces. With a small screwdriver, knife or other prying device, you can separate the inner part of the frame. We just need the lower part of one side of the frame to come apart far enough to slip the lens out.


Slide the lens out of the frame, being careful to not scrape it up.


Perform the two above steps on the opposite lens of the second pair of glasses.

Using scissors, trim the thin lens material so that you can fit each lens into the "wrong" side of the other frame. Don't trim so much that it's prone to fall out of the frame, but trim enough that it won't bend or crease when you put it back into the frame.


Carefully slide the lens into the other frame, being sure it slides into the thin slot snugly. Remember, we're taking the left lens of one frame and putting it into the right side of another frame, and/or vise versa. You don't really need to put the second frame together if you only need one set of 2D glasses.


Snap the frames back together, then wipe the lenses clean, as they're sure to have fingerprints all over them.


If you did it right, you should see that the movie looks the same through both eyes, and that looking at yourself in the mirror shows both dark lenses through both eyes, instead of just the lens you're looking through being dark.