The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 27 Issue 77

Friday 28 February 2014

Contents

Fake Computer Science Papers
Rebecca Mercuri
France's 'Anti-Amazon' law takes the wrong approach
Hugo Beniada via Gene Wirchenko
"Study: IRS exposing Social Security numbers online"
Tony Bradley via Gene Wirchenko
EFF: Bad Facts, Really Bad Law: Court Orders Google to Censor Controversial Video Based on Spurious Copyright Claim
Lauren Weinstein
"Pony malware targeting passwords and Bitcoins uncovered"
Candice So via Gene Wirchenko
Scholarship for Women Studying Information Security
Jeremy Epstein
Re: Lawmakers consider broad safety exemptions to bypass FDA
Robert L Wears
"New iOS flaw allows malicious apps to record touch screen presses" Lucian Constantin via Gene Wirchenko)
????
"Apple's security flaws: Are you paranoid enough yet?"
Caroline Craig via Gene Wirchenko
Re: iPhone's Critical Security Bug: a Single Bad `Goto'
Chuck Petras
Dimitri Maziuk
David Hedley
Phil Smith
Info on RISKS (comp.risks)

Fake Computer Science Papers

Rebecca Mercuri <notable@mindspring.com>
Wed, 26 Feb 2014 09:38:26 -0500
There is some software (called SCIgen) out of MIT that generates
scientific-looking papers. And some number of these have actually squeaked
through in (supposedly) reviewed conference proceedings, as well as into
IEEE and ACM databases!

Here's the research paper (not fake but 2 examples are in Appendix A) about
the fake papers:

http://hal.archives-ouvertes.fr/docs/00/71/35/55/PDF/0-FakeDetectionSci-Perso.pdf

A new check-box in paper review forms is suggested: "Utter Bullbleep!"

  [This is a very unsettling article.  The title is
    Duplicate and Fake Publications in the Scientific Literature: How
    many SCIgen papers in Computer Science?
    Cyril Labbe' and Dominique Labbe',
    Institut d'Etudes Politiques de Grenoble, First.Last@iep-grenoble.fr
    22 Jun 2012 ; Scientometrics; DOI 10.1007/s11192-012-0781-y

Abstract

Two kinds of bibliographic tools are used to retrieve scientific
publications and make them available online. For one kind, access is free as
they store information made publicly available online. For the other kind,
access fees are required as they are compiled on information provided by the
major publishers of scientific literature. The former can easily be
interfered with, but it is generally assumed that the latter guarantee the
integrity of the data they sell.  Unfortunately, duplicate and fake
publications are appearing in scientific conferences and, as a result, in
the bibliographic services. We demonstrate a software method of detecting
these duplicate and fake publications. Both the free services (such as
Google Scholar and DBLP) and the charged-for services (such as IEEE Xplore)
accept and index these publications.

keyword: Bibliographic
Tools, Scientific Conferences, Fake Publications, Text-Mining, Inter-
Textual Distance, Google Scholar, Scopus, WoK

Introduction

Several factors are substantially changing the way the scientific community
shares its knowledge.  On the one hand, technological developments have made
the writing, publication and dissemination of documents quicker and
easier. On the other hand, the "pressure" of individual evaluation of
researchers-publish or perish-is changing the publication process. This
combination of factors has led to a rapid increase in scientific document
production. The three largest tools referencing scientific texts are: Scopus
(Elsevier), ISI-Web of Knowledge (WoK Thomson-Reuters) and Google Scholar.

Google Scholar is undoubtedly the tool which references the most
material. It is free and it offers wide coverage, both of which are
extremely useful to the scientific community. Google Scholar allows grey
literature to be more visible and more accessible (technical reports, long
versions and/or tracts of previously published papers, etc). Google Scholar
systematically indexes everything that looks like a scientific publication
on the Internet, and, inside these documents and records, it indexes
references to other documents. Thus, it gives a picture of which documents
are the most popular. However, the tool, much like the search engine Google,
is sensitive to "Spam" [2], mainly through techniques, similar to link farms
that artificially increase the "ranking" of web pages. Faked papers like
those by Ike Antkare [12] (see 2.2 below) may also be mistakenly
indexed. This means that documents indexed by Google Scholar are not all
bona fide scientific ones, and information on real documents (such as the
number of citations found) 1 hal-00641906, version 2 - 2 Jul 2012 Author
manuscript, published in "Scientometrics (2012) 10.1007/s11192-012-0781-y"
DOI : 10.1007/s11192-012-0781-y can be manipulated. This type of tool, using
information publicly and freely available on the Web, faces some
reproducibility and quality control problems [22, 10].

  The full paper is well worth reading.  PGN]


