Please create an account to participate in the Slashdot moderation system


Forgot your password?
Slashdot Deals: Cyber Monday Sale! Courses ranging from coding to project management - all eLearning deals 25% off with coupon code "CYBERMONDAY25". ×

Comment Re:Levels of Security (Score 1) 107

btw, I'm pretty sure you have an interesting point here when you said this:

Functional decomposition is a really poor way of abstracting complexity, when it's being used in isolation, and does not include mandatory boundary layer order and direction of operations over said boundary.

but I'm not entirely sure what you meant. Could you clarify? What other option is there besides functional decomposition?

DJB's philosophy is to minimize individual attack surfaces by reducing code complexity. This has three components, of which DJB himself is a proponent of two of them. I'm not sure whether this is because he doesn't realize that it's a consequence of his implementation paradigm, or whether he simply thinks it's too obvious to talk about. These are the components:

(1) Reduce complexity by separating the problem domains into individual processes. This separates necessary privilege escalations from other code, and separates cross-functionality address space based attacks on the code.

(2) Reduce complexity into functional time domains involving serialization of operations which could (potentially) otherwise take place in parallel. This is also done through use of individual processes, but is based on the trigger initiating the processes being separate, and therefore not under the control of an attacker. This increases the difficulty of an attack by requiring serial attacks for each component between the intermediate targets and the final target of an exploit (as in the previously referenced "shellshock" attack). For a shellshock attack, this particular precaution was meaningless, since there was a direct passthrough of the data without prevalidation without action before passing the data onto another component. In other words: the particular attack zips through this security precaution.

(3) This may or may not have been intentional, but he reduces the network and system call footprint for each of the components in such a way that it reduces the remotely accessible attack surface (you can only attack things you can talk to) to something which can be firewalled, and the system call footprint of individual components into something that could have local application sandboxing applied to prevent particular system calls being used by individual program components, or even sequences of system calls being used outside a particular order, or in excess of a particular number of times. This was probably not a design goal, given that neither deep packet inspection/stateful firewalls, nor sandboxing, were utilized in most systems at the time qmail was originally written.

That's cool and all, but it's taking a hammer to a problem which is actually a result of programmer discipline and machine architecture, and, frankly, some of those architecture issues have been addressed at the operating systems and compiler level for years, and others are better addressed through other mechanisms. It also failed miserably in intentional strategy #2, above.

The first mechanism is boundary layer violations. The most infamous email program in existence is Microsoft Outlook, and it's for good reason. Outlook engaged in interface layering violations. These are responsible for nearly all the initially exploited Outlook vulnerabilities.

What avoiding boundary layer violations means is that, if you are designing correctly, you identify architectural layers for your libraries in order to abstract complexity of each layer from the layer below it. As part of this, you define an interface contract: you are permitted to call down to the interfaces below yourself, and you are permitted to call across, within the same layer to auxiliary functions, but under no circumstances are you permitted to call upward. A good example of a boundary layer violation in libc is the use of a function pointer for the compare function in the qsort library routine, which will result into an upcall from the libc layer, to upper level code. In general, this should be avoided -- and if you have multiple protection domains, such as ring 1 and ring 2, which are generally unused by most operating systems, it should be prohibited in hardware. A "poor man's" version of hardware prohibition is achievable through a rather more radical utilization of large address spaces than is used in ASLR: statistical page protection. If you can't find the page, and if functions in a library are not laid out in adjacent pages in the process address space when the library is loaded, you can use a computed location based on a known call site to find an attack vector.

Another boundary layering violation which Outlook has failed on -- and which qmail periodically fails upon, and which constitutes a number of usable qmail exploits -- is container boundary verification.

In the second vector for Outlook exploits, after the layering violations are dismissed, we have container boundary verification. While qmail is not subject specifically to MIME based container boundary verification issues, it has its own problems with containers. In Outlook, these took the form of intentionally malformed data content being passed as part of a message. The easiest of these is the fact that, in order to render a message more quickly, and, specifically to support the rendering of HTML messages (which Microsoft still things are "Nifty!(tm)"), Outlook started decoding the container contents before verifying the validity of the container. Specifically, it would start rendering GIFs before they were verified to be valid GIFs, it would start rending other content before it was determined the content was verified to be valid content. This is where we get the "malformed attachment" exploits in Outlook.

The correct thing to do is to download the content, verify each container matches its purported size, and then the containers inside the containers -- images, audio, video, etc. -- are themselves valid, before handing them off to the rendering component. Outlook failed to do this, and treated the header as a dispatch item, handing off the data stream to the rendering component, which allowed a header on a container to cause mush more of the byte stream than the container boundary to execute payload in subsequent containers. Qmail fails in a similar way with the handing off to a renderer unverified content container content ...and this is precisely how the second component failed them in the shellshock scenario.

