Skip to content. | Skip to navigation

Personal tools
Log in Register
You are here: Home Articles Newsletters Screen command, Intel Inside, MOSXSWebPassword 1.5b1, Exploiting Concurrency Vulnerabilities

Screen command, Intel Inside, MOSXSWebPassword 1.5b1, Exploiting Concurrency Vulnerabilities


I'm trying to be a bit more regular about sending out this newsletter, so here goes.


A fantastic little command line tool that seems to be little known. It allows you to set up a virtual terminal window that you can detach from, but it keeps running. This is great if you need to ssh into a server, set a long-running process going, then go home. If you just opened a terminal window and did that, the process would die once you disconnected from the ssh session by logging out or taking your laptop home.

Instead, before launching the long-running command, just type:


at the command prompt. You will get a splash screen and then a new command prompt. Except for one thing -- this is now running inside a /usr/bin/screen session. Type in the long-running command, then hit:


That's control-a, followed by the 'd' key. You're now back at your original command prompt, but the screen session is still running in the background. Disconnect, log out, go home, come back the next morning. Ssh into the server, then type:

screen -ls

This will give you a listing of currently running screen sessions. You should see something like:

There is a screen on:
1805.ttyp1.dhcp18       (Detached)
1 Socket in /tmp/uscreens/S-plsuh.

You can then type:

screen -r 1805

and you will be reconnected with your screen session. You can detach and reattach multiple times to the same session. The only downside is that it doesn't have a scrollback buffer, so if you're counting on scrolling back to see the printout this won't work. You'll need to redirect output to a file instead.

To end a screen session when you're done, type:




Unlike detaching from the screen session, this kills it off entirely.

Intel Inside Campaign Explanation

There was a bit of a kerfluffle recently over a journalist named Bob Keefe, who asked Steve Jobs, "Why doesn’t Apple participate in Intel’s 'Intel Inside' program (which pays computer makers for putting their stickers on its boxes and logos in their ads)?"

Regardless of whether or not question was an insightful one or not, I got some puzzled looks when I was discussing this with some colleagues, so I thought it might be useful to explain what the program is all about. "Intel Inside" is a co-op advertising program -- Intel will pick up part of the cost of running advertising if a computer manufacturer participates in the program, by putting stickers on their computers and including the logo in their flyers and other marketing materials.

Intel is not the only company that has a co-op advertising program; most manufacturers do. The idea is to build a brand in consumers' minds for a manufacturer further up the supply chain. For a commodity, the brand association for a buyer is the immediate supplier of the product. For instance, if you buy a head of lettuce at the supermarket, your association of the quality of that head of lettuce is with the supermarket — Safeway, Kroger, Stop & Shop, etc. However, if you buy a computer, your association of the quality of the computer is not necessarily with the shop that sold you the computer. More likely it's with the company that built the computer — Apple, Dell, HP, etc. By using co-op advertising programs, the computer manufacturers are trying to build their brands down the line, so that the brand of the computer is more important than the place you bought it from.

Most manufacturers co-op advertising programs are very attractive to the retailers who participate. Participation is likely to pay for most if not all of the costs of a newspaper flier in the Sunday ad sections, for instance. A retailer is in general trying to to out-advertise (or at least keep up with) its primary competitors — other retailers. The boost that the retailer gets from co-op advertising programs can be significant. I have heard anecdotally that co-op advertising programs can make up 50% of the advertising budget for a retailer.

Given that there's a lot of money potentially available, why doesn't Apple add the sticker and take advantage of Intel's advertising dollars? The answer is three-fold, I think. First, as most of the pundits have opined, Apple and Steve Jobs don't want to wreck the clean design of Apple's hardware with stickers. Second, and I think most of the pundits missed this, Apple already has a huge advertising budget that gets spent on ads in major publications and prime time TV spots, and Apple has the gross margins to support that budget. The amount that Intel can add to this for Apple is much less significant than if you compared it to your typical computer hardware manufacturer's advertising budget. Steve Jobs is a coldly rational and very creative businessman. If Intel was going to be able to contribute significantly to Apple's advertising budget through a co-op program, he would have found a way to make it work.

Third, I think that Apple is thinking long run. One of the points to note about co-op advertising is that it has the potential to make the downstream partner less important in the consumer's mind. A retailer has to get its name in front of consumers every week, since its competitors will do it no matter what, even if the advertising collectively builds the manufacturer's brand more than it does the retailer's. E.g., Best Buy needs to include an insert in every Sunday paper, or Circuit City will gain ground on them for mindshare, even though the ads (both Best Buy's and Circuit City's) build Sony's brand more than they do any individual retailer's. People think, "I want a Sony TV", rather than, "I want to buy a TV at Circuit City". Apple faces a different decision compared to Best Buy or Fry's. There's already a huge differentiation built up in people's minds between Macs and Windows PC's. If consumers are looking for Intel-based computers rather than Macs, then the distinction between a Mac vs. some Windows PC becomes much less sharp — which runs counter to Apple's whole marketing thrust.

MOSXSWebPassword 1.5b1

At long last, the "Joel made me do it" release. Back in March, Joel Rennich posted an article to, where he wrote: "A more secure way of handling the need for password resets would be to create a script, probably presented to the users as a webpage, that would allow a non-admin to change passwords only for non-admin users. I believe some of those among us have ginned something up along these lines. If you have we'd love for you to share."

OK, it took me a while, but I finally got the bugs worked out. Here it is in all its lush, plush smoothness! The new features are:

  1. Configure the entry page

  2. Configure whether to show a link to the admin reset password page

  3. Configure the URL that the user will be taken to after a successful reset

  4. Protect admin users' passwords from resets

  5. Non-admin users in a specific group can reset non-admin users' passwords

  6. Configure whether the status of non-admin user password resets is shown

I reworked the installer package to make it more reliable as well. You can download it from <>.

Exploiting Concurrency Vulnerabilities by Robert Watson

Robert Watson is one of the true geniuses in the security research community. He recently gave a paper at the Usenix Workshop on Offensive Technologies (WOOT).


He was kind enough to explain what was going on in these attacks to me back at WWDC. System call wrappers are an attempt to prevent attackers from exploiting system vulnerabilities by constraining the actions of processes running as root. For instance, you might allow a web server to run as root but allow it to listen only on a port 80. This would prevent an attacker who compromised the web server from putting in a TCP listener back door. Some examples of system call wrappers are Systrace, the TIS Generic Software Wrappers Toolkit, and CerbNG.

Unfortunately, these all assume that kernel operations are atomic — i.e., there is no way to interrupt them while they happen. It seems trivial once it's pointed out (but I can tell you it was a huge light bulb for me) that on a multi-process, multi-threaded system, kernel interruptions happen all the time. As a result, you can send in an innocuous operation, have it approved by the wrapper, then interrupt the kernel and substitute a dangerous operation instead.

A truly brilliant paper, and actually quite short — only 8 pages long.

Well, that's all for now. I still have a ton more stuff that I want to write up: how to push OD settings to clients via packages, how to tweak user account information from Open Directory using Excel & BBEdit, a script to reset a user's login keychain, and a login policy banner. Maybe next week.


Related content
MOSXSWebPassword 1.5
Document Actions
Add comment

You can add a comment by filling out the form below. Plain text formatting.

Please enter your name.