France's 'Anti-Amazon' law takes the wrong approach (Hugo Beniada)

Gene Wirchenko <genew@telus.net>
Fri, 28 Feb 2014 10:24:19 -0800
Hugo Beniada, Fueled, 27 Feb 2014
http://www.itbusiness.ca/blog/frances-anti-amazon-law-takes-the-wrong-approach/46802

selected text:

After taking aim at U.S. Internet giants, including Yahoo Inc. and Google
Inc., France's new target is the online retailer Amazon.com Inc.

Last month, the French Senate has approved the so-called "Anti-Amazon" law,
aimed to protect local book retailers. Basically, this law modernizes a 1918
law that established a fixed price for books sold in France. The Lang law,
which carries the name of Jack Lang (the Minister of Culture of that time),
enables book retailers to only discount up to 5 percent below the
publisher's price.

Created to preserve France's cultural exception, the government happens to
really forget about the primordial access to Culture with this law. French
rural inhabitants don't always have the chance live right next to a
bookshop. Driving to the closest bookshop and paying for gas seems to be
really more inconvenient than waiting for a book to be delivered for free to
your mailbox.

  [I just noticed that in addition to selling new copies of my
  "Computer-Related Risks" (1995) book at a nice discount, Amazon is
  offering 15 used copies available for $0.01 plus shipping.  I'm delighted
  the book is still recirculating.  So much of it is still relevant today,
  as we keep making the same mistakes over and over again.  PGN]


"Study: IRS exposing Social Security numbers online" (Tony Bradley)

Gene Wirchenko <genew@telus.net>
Wed, 26 Feb 2014 09:51:55 -0800
Tony Bradley, InfoWorld, 25 Feb 2014
An analysis of public tax returns from non-profit organizations found
  an estimated 630,000 Social Security numbers were exposed online
PC Worldhttp://www.infoworld.com/d/security/study-irs-exposing-social-security-numbers-online-237089

opening text:

This tax season you may have more to worry about than how much you owe. A
new study from Identity Finder finds the IRS is not properly protecting
social security numbers in some tax returns.

Personal tax returns are not public, but the tax returns of non-profit
organizations are public domain.


EFF: Bad Facts, Really Bad Law: Court Orders Google to Censor Controversial Video Based on Spurious Copyright Claim

Lauren Weinstein <lauren@vortex.com>
Wed, 26 Feb 2014 20:01:12 -0800
  "It's an old legal adage that bad facts lead to bad legal decisions, and
  today we've got a classic example in Garcia v. Google-the "Innocence of
  Muslims" case. Based on a copyright claim that is dubious at best, the
  Ninth Circuit Court of Appeals has ordered Google to take offline a video
  that is the center of public controversy. We can still talk about it, but
  we can't see what we are talking about.  We're hard-pressed to think of a
  better example of copyright maximalism trumping free speech."
    http://j.mp/1hiSWHI  (EFF)


"Pony malware targeting passwords and Bitcoins uncovered" (Candice So)

Gene Wirchenko <genew@telus.net>
Thu, 27 Feb 2014 11:32:35 -0800
Candice So, *IT Business*, 26 Feb 2014
http://www.itbusiness.ca/news/pony-malware-targeting-passwords-and-bitcoins-uncovered/47143


Scholarship for Women Studying Information Security

Jeremy Epstein <jeremy.j.epstein@gmail.com>
Fri, 28 Feb 2014 12:50:12 -0500
Since 2011, Applied Computer Security Associates, sponsor of the ACSAC and
NSPW conferences, has offered scholarships for women in their undergraduate
and masters' degree programs through the Scholarships for Women Studying
Information Security (SWSIS, www.swsis.org).

Thanks to a $250,000 4-year contribution by Hewlett-Packard company, ACSA
plans to offer an increased number of scholarships for the 2014-15 academic
year.  Also new in 2014-15, the Committee on the Status of Women in
Computing Research (CRA-W), an arm of the Computing Research Alliance, is
joining SWSIS, and will lead selection of scholarship winners.

SWSIS winners will be invited to attend flagship conferences sponsored by
ACSA, HP, and CRA-W, and will be encouraged to participate in HP's summer
internship program.

Applicants must provide:
* An essay describing their interest and background in the information
  security field.
* A current transcript.
* A resume or CV.
* Letters of reference (typically from faculty members).
* Their university name and class status.

The scholarship is renewable for a second year, given proof of satisfactory
academic progress.  Preference is for US citizens or permanent residents;
funds are available for use at any US campus of a US university.

Applications may be submitted starting 30 Mar 2014, and will be accepted
until 1 May 2014.

More information at www.swsis.org or swsis@swsis.org

Jeremy Epstein, Director, Scholarship Programs
Applied Computer Security Associates, Inc.


Re: Lawmakers consider broad safety exemptions to bypass FDA (Fu, RISKS-27.76)

"Robert L Wears, MD, MS, PhD" <wears@ufl.edu>
Thu, 27 Feb 2014 14:00:34 -0500
Kevin Fu's post notes that proposed legislation exempting health information
technology from independent oversight would create "disturbing loopholes"
that could compromise safety ... It's even worse than that.  Patient safety
is already compromised by buggy, poorly usable systems. The legislation
would just enshrine the status quo as the state of the art.

Robert L Wears, MD, MS, PhD, University of Florida Imperial College London
wears@ufl.edu 1-904-244-4405  r.wears@imperial.ac.uk +44 (0)791 015 2219


"New iOS flaw allows malicious apps to record touch screen presses"

Gene Wirchenko <genew@telus.net>
Wed, 26 Feb 2014 09:53:30 -0800
Lucian Constantin, InfoWorld, 25 Feb 2014
Attack is the equivalent of keylogging, and the captured touch screen
data could be used to reconstruct what users type
http://www.infoworld.com/d/security/new-ios-flaw-allows-malicious-apps-record-touch-screen-presses-237070


"Apple's security flaws: Are you paranoid enough yet?" (Caroline Craig)

Gene Wirchenko <genew@telus.net>
Fri, 28 Feb 2014 10:17:52 -0800
Caroline Craig | InfoWorld, 28 Feb 2014
Apple's SSL encryption fail and iOS keylogging flaw juiced anxiety
levels in an industry already reeling from security fatigue
http://www.infoworld.com/t/vulnerability-assessment/apples-security-flaws-are-you-paranoid-enough-yet-237332


Re: iPhone's Critical Security Bug: a Single Bad `Goto' (RISKS-27.76)

<Chuck_Petras@selinc.com>
Wed, 26 Feb 2014 11:22:48 -0800
What horrible coding style.  To me it looks like it was specifically written
to embed that exploit!

The Apple code snippet is a great example of why curly brackets should be
mandatory.

If I was reviewing that code I'd have made them re-write it along the lines
of:

   err = 0;
   if ( ( (err = (SSLHashSHA1.update(&hashCtx, &serverRandom)) ) != 0 ) ||
        ( (err = (SSLHashSHA1.update(&hashCtx, &signedParams)) ) != 0 ) ||
        ( (err = (SSLHashSHA1.final(&hashCtx, &hashOut))       ) != 0 )
      )
   { // Do fail stuff here
      SSLFreeBuffer(&signedHashes);
      SSLFreeBuffer(&hashCtx);
   }
   return err;

Chuck Petras, PE**, Schweitzer Engineering Laboratories, Inc
Pullman, WA  99163  USA  http://www.selinc.com  Tel: +1.509.332.1890


Re: iPhone's Critical Security Bug: a Single Bad `Goto' (RISKS-27.76)

Dimitri Maziuk <dmaziuk@bmrb.wisc.edu>
Tue, 25 Feb 2014 18:47:29 -0600
Just as a side note: but there's several scenarios where computer
practitioners consider it better than the alternative.

