[Infowarrior] - How the Web makes creating software vulnerabilities easier

[Richard Forno]

The Chilling Effect

http://www.csoonline.com/read/010107/fea_vuln_pf.html

How the Web makes creating software vulnerabilities easier, disclosing them
more difficult and discovering them possibly illegal.
By Scott Berinato

Last February at Purdue University, a student taking "cs390s‹Secure
Computing" told his professor, Dr. Pascal Meunier, that a Web application he
used for his physics class seemed to contain a serious vulnerability that
made the app highly insecure. Such a discovery didn't surprise Meunier.
"It's a secure computing class; naturally students want to discover
vulnerabilities."

They probably want to impress their prof, too, who's a fixture in the
vulnerability discovery and disclosure world. Dr. Meunier has created
software that interfaces with vulnerability databases. He created ReAssure,
a kind of vulnerability playground, a safe computing space to test exploits
and perform what Meunier calls "logically destructive experiments." He sits
on the board of editors for the Common Vulnerabilities and Exposures (CVE)
service, the definitive dictionary of all confirmed software bugs. And he
has managed the Vulnerabilities Database and Incident Response Database
projects at Purdue's Center for Education and Research in Information and
Assurance, or Cerias, an acronym pronounced like the adjective that means
"no joke."

When the undergraduate approached Meunier, the professor sensed an
educational opportunity and didn't hesitate to get involved. "We wanted to
be good citizens and help prevent the exploit from being used," he says. In
the context of vulnerable software, it would be the last time Meunier
decided to be a good citizen. Meunier notified the authors of the physics
department application that one of his students‹he didn't say which one‹had
found a suspected flaw, "and their response was beautiful," says Meunier.
They found, verified and fixed the bug right away, no questions asked.

But two months later, in April, the same physics department website was
hacked. A detective approached Meunier, whose name was mentioned by the
staff of the vulnerable website during questioning. The detective asked
Meunier for the name of the student who had discovered the February
vulnerability. The self-described "stubborn idealist" Meunier refused to
name the student. He didn't believe it was in that student's character to
hack the site and, furthermore, he didn't believe the vulnerability the
student had discovered, which had been fixed, was even connected to the
April hack.

The detective pushed him. Meunier recalls in his blog: "I was quickly
threatened with the possibility of court orders, and the number of felony
counts in the incident was brandished as justification for revealing the
name of the student." Meunier's stomach knotted when some of his superiors
sided with the detective and asked him to turn over the student. Meunier
asked himself: "Was this worth losing my job? Was this worth the hassle of
responding to court orders, subpoenas, and possibly having my computers
(work and personal) seized?" Later, Meunier recast the downward spiral of
emotions: "I was miffed, uneasy, disillusioned."

This is not good news for vulnerability research, the game of discovering
and disclosing software flaws. True, discovery and disclosure always have
been contentious topics in the information security ranks. For many years,
no calculus existed for when and how to ethically disclose software
vulnerabilities. Opinions varied on who should disclose them, too.
Disclosure was a philosophical problem with no one answer but rather,
schools of thought. Public shaming adherents advised security researchers,
amateurs and professionals alike to go public with software flaws early and
often and shame vendors into fixing their flawed code. Back-channel
disciples believed in a strong but limited expert community of researchers
working with vendors behind the scenes. Many others' disclosure tenets fell
in between.

Still, in recent years, with shrink-wrapped software, the community has
managed to develop a workable disclosure process. Standard operating
procedures for discovering bugs have been accepted and guidelines for
disclosing them to the vendor and the public have fallen into place, and
they have seemed to work. Economists have even proved a correlation between
what they call "responsible disclosure" and improved software security.

But then, right when security researchers were getting good at the
disclosure game, the game changed. The most critical code moved to the
Internet, where it was highly customized and constantly interacting with
other highly customized code. And all this Web code changed often, too,
sometimes daily. Vulnerabilities multiplied quickly. Exploits followed.

But researchers had no counterpart methodology for disclosing Web
vulnerabilities that mirrored the system for vulnerability disclosure in
off-the-shelf software. It's not even clear what constitutes a vulnerability
on the Web. Finally, and most serious, legal experts can't yet say whether
it's even legal to discover and disclose vulnerabilities on Web applications
like the one that Meunier's student found.

