Current and outdated references of secure C programming

C is the modern assembly language for many architectures, and still the most useful computer language for me. C does not have a rigid grammar and has a lot of variants and local dialects, and have revised a few times including the old UNIX C, ANSI C 1989 which first introduced prototypes, and C99. Finding out the de-facto standard elements of C is a complicated work. You can find a bunch of different indentation and writing styles on C code. I do not recommend a specific coding style in this article; I can only recommend you need to follow the mainstream style when working in a project. Sometimes you have to read the books for discovering what is the most right thing to do. I recommend following books for C programming now:

• C: A reference Manual (5th edition) (2002), which has a lot of precise and detailed examples on ambiguous usage;
• Secure Programming Cookbook for C and C++ (2003), which explains what to do and what not to do to write secure code; and
• Advanced Programming in the UNIX Environment (2nd Edition) (2005), which explains usages of modern UNIX system calls and libraries.

For practical programming, however, depending on books is not enough. Actually those books I recommended above are 5 to 7 years old as of 2009, so if you want to know the cutting-edge details of programming, you should read the latest software. Consulting a C compiler manual and well-written source code such as that of BSD kernels is a must if you want to write an efficient code (those are freely available). One thing to which you've got to pay special attention is that books are eventually but surely getting outdated. Books are not the Web articles; they are static and will not change. The lifespan of a reference book for computer science is typically very short these days, due to the rapid change of technologies. Books about C is not an exception either. And I should confess that a few days ago I decided to sell the following old worn-out books because I found out them simply outdated (and I no longer recommend the following two books any more):

• The C Programming Language (2nd edition) (1988)
• The Standard C Library (1991)

The reason that I found them outdated were as follows:

• They are old, written in approx. 20 years ago, and they do not reflect the changes of C99 and other additional elements;
• Not mentioning secure programming at all, including
  • avoiding reference to non-existent data objects,
  • preventing buffer overflows,
  • limiting the length of a string;
  and
• The C library structure and source have been changed a lot for these 20 years.

Frankly speaking, I loved those old books, especially which I referred to the most during my apprentice time of learning the language in the late 1980s. Those books were the only source before the Web. I had to repeatedly read the old bestsellers many times to discover the details. I do respect the authors of those books. They are pioneers of UNIX and C programming. Nothing is eternal, however; and I suggest use to stop using outdated reference books ASAP for every subject, not only for programming.

Moving away from heavyweight blogs

I admit I've been dormant on blogs. Instead I've been active on Twitter and Tumblr; you can be reactive and posting short messages on those so-called microblogging systems. Time is the most scarce resource for me, and I want something with smaller overhead to write.

I will not entirely remove the contents of this blog, but I will not post a new article here, without further notice.

FYI, the pointers for my microblogging URLs:
(Note: the tumblr sites have been deleted by July 2009)

• jj1bdx: quote of technology
  
• Cyberperiscope Reviews (in Japanese)
  
• Twitter: jj1bdx (in Japanese)
• Twitter: kenji_rikitake (in English)
• Concurrently Chaotic (in English)
  

Open-plan office and peer-monitoring socialism against creativity

When I started working as a programmer after I graduated from college in 1990s, I was fortunate enough to have a wall-separated booth, thoughwithout a door. This is something which workers have taken for granted atresearch laboratories in the USA or Canada. But things have beendifferent in Japan, where I live and work.

Having a separated space for individuals has been considered a luxury inJapanese companies, where people think space is money. So I should emphasize I was fortunate; because in Japan still corporateoffices are mostly open-planned: everybody seeing each other with nowall, whole bunch of noise, and is forced to listen to each other.

I had to work in 1980s with an open-plan office in Japan as an inturn,and I thought working in the office would surely hurt my body anddegrade the quality of my thinking. If I were just moving around anddoing ordinary tasks, I wouldn't have considered it much. But I had tothink there for writing a technical report. So I thought something hadto be changed.

I do not reject the idea of shared meeting space or the importance offace-to-face meetings. Those are vital factors of successful companies.But without a place for solitude, nobody would be ableto think. Without thinking, no innovation will come, and nonew idea will emerge. How can you think without being alone?

