Hacker Newsnew | past | comments | ask | show | jobs | submit | wahern's commentslogin

1) IFUNC is hardly the only way to run code before main.

2) The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process, whereas with IFUNC the GOT will eventually be made immutable (or can be... not sure if that's the default behavior). In general function pointers aren't great for security unless you explicitly make the memory backing the pointer(s) unwritable, which at least is easier to do for a global table than it is for things like C++ vtables (because there's the extra indirection through data pointers involved to get to the table).


> The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process

They also suggest an alternative to storing the function pointer, store the bit flags that decide which function to call. That restricts the call targets to only the legitimate ones intended.


Yeah, this blog is misguided. As a higher level criticism: it's confusing[1] the technical details with the payload with the exploit chain that deployed it.

The interesting thing is obviously not that you can get code to run at high privilege level by modifying a system component. I mean, duh, as it were.

The interesting thing is that the attackers (almost) got downstream Linux distros to suck down and deploy that malicious component for them. And that's not down to an oddball glibc feature, it happened because they got some human beings to trust a malicious actor. GNU glibc can't patch that!

[1] Incorrectly, as you point out.


> The alternative they present is arguably less secure because the function pointer will remain writable for the life of the process

The article mentions this, and also points to mprotect which you can use to protect the pointer.

Why people jump to criticize without reading first? BTW, you can ask an LLM to check your critique, before posting, if you don't want to read the text.


Yes but at best their "solution" is equally secure, not any better.

They argue, and I tend to agree, that their solution is more secure.

1. It impiles some function pointers to be writable temporarily, not all of them.

2. It doesn't hide writable pointers from a cursory glance not familiar with IFUNC.


The GOT has to be initially writable regardless of ifunc, even with relro, to apply relocations.

Would xz still have been able to alter opensshd without IFUNC?

You can always populate .init_array section with a hidden constructor. It would work just like ifunc and would always execute at shared library load time.

Yes, liblzma could have used multiple routes to take over sshd. Once you're running inside the process it's game over. The exact details, like how they used ifunc and an audit hook, are very interesting, but ultimately not that important.

The term "Latin mass" confuses two distinct aspects. Colloquially it refers to celebrating the Tridentine Mass in Latin. But the Tridentine Mass was already celebrated in the vernacular years before Vatican II, though it was optional and I don't know how widespread it was. The Vatican II reformed mass was expected to use the vernacular in most parts, but it can also be given in Latin, and Latin is the canonical form against which translations are made.

I've been to a Latin mass a couple of times, specifically a sung (aka high) Latin mass. I see why so many people prefer it. But the Novus Ordo can also be sung. Latin masses also tend to use incense, etc, which also used to be more common in the Norvus Ordo. The real division is between parishes and priests with the energy to put into the mass, versus those that fall into the habit of doing the bare minimum. The "Latin mass" just happens to be a convenient mechanism that bifurcates the two groups.

Relatedly, I read a argument somewhere that the current state can be traced back to the proliferation of Irish priests. In Ireland the low (unsung) Latin mass had apparently been for centuries the predominate form even on Sundays. I'm not sure how accurate that is, but reading various sources it does seem that in various parts of the world the sung mass had already been in a long decline at least since the 1800s. And I think the Norvus Ordo was intended to simplify things in the hopes of reviving the energy in the mass, but instead it just created a lower floor.


I've heard the same re. the Irish.

Regarding the Novus Ordo, I believe that the key document from Vatican II (Sacrosanctum Concilium) still preferred Latin as the dominant language in liturgy, while readings etc. stayed in the vernacular, but clearly that is not what happened.

There's been an uptick in numbers for Tridentine Rite, so tides might shift back as Catholics realize the wealth of their liturgical tradition.


It's the other way around. It's the C runtime that treats text ("t") mode differently, because the C standard specifies \n as a line delimiter but the Windows convention is \r\n. In text mode C stdio translates between \n and \r\n. In binary mode it does no translation.

Note that when neither is supplied, the text mode is the default. This is why I said that it is the C library handling the "b" flag.

> such authors... ignore highly inconvenient results?

There are plenty of examples where that does seem to happen. Not sure if anyone has done a comparison with rate of non-publication by non-interest group funded studies. Probably difficult given there's not much motivation to uncover non-publication without the anti-corporate sensationalism.


Regular surpluses can cause famines. This is what happened in East Africa in the 1980s. Cheap grains from elsewhere (Europe, US) caused farming to become unprofitable. Domestic/regional traditional farming of grains largely ceased as farmers moved to the cities. This happened very quickly, so consolidation and mechanization of farming to become competitive never happened. When cheap imported grains became unavailable in the 80s, for various reasons, it was too late. (The war in Ethiopia is often cited as the immediate cause, but people have always managed to farm through wars, usually at least enough to avoid the Ethiopian situation.)

It's an extreme case, but that same sort of pattern has happened repeatedly throughout history. Keeping some amount of farming economically sustainable is important. You don't necessarily need direct public subsidies, but you definitely want to avoid long periods where prices are too cheap to make farming of important crops not economically viable.


> The war in Ethiopia is often cited as the immediate cause, but people have always managed to farm through wars, usually at least enough to avoid the Ethiopian situation.

This isn’t true. See the Thirty Years War. There have been many wars in the past that have led to mass starvation by making the work of agriculture impossible. See also the depopulation of Sichuan during the Ming- Qing transition.

Separately the Ethiopian war was subsidised by western food aid and other aid to the Dengists.


DNSSEC doesn't change the degree to which DNS is decentralized. It's always been hierarchical. In the absence of caching, every DNS query starts with a request to the root DNS servers. For foo.com or foo.de, you first need to query the root servers to determine the nameservers responsible for .com and .de. Then you contact the .com or .de servers to ask for the foo.com and foo.de nameservers. All DNSSEC does is add signatures to these responses, and adds public keys so you can authenticate responses the next level down.

A list of root nameserver IP addresses is included with every local recursive DNS resolver. The list changes, albeit slowly, over the years. With DNSSEC, this list also includes public keys of those root servers, which also rotate, slowly.


The word "thread" is confusing things. In computer science a thread represents a flow of execution, which in concrete terms where execution is a series of function calls, is typically a program counter and a stack.

There are many ways to implement and manage threads. In Unix-like and Windows systems a "thread" is the above, plus a bunch of kernel context, plus implicit preemptive context switching. Because Unix and Windows added threads to their architectures relatively late in their development, each thread has to behave sort of like its own process, capable of running all the pre-existing software that was thread-agnostic. Which is why they have implicit scheduling, large userspace stacks, etc.

But nothing about "thread" requires it to be implemented or behave exactly like "OS threads" do in popular operating systems. People wax on about Async Rust and state machines. Well, a thread is already state machine, too. Async Rust has to nest a bunch of state machine contexts along with space for data manipulated in each function--that's called a stack. So Async Rust is one layer of threading built atop another layer of threading. And it did this not because it's better, but primarily because of legacy FFI concerns and interoperability with non-Rust software that depended on the pre-existing ABIs for stack and scheduling management.

Go largely went in the opposite direction, embracing threads as a first-class concept in a way that makes it no less scalable or cheap than Rust Futures, notwithstanding that Go, too, had to deal with legacy OS APIs and semantics, which they abstracted and modeled with their G (goroutine), M (machine), P (processor) architecture.


If you're using a container as a sandbox, one should use a default deny policy and allow only the facilities required by the container. Though, in practice containers are used to package a huge collection of software, most of which the container creator has no familiarity with and no ability to determine what runtime dependencies, beyond other package names, are required. This one of the reasons why containers, generally speaking, don't offer reliable security. If you can't or won't carefully design your components to sandbox themselves (e.g. by using seccomp and landlock with policies tailored to the specific component), like Chrome or various OpenBSD daemons, then it's far better to use VMs for isolation; and if you do design your components that way, containers are superfluous from a security perspective.

There's been several studies. The same phenomenon happens in the US among a subset of people who frame the voices in terms of older cultural narratives like, e.g., hearing the dead (i.e. traditional Western spiritualism), or with immigrants who came of age overseas. The critical elements seem to be 1) how the culture primes the person to frame the hallucinations, and 2) how family, friends, and other community members receive the claims. If both are positive or at least benign, it's less likely for the symptoms to become debilitating. Stress has a well known and very strong effect on progression of the disease. If you have angry, scary, violent voices, or when the community around you reaffirms the negativity and pathological nature of the voices, your stress levels go up tremendously.

The priming effect is huge, I think. American culture loves conspiracy theories, and conspiracy figures prominently in the experiences of American sufferers. Likewise for tropes like nefarious government surveillance, not to mention how both are infused with literal and tacit threats of extreme violence, or demands of violent responses. That's just not true to the same degree, if at all, most other places, with notable exceptions being other Anglo countries, which share similar cultural histories, not to mention sharing to a much greater degree Hollywood media which express and popularize these kinds of stories.


> and those are regularly treated as sacred

They indeed are treated as sacred, it's enshrined in the Takings Clause of the US Constitution. The big problem in the American West it that the model of property rights in water sources makes it very difficult as a technical matter to put a price on a specific claim and to adjudicate disputes, without triggering a cascade of pricing and rights dilemmas upstream and downstream (figuratively and literally). Western states could in theory exercise eminent domain to take back water rights, and I think they occasionally do, but it's just very fraught from countless legal angles even before getting into the politics of it, which compound the headaches a hundredfold (partly because of the interdependent nature of everybody's rights). Most of the time Western states try to hack around the issues with complicated regulatory and taxing schemes to try to claw back some semblance of control over water resources. But it's very inefficient and ineffective. Property rights are useful because you don't need to centralize all pricing and usage decisions, or when you do--e.g. regulation, taxation, eminent domain--the mechanisms for applying those decisions are simpler and more mechanical; but Western water rights are just a different kind of beast. What's needed is comprehensive reform that tries to shift the American West to a better water rights model, specifically a better model for how property rights inhere in water resources, to drastically improve transactional efficiency, both from a legal and market perspective. But there's no simple way, and in particular no cheap way from a budgetary perspective, to get there even if the motivation existed to get around the monumental collective action problem, which it doesn't.


> But there's no simple way, and in particular no cheap way from a budgetary perspective, to get there even if the motivation existed to get around the monumental collective action problem, which it doesn't.

It seems like maybe there is though.

The first problem is the "use it or lose it" provisions where someone has the rights to use water but not sell it, thereby encouraging waste. That one has a solid solution: If they have the right to use it, they get the right to sell it. Make sale inalienable from use. Then you don't have to pay them anything because you're giving them something instead of taking it. But you get higher water availability as now all these people wasting "free" water start selling it because the opportunity cost of not selling it is now worth more than the wasteful use. The only "problem" here is that they get a windfall, but we can solve that in the same way as the second "problem".

Which is the takings clause. The purpose of that is to prevent unequal takings. If the government needs your land to build a railroad, they have to pay you for it, because they're taking yours but not anyone else's. Whereas when they take everyone's property at the same rate it's called property tax, and that's allowed. So if you just got a windfall of water rights in a dry place, congrats, you now have a valuable property right which is subject to property tax. Not using the water and don't want to pay the tax? Then sell the water. Since the buyer values it at more than you do, and the tax is less than 100% of the value, everyone comes out ahead compared to the status quo. The previous inefficient user gets $100 in money instead of $10 worth of inefficient use, the government gets some proportion of that in new tax revenue (variously property tax on the rights and income tax on the sale), the buyer gets water it values at >$100.


Can you explain the issue from a more basic level for people who don’t know? what i’m imagining is that, like, an aquifer might connect over a very large area and every property owner in the area has the right to extract as much water as they want from it? Leading to a tragedy of the commons situation that states are unable to regulate for some reason?

Short answer: it's complicated. A somewhat longer answer: "Cadillac Desert". Marc Reisner. 1986.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: