A quick test on my local machine shows that this will send a message to nasty@secret.org with the subject gotcha and the body "hi=there".

This is insidious; it means that E-mail messages, purportedly from me (and all traces will show they really are from me) can be sent anywhere, without my knowledge, with contents that I do not approve. Further, it means that I can no longer count on browsing a site without my userid being disclosed. Unlike Java, there is no way to disable this. [Also been submitted to Netscape.]

Netscape's too-lenient syntax checking

> From: [webmaster @ affected site]
> RE: Re: [site name deleted] Web Link

> From [frustrated web site visitor]
> > The main link to [site name deleted] doesn't
> > work through 'lynx' because the html is not
> > correct. The ' > > link is never terminated with '</a>', so that
> > the [site name deleted] link won't work.
> > Could you please look at this problem, and
> > send me a message when it is fixed.
> > Thanks very much.
>
> Thanks for the input. The mistake was never noticed before because the
> Netscape browsers are smart enough to detect the error and deal with it.
> Lynx, however, is not. The problem is fixed, although I don't recommend
> looking at the site with anything but Netscape 1.1N and higher. We
> incorporate too many of Netscape's features to make viewing these pages
> without it useful.

Re: CIA & NSA run remailers (Mayer-Schoenberger, RISKS-17.87)

As the maintainer of a remailer-list, I felt I should respond to this. Strassmann and Marlow have lately been getting quite a bit of press spreading anti-remailer fear, uncertainty and doubt. Almost all of it is inaccurate.

It is certainly possible that governments are running remailers. Personally, I tend to doubt it, but that's just because I know most of the remailer operators. Even if governments were running remailers, the use of a chain of remailers, rather than just one, protects against compromise of identity even if one or more remailers are compromised. It suffices that one of the remailers in the chain is honest. It certainly isn't the case that the most popular remailers in France and Germany are run by government agencies. Maybe if there were remailers in these countries, they would be, but there aren't. There used to be one in Germany, but it's no longer operating. There's never been one in France. If there were, it would be quite illegal, due to the French crypto restrictions.

The ability to crack 1000-bit keys would represent a major advance in factoring technology. 1024-bit keys less than an order of magnitude more effort to crack than 1000, so recommending them in face of 1000-bit keys having been cracked is ridiculous. The current record for factoring an RSA key is still RSA-129, which is only about 428 bits. Advances in factoring are expected, but most people figure 1000 bits is a long way away.