Recently I've found an article on Web which says working in open-planoffice makes you sick and is hazardous to your health.

A recent study of Dr. VineshOommen and his group in Queensland University of Technology showsthe following results:

Results: Research evidence shows that employees face a multitude ofproblems such as the loss of privacy, loss of identity, low workproductivity, various health issues, overstimulation and low jobsatisfaction when working in an open plan work environment.

Well said.

Tom Demarco and Timothy Lister also write in one of theirclassics Peopleware (2nd Edition, 1999, Dorset HousePublishing) as follows (in Chapter 12):

Management, at its best, should make sure there is enough space, enoughquiet, and enough ways to ensure privacy so that people can create theirown sensible workspace.

I've read the 1st edition of Peopleware (published 1987) in 1989, so theworkplace privacy issue is well-known for at least 20 years.

On the other hand, Japanese workplace has little changed for the past 20years. I still see many open-plan offices, especially amongnon-engineering workers.

I suspect Japanese open-plan offices are designed for managers to putthe subordinates under surveillance during the working hours. This isan example of a dark side in Japanese workplace socialism.

In a typical office layout, a manager in a team has the own desk besidesthe cluster of the desks for the team members. A team member can't takea rest or make a physical movement during working hours. I think thissort of desk layout does not respect the health of the team members, letalone the privacy or the productivity.

I've found quite a few articles about this open-plan office sicknessissue on the Web. So I think this is a matter of concern for manypeople. Maybe this is a sort of backlash due to the recent economydepression.

I'd rather work alone if I were put into an open-plan office every day again, solong as my brain and my ideas are the source of my income.

The risks of systems left alone and untested

Computer systems left alone unmaintained are a premier source of risks. Those systems may cause a serious crisis and a major service disruption.

On September 14, 2008, All Nippon Airways (ANA), a major Japanese airline, caused the disruption of the ticketing service due to the cryptographic function software expiration (as they announced in the Japanese press release), which is logically assumable about the PKI certificate, according to the other Japanese-written press reports like ITmedia's and Nikkei ITpro's.

The chilling fact revealed was that the ANA left the cryptographic function unused for 2 years and did not make a review about expiration at all when they activated the function for the terminals used by the ticketing agents. This is an awful example of software development indeed.

I wrote about the service disruption for RISKS-DIGEST 25.34 just after the incident occurred.  And recently I knew the article was quoted by another blog article yesterday.

The expiration issue is not only about the PKI certificate; domain name registration is another source of expiration risks. An expired domain can be abused for phishing and overtaken by attackers.  Software license is another good example.  In general, Expiration is a part of overall misconfiguration.  So when did you review the expiration date of the system resources under your control last time?

Chain of distrust

Communication is a collection of trust between the involving parties. Unfortunately, the trust is eroding in Internet, or in the society itself; and I see the emerging chains of distrust.

An idea called Chain of trust is a practical implementation of authentication.   Let me put it in this way; when Alice trusts Bob and Bob trusts Carol, then Alice assumes Carol is trustable.  In this way, Alice doesn't have to directly authenticate Carol.  Internet is another good example of chain of trust; each router assumes the peer routers will forward the packets originated from itself. 

But the chain of trust is not what should be taken as it is, in the real world.  In the Alice-Bob-Carol case of the previous paragraph, the peer-to-peer trust relationship between Alice and Carol is not necessarily established; the existence of distrust between Alice and Carol is even possible, and they may don't want to talk to each other.  Communication through a proxy is in fact quite common between the distrusting two parties. Should I call this a chain of trust?  I should rather call this a chain of distrust.

The current Internet is full of chains of distrust. Maybe I should rephrase it for accuracy; the chains of limited trust. For example, your employer will not unconditionally trust you to protect the employer's privacy, so you have to communicate outside the employer's network through a firewall, usually made of packet filters and proxy servers.  Your employer gives you a limited trust for the external communication.  This sort of limitation may cause your distrust to your employer, but the employer usually considers this is a security feature to protect the relationship with you.  The difference of interpretation to the situation of limited trust can be a source of distrust.