To Meunier's relief, the student volunteered himself to the detective and
was quickly cleared. But the effects of the episode are lasting. If it had
come to it, Meunier says, he would have named the student to preserve his
job, and he hated being put in that position. "Even if there turn out to be
zero legal consequences" for disclosing Web vulnerabilities, Meunier says,
"the inconvenience, the threat of being harassed is already a disincentive.
So essentially now my research is restricted."

He ceased using disclosure as a teaching opportunity as well. Meunier wrote
a five-point don't-ask-don't-tell plan he intended to give to cs390s
students at the beginning of each semester. If they found a Web
vulnerability, no matter how serious or threatening, Meunier wrote, he
didn't want to hear about it. Furthermore, he said students should "delete
any evidence you knew about this problem...go on with your life," although
he later amended this advice to say students should report vulnerabilities
to CERT/CC.

A gray pall, a palpable chilling effect has settled over the security
research community. Many, like Meunier, have decided that the discovery and
disclosure game is not worth the risk. The net effect of this is fewer
people with good intentions willing to cast a necessary critical eye on
software vulnerabilities. That leaves the malicious ones, unconcerned by the
legal or social implications of what they do, as the dominant demographic
still looking for Web vulnerabilities.
The Rise of Responsible Disclosure

In the same way that light baffles physicists because it behaves
simultaneously like a wave and a particle, software baffles economists
because it behaves simultaneously like a manufactured good and a creative
expression. It's both product and speech. It carries the properties of a car
and a novel at the same time. With cars, manufacturers determine quality
largely before they're released and the quality can be proven, quantified.
Either it has air bags or it doesn't. With novels (the words, not the paper
stock and binding), quality depends on what consumers get versus what they
want. It is subjective and determined after the book has been released.
Moby-Dick is a high-quality creative venture to some and poor quality to
others. At any rate, this creates a paradox. If software is both
scientifically engineered and creatively conjured, its quality is determined
both before and after it's released and is both provable and unprovable.

In fact, says economist Ashish Arora at Carnegie Mellon University, it is
precisely this paradox that leads to a world full of vulnerable software.
"I'm an economist so I ask myself, Why don't vendors make higher quality
software?" After all, in a free market, all other things being equal, a
better engineered product should win over a lesser one with rational
consumers. But with software, lesser-quality products, requiring massive
amounts of repair post-release, dominate. "The truth is, as a manufactured
good, it's extraordinarily expensive [and] time-consuming [to make it high
quality]." At the same time, as a creative expression, making "quality"
software is as indeterminate as the next best-seller. "People use software
in so many ways, it's very difficult to anticipate what they want.

"It's terrible to say," Arora concedes, "but in some ways, from an economic
perspective, it's more efficient to let the market tell you the flaws once
the software is out in the public." The same consumers who complain about
flawed software, Arora argues, would neither wait to buy the better software
nor pay the price premium for it if more-flawed, less-expensive software
were available sooner or at the same time. True, code can be engineered to
be more secure. But as long as publishing vulnerable software remains legal,
vulnerable software will rule because it's a significantly more efficient
market than the alternative, high-security, low-flaw market.

The price consumers pay for supporting cheaper, buggy software is they
become an ad hoc quality control department. They suffer the consequences
when software fails. But vendors pay a price, too. By letting the market
sort out the bugs, vendors have ceded control over who looks for flaws in
their software and how flaws are disclosed to the public. Vendors can't
control how, when or why a bug is disclosed by a public full of people with
manifold motivations and ethics. Some want notoriety. Some use disclosure
for corporate marketing. Some do it for a fee. Some have collegial
intentions, hoping to improve software quality through community efforts.
Some want to shame the vendor into patching through bad publicity. And still
others exploit the vulnerabilities to make money illicitly or cause damage.

"Disclosure is one of the main ethical debates in computer security," says
researcher Steve Christey. "There are so many perspectives, so many
competing interests, that it can be exhausting to try and get some movement
forward."