[... don't forget that if you can monitor and compare the incoming and outgoing mail from an anonymous remailer, ... PGN]

Locking the key inside

Where I work, a security grille is opened and closed by means of a remote control unit. As the grille can be closed by a short press of a button on the remote control unit, it is quite possible to accidentally end up with the operator on the outside of a closed security grille with the remote control unit left locked inside. I did that yesterday morning.

For all the complexity of the situation, I had simply locked a "key" - the remote control unit - inside the secured area.

After puzzling over the situation, I came up with the specific solution that a remote control to close or lock a device shouldn't proceed to completion unless the control is held on by the operator. (That kind of safeguard is like not being able to lock something from outside without the key).

For the software analogy, imagine the situation when new bootstrap or operating system code is loaded. If the new code fails to load or work for any reason, there needs to be a means of booting from the old code.

In the software analogy the "key" is the bootstrap or operating system kernel and code that make a computer, modem or other device work: one doesn't want to let go of or throw away the old "key" until the new "key" is safely written to non-volatile storage media and known to work. To allow the user to delete the old code (especially inadvertently) without the new code working is undesirable, yet some modems with user-upgradable firmware don't protect the user against such behaviour. No doubt many RISKs readers have had similar experiences with software upgrades of many kinds...

Backdoors, bugs, and Oracle

On 22 Jun 1995, I reported a "flaw" with Oracle7 and its ALTER USER instruction that enabled any userid beginning with "sys" to "ALTER USER SYS IDENTIFIED BY <pw>", giving complete system permission to ordinary users. Amazingly, the command would fail for any user except "sys". I sent a notice to our Oracle contact and they fixed the problem in minutes (over the phone). I discovered the problem in release 7.1.4 and it is no longer present in 7.2.3.

When I upgraded to 7.2.3, I noticed another "feature" (new to me anyway) "ALTER SESSION SET CURRENT_SCHEMA= <user>". It's a nifty little command that allows you to change ids without a password (the import utility uses it). Anyway, during a restore (disk failures), I noticed that any user could use the "ALTER SESSION" instruction regardless of whether they had been granted that privilege or not. I breathed a sigh of relief when it seemed that "actual" authorities were enforced based upon the real userid. Whew! But, it sure does make me wonder if I haven't looked hard enough.

This reminded me of the Oracle6 export utility and how it placed passwords for database links in plaintext. Oracle 6 and 7 database files contain plaintext strings. All of this is ok if you simply change the permissions on files, directories, or file systems (as Oracle recommends). One other thing that was a neat idea on Oracle's part, using a userid "scott" with the password "tiger" to install the demos to. Unfortunately, I've seen too many systems that either did not disable the account when finished, or that actually gave total permissions to "scott". Ouch. There have even been a few cases of the "system" password still being "manager" from the install.

I think Oracle has an excellent RDBMS. It performs quite well, and I've survived many failures (knock on wood). I I haven't used anything else in a while, so I relate only to Oracle. Anyway, the risks... With any large, complex sets of software "bugs" might silently hide, backdoors can remain undetected, and a whole lot is handled without any human intervention. Oracle has had its share of bugs and they have been good about correcting it in some way. The "backdoors" have implications that go beyond Oracle...

Over 10,000 sites running nonsecure versions of NCSA web server

[Long message abstracted for RISKS by PGN:]

Details of the problem, demo program, and recommendations, are available <http://www.netcraft.com/security/http/ncsa13.html>.

The current versions of both NCSA and Apache are freely available, have log file compatibility with NCSA/1.3, and -- so far as we are aware -- no one has published details of security weaknesses in either.

Re: Teen convicted on mismatched metadata (Jewell, RISKS-17.87)

The problem wasn't simply due to the compact representation, but also to the fact that the data required to interpret it was separated from the offence record. An awesomely large-scale foulup of the same nature was reported here a few years ago; the police in Paris did their routine mailing of citations for traffic offences, where the decoding information was kept on a separate magnetic tape. But this time someone had loaded the wrong tape; one containing codes for serious criminal offences. The result was that thousands of people charged with double parking or running red lights were sent documents accusing them of kidnapping or attempted murder; along with demands for payment of trivial fines. (One of the more popular charges was "illegal handling of veterinary products", if I remember right).

Both examples are elementary failures of database design and management, and there's been no excuse for them for 30-odd years. "Lack of redundancy" is exactly what relational normalization is *for*, and if done right it can only be beneficial.

Re: Teen convicted: a similar example (Jewell, RISKS-17.87)

Normalization is not bad design. It is good design, according to a substantial body of relational database design literature. Basically, you want to use the smallest non-ambiguous code set for internal storage, then use those codes to reference a human readable display code. The risk is not bad design, but rather inconsistent code definition across systems.

I have suffered from this as well. I received a ticket for riding a bicycle in a no bike riding zone, that was explicitly _not_ supposed to affect my driving record. It did, however, because the motor vehicle department computers saw a non-recognized code propagated from the city computers, and assumed it was something bad, rather than something innocuous or null. I had to take several days off work and run around between various courthouses to fix the problem. This shows the added risk of lost productivity due to knowledgeable people being affected by stupid computer systems and quixotically wanting to make the data good.

Chris also seems to have missed the obvious risk of fundamental systems change over time. Even only 13 years of school records is enough time for substantial change in record-keeping and perhaps even "good" systems design. I hope people don't expect $200 Gigabyte disks to last decades.

Signs of Intelligent Life

The recent traffic about maintaining clock and calendar integrity led me to speculate that one of the astronomical attributes we could use to determine whether a distant solar system contained intelligent life would be if the planet most likely to support life had a rotational period that was related to its orbital period by an exact integer.

I mentioned this to a friend of mine who has spent considerable time researching these issues, and he said it would be evidence of really stupid intelligent life.

But I countered that maybe they just standardized on some stupid software early in their history, and that it was easier to change the rotational period of the planet than to change the software. :-)

Causes of leap-year difficulties

Step back for a moment from the host of confusion seen around the leap year issue. It seems that one root cause is the deceptive simplicity and regularity of the ordinary calendar. Human nature seems to take regular things for granted rather quickly. If it would be more complicated, more often, people would probably be more cautious and get it right.