In a set of trusted parties with a limited size, each party does not have to spend time on authenticating each other for every packet they communicate with each other. The trust is proven through the physical connection and perimeters.  Internet's packet forwarding system extends this idea of physical connection to the chains of trust by reliable communication with discrete packet deliveries, and the idea has worked well in a limited community where the people are trustable with each other. The end-to-end principle [1] has worked so effectively that the engineers of Internet firmly believe in it.

The reality we are facing, however, is that the people are no longer trustable with each other and rather distrusting one another. People are seeking for a safe haven by creating a chain of distrust, which is apparently a false sense of security, considering that the chain of distrust is easily broken if the proxy between the distrusting two has a malicious intent.

We are heading into the very difficult times, where the security engineers ought to secure the chains of distrust as well as the chains of trust.

Reference:
[1] Blumenthal, M. S. and Clark, D. D. 2001. Rethinking the design of the Internet: the end-to-end arguments vs. the brave new world. ACM Trans. Internet Technol. 1, 1 (Aug. 2001), 70-109. DOI=http://doi.acm.org/10.1145/383034.383037

Working CW stations at the end of the year

I've set up an amateur radio station again this week, and worked some stations, including some friends. The transmission feeder is a temporary one, so I will disassemble and reassemble the system soon, after the new year vacation time is over.

Amateur radio for me since 2002 is mostly CW (Morse Code). CW is the most primitive but still practical digital communication form. The bit rate is about 10 to 25 bps (no kilo, mega, or giga) (that is 12 to 30WPM) and it's very slow indeed. You still can send something meaningful over CW, and it has been used for more than 100 years. See how people are using Twitter these days.

CW has already been phased out from the mainstream of professional communication systems, but it's still a viable backup, and ham radio operators still use it over shortwaves to exploit the maximum possibility of communication, to overcome the difficulties of natural and artificial noises, and significant path loss. On the other hand, the latency is minimal; only the path distance between the peers determines the delay time. It's the oldest chat system in the world.

The hardest part of CW is that you need to learn and have a lot of practice to listen to it. It's like learning another foreign language. Some eccentric people including me, however, choose this road less traveled, for many reasons.

Many old operators may find out their younger days of enthusiasm towards radio itself. And many hardware hackers will use CW for realizing the simplest but useful radio system with a pair of home-made transmitter and receiver. Whatever the reason it might be, still quite a lot of people devote themselves to CW. And I am one of them.

Working on CW is simply a good time for me. Learning for a faster CW listening stimulates my mind a lot. And CW reminds me of the very basic issues of digital communication; reliability, bandwidth, stability, latency, and practicality. The procedure of sending and receiving letters by yourself gives you more time to think.

I'm a computer engineer and scientist, and technologically CW is an archaic thing. The principle embedded, however, is still effective to be a fundamental motivation of pursuing engineering and scientific skills; to explore the road less traveled and discover the new world.

The following article of Jeff, KE9V may help you to understand why some old amateur radio operators are still enthusiastic to operate on CW: The Road Less Traveled

73 and have a happy new year 2009.

Kenji Rikitake, JJ1BDX(/3), JO3FUO, N6BDX and JQ2KST

My Influences

My influences on programming, Internet, and computer skills:

1. Tsuneji Rikitake, my father: who taught me basic math, FORTRAN, and financed my startup (of my professional career, indeed)
2. Paul Vixie and DEC NSL people: for the primary idea of firewalls and Internet systems administration, and the proper engineering attitudes toward problem solving
   
3. Daniel J. Bernstein: on re-thinking Internet protocols from the very beginning, especially on DNS
4. Bruce Schneier: for the basic philosophy and principles of security, not only for computer systems
5. UNIX gurus on Bell Labs and BSD communities: for the programming suite and styles, including C, awk, and Bourne shell
   
6. Joe Armstrong and the Erlang programming communities: for letting me know a practical message-passing-based concurrency
   

I know there are many other people I should put on the list, but I will just keep this list small.

My salutation to Chad Fowler and Kevin Smith for reminding me of this topic.