Most modern (predominantly research) security architectures have moved to a container-in-a-mailbox mechanism. You put the contents of the container into a mailbox, and then you run a verifier -- separate from the renderer -- on the mailbox contents, thus preventing an assignment of meaning, and therefore a communication of intelligence (attack data) to a target; only after that, do you hand the mailbox off to the content renderer.

Note that this application of containers in mailboxes has a couple of significant advantages: (A) it's really amenable to things like statistical memory protection, since if you run off the end of a page, you fault, instead of getting meaningful payload data, and (B) for hardening purposes, you can put the container contents end at the end of the page boundary, and index the start of the mailbox into the first page, rather than at the start of the page (you can do this, because you are aware of the content length as a result of looking at the initial container and having vetted it before mailboxing the data). This means that a scan forward into the container past the boundary results in an immediate fault, even though your hardware perhaps only supports 4K page boundaries, rather than byte-level mapping. And finally, (C), you can map the mailbox contents as read-only, non-executable, non-writeable, before you hand them off even to the verifier, thus preventing self-referential execution as part of an attack.

To deal with the issue of attack surface at interface layers, which is handled by decomposition into processes, instead you can rely on the link-loader. In most modern operating systems, the link-load phase is handled in the kernel exec/fork/spawn functions, which also manage ASLR. An alternative is to only make the addresses of code in inferior layers (one should never access data in an inferior layer, other than through use of an accessor/mutator function, rather than directly), you make known the function only at the call site. Further, you decompose the functions locations into groups of pages which are non-contiguous. Thus the fprintf() function in libc might (should) be in a physically discontiguous location from the gethostent() or other libc function. Thus address space decomposition is a better approach than functional decomposition based on role and program boundaries: it's much more granular.

There's at least 5 additional techniques that you might be expected to use, each with diminishing security utility, which you could utilize to do a better job than qmail does, but you get the basic idea, and I'm not going to write an entire paper here on Slashdot.

Comment Re:"Advanced battery technology" is a flashlight b (Score 1) 111

I see that the Tesla battery pack weighs 1,200 pounds. Reducing weight greatly improves efficiency, handling, braking, and acceleration, meaning lighter weight is all around better. It seems a bit wasteful of weight and materials to have 7,000 metal casings around 7,000 tiny batteries, connected with thousands of connections, rather far fewer larger cells. I'm surprised they don't use perhaps 24 or 100 larger cells instead, thereby eliminating thousands of unnecessary casings and connections.

There are a number of reasons.
1. 18650 cells are the cheapest per kWh, significantly so.
2. The smaller cell size helps with thermal management. It's easier to deal with the heat from using the batteries the smaller they are. There have been problems with airlines that use larger cells with them catching fire.
3. Power capability is actually higher with smaller cells. For a car with the acceleration of a Model-S, this is important.
4. Due to the amount of R&D into the cell, which is the most common LiIon cell in the world, weight and volume wise it's at least as energy dense as anything else, extra casing or not.
5. The connections aren't actually that big of a deal, most of the batteries are simply end-to-end.

Comment Re:I really wonder how other employers/employees.. (Score 1) 121

In the cases I have seen "contractors" have all been W-2s I should move to your part of the country, I hate being a W-2

The easiest way to accomplish this is to start your own contracting agency, and then employ yourself, and any friends who are in the same boat, as a 1099 worker. The bonus is that this will let you deduct most of your taxes as either "operating expense" or "capital outlay" on the part of the agency, you can run an expense account for most of the day to day expenses, including a car if you want, you can incorporate retirement fund operating company for the contracting agency to reallocate income into for the principals in the contracting agency, and you still get your 1099 job on top of it.

BTW: This is how most massage studios, day spas, nail salons, hair salons, and so on operate. Everyone who does the actual work is a 1099, with the exception of the owner, and maybe a hourly receptionist, if the business is big enough to merit one for bookings.

Comment Re:Two words (Score 1) 348

I'm normally not this rude, but I'm feeling a little put off by you, so I will take my gloves off this time to set you straight.

A few facts for you idiot.

Sure, fucktard. I'm listening.

1) Californias water problems are house made and not solveable by desalination plants, I doubt they would ever be economical in relation to just start with 'saving water'.

Adding together all the water savings every year since the conservation programs began over 20 years ago, you get slightly less than the 5 *billion* gallons a day which are used in the Sacramento Valley *alone* for growing rice for export, to cover evaporative losses from the paddies.

Or, you know: you assholes could grow your own food, since almost all that rice is grown for export.

Or you could build some reservoirs, but well, that would involve the government, needs tax money, god forbid the government actually doing something for the people.