What this system created was a kind of free-for-all in the disclosure
bazaar. Discovery and disclosure took place without any controls. Hackers
traded information on flaws without informing the vendors. Security vendors
built up entire teams of researchers whose job was to dig up flaws and
disclose them via press release. Some told the vendors before going public.
Others did not. Freelance consultants looked for major flaws to make a name
for themselves and drum up business. Sometimes these flaws were so esoteric
that they posed minimal real-world risk, but the researcher might not
mention that. Sometimes the flaws were indeed serious, but the vendor would
try to downplay them. Still other researchers and amateur hackers tried to
do the right thing and quietly inform vendors when they found holes in code.
Sometimes the vendors chose to ignore them and hope security by obscurity
would protect them. Sometimes, Arora alleges, vendors paid mercenaries and
politely asked them to keep it quiet while they worked on a fix.

Vulnerability disclosure came to be thought of as a messy, ugly, necessary
evil. The madness crested, famously, at the Black Hat hacker conference in
Las Vegas in 2005, when a researcher named Michael Lynn prepared to disclose
to a room full of hackers and security researchers serious flaws in Cisco's
IOS software, the code that controls many of the routers on the Internet.
His employer, ISS (now owned by IBM) warned him not to disclose the
vulnerabilities. So he quit his job. Cisco in turn threatened legal action
and ordered workers to tear out pages from the conference program and
destroy conference CDs that contained Lynn's presentation. Hackers accused
Cisco of spin and censorship. Vendors accused hackers of unethical and
dangerous speech. In the end, Lynn gave his presentation. Cisco sued. Lynn
settled and agreed not to talk about it anymore.

The confounding part of all the grandstanding, though, was how unnecessary
it was. In fact, as early as 2000, a hacker known as Rain Forest Puppy had
written a draft proposal for how responsible disclosure could work. In 2002,
researchers Chris Wysopal and Christey picked up on this work and created a
far more detailed proposal. Broadly, it calls for a week to establish
contact between the researcher finding a vulnerability and a vendor's
predetermined liaison on vulnerabilities. Then it gives the vendor, as a
general guideline, 30 days to develop a fix and report it to the world
through proper channels. It's a head-start program, full disclosure‹delayed.
It posits that a vulnerability will inevitably become public, so here's an
opportunity to create a fix before that happens, since the moment it does
become public the risk of exploit increases. Wysopal and Christey submitted
the draft to the IETF (Internet Engineering Task Force), where it was
well-received but not adopted because it focused more on social standards,
not technical ones.

Still, its effects were lasting, and by 2004, many of its definitions and
tenets had been folded into the accepted disclosure practices for
shrink-wrapped software. By the time Lynn finally took the stage and
disclosed Cisco's vulnerabilities, US-CERT, Mitre's CVE dictionary (Christey
is editor), and Department of Homeland Security guidelines all used large
swaths of Wysopal's and Christey's work.

Recently, economist Arora conducted several detailed economic and
mathematical studies on disclosure, one of which seemed to prove that
vendors patch software faster when bugs are reported through this system.
For packaged software, responsible disclosure works.
>From Buffer Overflows to Cross-Site Scripting

Three vulnerabilities that followed the responsible disclosure process
recently are CVE-2006-3873, a buffer overflow in an Internet Explorer DLL
file; CVE-2006-3961, a buffer overflow in an Active X control in a McAfee
product; and CVE-2006-4565, a buffer overflow in the Firefox browser and
Thunderbird e-mail program. It's not surprising that all three are buffer
overflows. With shrink-wrapped software, buffer overflows have been for
years the predominant vulnerability discovered and exploited.

But shrink-wrapped, distributable software, while still proliferating and
still being exploited, is a less desirable target for exploiters than it
once was. This isn't because shrink-wrapped software is harder to hack than
it used to be‹the number of buffer overflows discovered has remained steady
for half a decade, according to the CVE (see chart on Page 21). Rather, it's
because websites have even more vulnerabilities than packaged software, and
Web vulnerabilities are as easy to discover and hack and, more and more,
that's where hacking is most profitable. In military parlance, webpages
provide a target-rich environment.

The speed with which Web vulnerabilities have risen to dominate the
vulnerability discussion is startling. Between 2004 and 2006, buffer
overflows dropped from the number-one reported class of vulnerability to
number four. Counter to that, Web vulnerabilities shot past buffer overflows
to take the top three spots. The number-one reported vulnerability,
cross-site scripting (XSS) comprised one in five of all CVE-reported bugs in
2006.

To understand XSS is to understand why, from a technical perspective, it
will be so hard to apply responsible disclosure principles to Web
vulnerabilities.