The code below is the textbook illustration for one: cleaning up after
yourself, in this case: freeing up memory.

> SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer
>   signedParams, uint8_t *signature, UInt16 signatureLen)
>
> {
>         OSStatus        err;
>         ...
>         if <error>
>                 goto fail;
          ...
>         if <another error>
>                 goto fail;
          ...
>         if <yet another error>
>                 goto fail;
>         ...
> fail:
>         SSLFreeBuffer(&signedHashes);
>         SSLFreeBuffer(&hashCtx);
>         return err;
> }

Because if you copy-paste the clean-up ("fail") block into a dozen "if"
blocks you will mess one of them up. Or somebody updating the code will
mess one up eventually.

What you'll get then is the dreaded memory leak that every computer
scientist knew was considered harmful.

Dimitri Maziuk, BioMagResBank, UW-Madison—http://www.bmrb.wisc.edu


Re: iPhone's Critical Security Bug: a Single Bad `Goto' (RISKS-27.76)

David Hedley <david.hedley@3-c.coop>
Wed, 26 Feb 2014 10:14:46 +0000
This fault demonstrates a dangerous feature of the C language and its
derivatives.

This programming mistake is not possible in an Algol or Fortran based
language, which would read:

IF (err ... != 0) THEN goto fail ENDIF;

and the (presumed) botched cut and paste edit would fail compilation.

So I propose that the use of C is a risk.


Re: iPhone's Critical Security Bug: a Single Bad `Goto' (RISKS-27.76)

Phil Smith <phil@voltage.com>
Thu, 27 Feb 2014 09:34:00 -0800
>Baker:
But every computer scientist already knew that GOTO's are considered harmful!

I have for 35 years and continue to take exception to this blanket
statement, and do not believe from my reading of the early discussions that
this belief was the intention of the original writers. "GOTOs *without
discipline* are harmful" is closer to what I believe they meant.

In other words, GOTOs *can* make code much less readable, maintainable,
stable, reliable, and other good words ending in -ble. But that isn't
necessarily the case: indeed, code where the mainline never does a GOTO
*except* to branch out to error handlers (yes, I'm mainly talking about
non-OO code here) can be far more -ble.

Specifically, it reduces the levels of nesting. Consider the following
(p-code):

Function1()
If rc != 0 then...
   Function2()
   If rc != 0 then ...
      Function3()
      If rc != 0 then ...
         Function4()
         If rc != 0 then ...
         End
      End
   End
End
/* Did everything above work? */
If rc != 0 then ...
End

Those nested IFs get pretty painful if you use indention (required for some
of the -bles!), especially if the blocks are large (another topic for theo
logical discussion, but out of scope here). Far more -ble IMHO:

Function1()
If rc != 0 then goto FAILED1
Function2()
If rc != 0 then goto FAILED2
Function3()
If rc != 0 then goto FAILED3
Function4()
If rc != 0 then goto FAILED4
/* If we get here, everything worked so far */

I would MUCH rather read and maintain the latter: I can see what the
mainline is doing, and if I need to know what happens if a specific call
fails, I go follow that up. This in no way diminishes the importance of
error handling: indeed, it enhances it, by allowing a bunch of error
handlers to be adjacent, making it easier to keep their behavior consistent.
How many times have you fixed a memory leak caused by an error case that
forgot to release a buffer that the other 27 error handlers all remembered
to do? If those had all been adjacent, it should (I almost wrote "would",
but that's a wish) be easier for the person adding a handler to say "Oh,
yeah, look, they all release that, I should at least see whether I need to
do that as well".

This requires some rigor to make sure that the FAILEDx handlers all
themselves wind up at an appropriate exit point, but then, this is all about
rigor.

It helps if the error handlers actually DO something, of course; in Apple's
case, "fail:" didn't do much except assume that an error had occurred. In
system-level code, I'd consider that alone to be inexcusably sloppy.
Something like this should be returning an error AND a reason: the error
handler forces the error, and the reason would be what fell out of the
specific call ("rc" vs. "errno", in many cases).

So the problem here wasn't the GOTOs per se: it was poorly structured, lazy
code. Not a new risk, alas.

Please report problems with the web pages to the maintainer

Top