Reservoirs interfere with the mating cycles of fish, and in particular, Pacific Salmon, but also with a number of endangered species.

While I think it would be great for the people in Los Angeles to get off their collective Hollywood asses, and build some cisterns, instead of directing all their rainwater runoff into the ocean, that would only make a small dent in the problem, since the primary problem is that California grows about 1/5th the food eaten in, and *exported from*, the U.S., and uses a lot of agricultural water to do it.

By the way: it's the same people who care so much about the fish that they are actually tearing down reservoirs and dams to save their habitat, who are violently anti-nuclear power.

2) Germany is a net exporter of energy, allways was and likely allways will be. That includes for most of the time France, there are only a few months in a row in 2013 or 2014 where we where a net importer versus France. Germany is exporting 30% - 50% of its energy production to the EU, you idiot.

See, that used to be true when you were running nuclear plants, but according to this Bloomberg article, that stopped right after you idiots shut things down after the Fukushima disaster because, you know, all your plants are in coastal areas subject to tsunamis, and you stupidly did what TEPCO did, and failed to upgrade sea walls and safety systems.

Oh wait. Your plants aren't actually in any danger from this.

Why did you idiots shut them down again? It's hard to believe that a country that birthed nuclear physicists of the like of Einstein and Heisenberg would be quaking in their boots over a problem in Japan caused by greedy middle management.

3) look on a damn map. How retarded can one be and claim that Parkistan is using 'thermal waste to desalinate water' ... and why should they? Again, look on a damn map where Parkistan actually lies.

"Pakistan has a 1,046-kilometre (650 mi) coastline along the Arabian Sea and the Gulf of Oman in the south"

I thought Germans were supposed to be good engineers. You are also aware that desalination is a generic term for water purification from various impurities, and can be applied not only to sea water, but also to well water, and waste water from other sources, right? Not that Karachi isn't on the freaking Arabian Sea anyway, as opposed to being land-locked, like you are trying to imply.

P.S.: Yes, that desalination plant was subsequently built at the Karachi nuclear facility.

4) The efficiency of pumped storage and lithium ion batteries is more or less the same, no idea why you disagree about stuff you simply can read up on wikipedia (pumped storage a bit above 89% and lithium ion batteries a bit above 90%, both depending on all the components involved, oops, you assumed lithium ion would be less efficien? Why? On what physical fact could that be based? )

Energy density of the storage, and the preexisting hydroelectric facilities having already had the land area committed to the water storage. It's call a parasitic use for an existing sunk cost. Like when Pakistan's Karachi nuclear facility takes its waste heat and desalinates water with it, instead of just directly using the atmosphere as a heat sink.

However there are countries/places where nuclear plants are used for dessalination, not really because of the lack of fresh water, but more because of savings if you build one combined plant instead of a water plant treating fresh water and a power plant. Parkistan is not sucha country ... with nuckear power below 5% of the contries power consumption and one of the countries with absolutely no fresh water problem ... that would be more than nonsense.

Here's a picture of the Karachi nuclear desalination plant for you. You can understand pictures, right?

I think that about covers disassembling your posting.

Comment Re:It's not Obama (Score 1) 307

And this is totally unlike what every other president did who had a 747 to hop on to?

Ooh, good retort! Anything that another asshole in the white house did before Obama totally excuses him, even if he's wagging a finger at us driving cars while he rides in a fucking airliner.

When did it become OK to be patriotic and yet call the elected leader of this country "that asshole" instead of The President?

Anyone who hasn't called a president an asshole isn't a true American.

I have more respect and love for the country

Do you really not understand the difference between a politician and the country?


Comment Re:Sakura Battery (Score 4, Funny) 111

My father has had various top executive roles in oil companies for the past two decades. We often crack jokes with each other about this sort of stuff. "Gee, dad, how was work - suppress any new revolutionary clean energy technologies today?" "Only two... and you know we've only managed to buy off twelve congressmen this month - total? *Sigh*, the business just isn't what it used to be..." "Oh, sorry to hear that dad... maybe you should start a new war, that always works." "Yeah, I'll bring it up at the next Illuminati meeting..." ;)

Comment Re:Levels of Security (Score 1) 107

I'm quite tired of the hi-tech this-security-is-hackable discussion. Of course it's hackable. Everything is.

If you think so and can prove it, then you can earn $1000 and eternal fame by hacking DJB's qmail. Over 15 years and still hasn't been hacked.

Actually, it has been hacked, and it's relatively easy to do.

Functional decomposition is a really poor way of abstracting complexity, when it's being used in isolation, and does not include mandatory boundary layer order and direction of operations over said boundary.

I really don't need to spend $1,000 worth of my time to argue with DJB, when he'll happily argue with anyone for free.

SCCS, the source motel! Programs check in and never check out! -- Ken Thompson