Generalizing, I see that many computer systems introduce the same kind of risk in other domains. That is, they simplify and make many activities and concepts more regular, but they can hide or postpone complexities and exceptions. When those exceptions occur, then people are typically not prepared to handle them.

But what's the alternative? Maybe it's enough to acknowledge the possibly hidden costs of (over)simplifying a domain for computerization.

[Whoa! More-complicated algorithms also beget more disasters. Oversimplified algorithms beget disasters. Modest algorithms can beget disasters. That's why RISKS is here. PGN]

Solving the year problem through 3979 [old style]

Experts in ASCII already know how to solve the two-digit year problem: designate the years following "1999" as "19:0", "19:1", and so on.

By the time we reach \255 in the `tens' position, 8-bit bytes will be a thing of the past and we can just keep going.

All we've got to do is get the calendar makers on board, and we can save the world $500 billion (or whatever the latest ridiculous year-2000-reprogramming-price-quote is).

Hmm, maybe I should have patented this scheme, then I could sell it for only $100 billion or so.

[David included a noncommercial reuse copyright notice in his posting. The generic risks.info file (which no longer accompanies every issue, to save space) says essentially the same thing, and so I normally truncate all such copyright notices. In this case, the only important thing is that no one else patents this wonderful idea and tries to charge David for using it. I suppose hex-based folks may have already come up with a scheme for postponing the problem for another 600 years by naming the century years 1A00, 1B00, 1C00, ..., 1H00 following 1900, but I hope not. PGN]

Re: bleep-year (Tepper, RISKS-17.86)

May I suggest that the underlying problem with millennial and leap-year software is a lack of incentive. Perhaps the major software firms could mutually agree that stock options awarded during the next two years be exercisable on, and only on, 29 Feb 2000. Care to guess what problem moves to the top of every project's punch-list?

In the same vein, year-end bonuses should be payable only to employees of record on 01 Jan 2000.

Re: Bleep year (Tepper and Hadley, RISKS-17.86)

>Let's just leap from December 31, 1999 straight to January 1, 2001.

There is one bright spot concerning the misperceptions over the beginning of the twenty-first century: two chances for a big party. Why risk missing the true millenium? You had better hit both just to be sure.

And Max Hadley wrote:

>The rules for converting from a seconds count to a date and time are
>arbitrary, complex, and subject to change at short notice! ...

JavaScript uses a millisecond based system (since January 1, 1970). There are built-in methods for converting between dates and milliseconds, but there is an error in the Mac version - it is always a day ahead of the result yielded by the Unix and Windows JavaScript date functions. (I am fairly certain that this is a beta error and not a political statement. :)

And regardless of your accuracy, you must still deal with different date formats. I am thinking of how today can be both 3/8/96 and 8/3/96, depending on your position on the globe. (That's one hell of a time zone...)

Time, days, and water

Fred Cohen wrote, >The solution to the leap- >obsessed with time ...

Computers do many useful tasks where precise timing is crucial. We may not be obsessed with time, but deciding when to turn out a steel mold is still something we can't afford to get wrong. (A previous comp.risks told of daylight-savings time causing molten steel to be dumped on the floor.) As long as time stamps on files are used for building programs, it will be important for networked systems to be within a few seconds of each other.

The solution is to store time, and do comparison and computation, using *only* the number of seconds from a fixed date. The length of a second is one of the few time of day-related things that doesn't change.

"lucero" <lucero@optec.army.mil> referred to Earth's rotation speeding up
because of water stored in reservoirs, and mentioned an author in Geophysical Research Letters claiming that "reservoirs are the only human activity big enough to cause an appreciable change in these global phenomena." This author has apparently forgotten about global warming. If, as some predict, the ice caps melt enough to raise the sea level by several feet, this will surely make more difference than reservoirs.

Year 2000 and Unix `struct tm' (Urlichs, RISKS-17.87)

In Risks 17.87, Matthias Urlichs writes about the Unix `struct tm' date-time interface:

IMHO, if the library is changed to return a four-digit date
instead of modulo 100, not much will break

Actually, it would break a lot of programs, including CVS, Emacs, gawk, expect, GCC, Ghostscript, INN, mh, perl, pine, RCS, and zoo (I just checked).

There are in fact three things you can do:

1. drop the modulus nonsense and return the year in full,
2. just subtract 1900, so that the above algorithm continues to work,
3. return % 100, as before.

Search RISKS using swish-e