Cross-site scripting (which is something of a misnomer) uses vulnerabilities
in webpages to insert code, or scripts. The code is injected into the
vulnerable site unwittingly by the victim, who usually clicks on a link that
has HTML and JavaScript embedded in it. (Another variety, less common and
more serious, doesn't require a click). The link might promise a free iPod
or simply seem so innocuous, a link to a news story, say, that the user
won't deem it dangerous. Once clicked, though, the embedded exploit executes
on the targeted website's server. The scripts will usually have a malicious
intent‹from simply defacing the website to stealing cookies or passwords, or
redirecting the user to a fake webpage embedded in a legitimate site, a
high-end phishing scheme that affected PayPal last year. A buffer overflow
targets an application. But XSS is, as researcher Jeremiah Grossman (founder
of WhiteHat Security) puts it, "an attack on the user, not the system." It
requires the user to visit the vulnerable site and participate in executing
the code.

This is reason number one it's harder to disclose Web vulnerabilities. What
exactly is the vulnerability in this XSS scenario? Is it the design of the
page? Yes, in part. But often, it's also the social engineering performed on
the user and his browser. A hacker who calls himself RSnake and who's
regarded in the research community as an expert on XSS goes even further,
saying, "[XSS is] a gateway. All it means is I can pull some code in from
somewhere." In some sense it is like the door to a house. Is a door a
vulnerability? Or is it when it's left unlocked that it becomes a
vulnerability? When do you report a door as a weakness‹when it's just there,
when it's left unlocked, or when someone illegally or unwittingly walks
through it? In the same way, it's possible to argue that careless users are
as much to blame for XSS as software flaws. For the moment, let's treat XSS,
the ability to inject code, as a technical vulnerability.

Problem number two with disclosure of XSS is its prevalence. Grossman, who
founded his own research company, White Hat, claims XSS vulnerabilities can
be found in 70 percent of websites. RSnake goes further. "I know Jeremiah
says seven of 10. I'd say there's only one in 30 I come across where the XSS
isn't totally obvious. I don't know of a company I couldn't break into
[using XSS]."

If you apply Grossman's number to a recent Netcraft survey, which estimated
that there are close to 100 million websites, you've got 70 million sites
with XSS vulnerabilities. Repairing them one-off, two-off, 200,000-off is
spitting in the proverbial ocean. Even if you've disclosed, you've done very
little to reduce the overall risk of exploit. "Logistically, there's no way
to disclose this stuff to all the interested parties," Grossman says. "I
used to think it was my moral professional duty to report every
vulnerability, but it would take up my whole day."

What's more, new XSS vulnerabilities are created all the time, first because
many programming languages have been made so easy to use that amateurs can
rapidly build highly insecure webpages. And second because, in those slick,
dynamic pages commonly marketed as "Web 2.0," code is both highly customized
and constantly changing, says Wysopal, who is now CTO of VeriCode. "For
example, look at IIS [Microsoft's shrink-wrapped Web server software]," he
says. "For about two years people were hammering on that and disclosing all
kinds of flaws. But in the last couple of years, there have been almost no
new vulnerabilities with IIS. It went from being a dog to one of the highest
security products out there. But it was one code base and lots of
give-and-take between researchers and the vendor, over and over.

"On the Web, you don't have that give and take," he says. You can't
continually improve a webpage's code because "Web code is highly customized.
You won't see the same code on two different banking sites, and the code
changes all the time."

That means, in the case of Web vulnerabilities, says Christey, "every input
and every button you can press is a potential place to attack. And because
so much data is moving you can lose complete control. Many of these
vulnerabilities work by mixing code where you expect to mix it. It creates
flexibility but it also creates an opportunity for hacking."

There are in fact so many variables in a Web session‹how the site is
configured and updated, how the browser is visiting the site configured to
interact with the site‹that vulnerabilities to some extent become a function
of complexity. They may affect some subset of users‹people who use one
browser over another, say. When it's difficult to even recreate the set of
variables that comprise a vulnerability, it's hard to responsibly disclose
that vulnerability.

"In some ways," RSnake says, "there is no hope. I'm not comfortable telling
companies that I know how to protect them from this."
A wake-up call for websites

Around breakfast one day late last August, RSnake started a thread on his
discussion board, Sla.ckers.org, a site frequented by hackers and
researchers looking for interesting new exploits and trends in Web
vulnerabilities. RSnake's first post was titled "So it begins." All that
followed were two links, www.alexa.com and www.altavista.com, and a short
note: "These have been out there for a while but are still unfixed."
Clicking on the links exploited XSS vulnerabilities with a reasonably
harmless, proof-of-concept script. RSnake had disclosed vulnerabilities.

He did this because he felt the research community and, more to the point,
the public at large, neither understood nor respected the seriousness and
prevalence of XSS. It was time, he says, to do some guerilla vulnerability
disclosure. "I want them to understand this isn't Joe Shmoe finding a little
hole and building a phishing site," RSnake says. "This is one of the pieces
of the puzzle that could be used as a nasty tool."

If that first post didn't serve as a wake-up call, what followed it should.
Hundreds of XSS vulnerabilities were disclosed by the regular klatch of
hackers at the site. Most exploited well-known, highly trafficked sites.
Usually the posts included a link that included a proof-of-concept exploit.
An XSS hole in www.gm.com, for example, simply delivered a pop-up dialog box
with an exclamation mark in the box. By early October, anonymous lurkers
were contributing long lists of XSS-vulnerable sites. In one set of these,
exploit links connected to a defaced page with Sylvester Stallone's picture
on it and the message "This page has been hacked! You got Stallown3d!1" The
sites this hacker contributed included the websites of USA Today, The New
York Times, The Boston Globe, ABC, CBS, Warner Bros., Petco, Nike, and
Linens 'n Things. "What can I say?" RSnake wrote. "We have some kick-ass
lurkers here."

Some of the XSS holes were closed up shortly after appearing on the site.
Others remain vulnerable. At least one person tried to get the discussion
board shut down, RSnake says, and a couple of others "didn't react in a way
that I thought was responsible." Contacts from a few of the victim
sites‹Google and Mozilla, among others‹called to tell RSnake they'd fixed
the problem and "to say thanks through gritted teeth." Most haven't
contacted him, and he suspects most know about neither the discussion thread
nor their XSS vulnerabilities.

By early November last year, the number of vulnerable sites posted reached
1,000, many discovered by RSnake himself. His signature on his posts reads
"RSnake‹Gotta love it." It connotes an aloofness that permeates the
discussion thread, as if finding XSS vulnerabilities were too easy. It's fun
but hardly professionally interesting, like Tom Brady playing flag football.

Clearly, this is not responsible disclosure by the standards shrink-wrapped
software has come to be judged, but RSnake doesn't think responsible
disclosure, even if it were somehow developed for Web vulnerabilities (and
we've already seen how hard that will be, technically), can work. For one,
he says, he'd be spending all day filling out vulnerability reports. But
more to the point, "If I went out of my way to tell them they're vulnerable,
they may or may not fix it, and, most importantly, the public doesn't get
that this is a big problem."
Discovery Is (Not?) a Crime

RSnake is not alone in his skepticism over proper channels being used for
something like XSS vulnerabilities. Wysopal himself says that responsible
disclosure guidelines, ones he helped develop, "don't apply at all with Web
vulnerabilities." Implicit in his and Christey's process was the idea that
the person disclosing the vulnerabilities was entitled to discover them in
the first place, that the software was theirs to inspect. (Even on your own
software, the end user license agreement‹EULA‹and the Digital Millennium
Copyright Act‹DMCA‹limit what you can do with/to it). The seemingly endless
string of websites RSnake and the small band of hackers had outed were not
theirs to audit.

Disclosing the XSS vulnerabilities on those websites was implicitly
confessing to having discovered that vulnerability. Posting the exploit
code‹no matter how innocuous‹was definitive proof of discovery. That, it
turns out, might be illegal.

No one knows for sure yet if it is, but how the law develops will determine
whether vulnerability research will get back on track or devolve into the
unorganized bazaar that it once was and that RSnake's discussion board hints
it could be.

The case law in this space is sparse, but one of the few recent cases that
address vulnerability discovery is not encouraging. A man named Eric
McCarty, after allegedly being denied admission to the University of
Southern California, hacked the online admission system, copied seven
records from the database and mailed the information under a pseudonym to a
security news website. The website notified the university and subsequently
published information about the vulnerability. McCarty made little attempt
to cover his tracks and even blogged about the hack. Soon enough, he was
charged with a crime. The case is somewhat addled, says Jennifer Granick, a
prominent lawyer in the vulnerability disclosure field and executive
director at Stanford's Center for Internet and Society. "The prosecutor
argued that it's because he copied the data and sent it to an unauthorized
person that he's being charged," says Granick, "but copying data isn't
illegal. So you're prosecuting for unauthorized testing of the system"‹what
any Web vulnerability discoverer is doing‹"but you're motivated by what they
did with the information. It's kind of scary."

Two cases in a similar vein preceded McCarty's. One was acquitted in less
than half an hour, Granick says; in the other, prosecutors managed to
convict the hacker, but, in a strange twist, they dropped the conviction on
appeal (Granick represented the defendant on the appeal). In the USC case,
though, McCarty pleaded guilty to unauthorized access. Granick calls this
"terrible and detrimental."

"Law says you can't access computers without permission," she explains.
"Permission on a website is implied. So far, we've relied on that. The
Internet couldn't work if you had to get permission every time you wanted to
access something. But what if you're using a website in a way that's
possible but that the owner didn't intend? The question is whether the law
prohibits you from exploring all the ways a website works," including
through vulnerabilities.

Granick would like to see a rule established that states it's not illegal to
report truthful information about a website vulnerability, when that
information is gleaned from taking the steps necessary to find the
vulnerability, in other words, benevolently exploiting it. "Reporting how a
website works has to be different than attacking a website," she says.
"Without it, you encourage bad disclosure, or people won't do it at all
because they're afraid of the consequences." Already many researchers,
including Meunier at Purdue, have come to view a request for a researchers'
proof-of-concept exploit code as a potentially aggressive tactic. Handing it
over, Meunier says, is a bad idea because it's proof that you've explored
the website in a way the person you're giving the code to did not intend.
The victim you're trying to help could submit that as Exhibit A in a
criminal trial against you.

RSnake says he thought about these issues before he started his discussion
thread. "I went back and forth personally," he says. "Frankly, I don't think
it's really illegal. I have no interest in exploiting the Web." As for
others on the discussion board "everyone on my board, I believe, is
nonmalicious." But he acknowledges that the specter of illegality and the
uncertainty surrounding Web vulnerability disclosure are driving some
researchers away and driving others, just as Granick predicted, to try to
disclose anonymously or through back channels, which he says is unfortunate.
"We're like a security lab. Trying to shut us down is the exact wrong
response. It doesn't make the problem go away. If anything, it makes it
worse. What we're doing is not meant to hurt companies. It's meant to make
them protect themselves. I'm a consumer advocate."
A Limited Pool of Bravery

What happens next depends, largely, on those who publish vulnerable software
on the Web. Will those with vulnerable websites, instead of attacking the
messenger, work with the research community to develop some kind of
responsible disclosure process for Web vulnerabilities, as complex and
uncertain a prospect as that is? Christey remains optimistic. "Just as with
shrink-wrapped software five years ago, there are no security contacts and
response teams for Web vulnerabilities. In some ways, it's the same thing
over again. If the dynamic Web follows the same pattern, it will get worse
before it gets better, but at least we're not at square one." Christey says
his hope rests in part on an efficacious public that demands better software
and a more secure Internet, something he says hasn't materialized yet.

Or will they start suing, threatening, harassing those who discover and
disclose their Web vulnerabilities regardless of the researchers' intention,
confidently cutting the current with the winds of McCarty's guilty plea
filling their sails? Certainly this prospect concerns legal scholars and
researchers, even ones who are pressing forward and discovering and
disclosing Web vulnerabilities despite the current uncertainty and risk.
Noble as his intentions may be, RSnake is not in the business of martyrdom.
He says, "If the FBI came to my door [asking for information on people
posting to the discussion board], I'd say 'Here's their IP address.' I do
not protect them. They know that."

He sounds much as Meunier did when he conceded that he'd have turned over
his student if it had come to that. In the fifth and final point he provides
for students telling them that he wants no part of their vulnerability
discovery and disclosure, he writes: "I've exhausted my limited pool of
bravery. Despite the possible benefits to the university and society at
large, I'm intimidated by the possible consequences to my career, bank
account and sanity. I agree with [noted security researcher] H.D. Moore, as
far as production websites are concerned: 'There is no way to report a
vulnerability safely.'"

E-mail feedback to Senior Editor Scott Berinato.