Slashdot Mirror
The Story of a Microsoft Patch
buckethead writes "eWeek is running a story about a security patch from Microsoft that failed to adequately address a denial-of-service flaw on CSRSS (Client/Server Runtime Server Subsystem), the user-mode part of the Win32 subsystem. It stems from a research paper from Argeniss that discusses how Microsoft only patched one path to the vulnerable function, but they forgot to do proper research to identify all the paths." From the article: "The problem was that Microsoft didn't patch the vulnerable function; they just added some validation code before the call to the vulnerable function, but what Microsoft missed was that the vulnerable function can be reached from different paths and the validation code was added on just one of them"
A Microsoft Microsoft patch? That's the worst kind!
I'm liable for bugs in my software.
I'm not liable if my patches fail to patch the bug.
I'm not liable if my patches make more damages than the pathced bug.
If I do the same in restaurant business I get jailed!
It would be great at least a "pay after use", just like pizza: do you use to pay for pizza after or before you ate it?
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
Stuttering in the summaries? "It stems from a research paper from Argeniss that discusses how Microsoft Microsoft only patched one path to the vulnerable function, but they forgot to do proper research to identify all the paths." From the article: "The problem was that Microsoft didn't patch the vulnerable function; ...... but what Microsoft missed was that the vulnerable function can be reached from different paths and the validation code was added on just one of them"
Freedom is fragile and must be protected. To sacrifice it, even as a temporary measure, is to betray it.
Cue all the "Microsoft doesn't remove the causes of bugs but only fixes symptoms" comments
Why didn't they fix the vulnerable function in the first place (is there a specific reason)? Sure, adding validation seems like a quick and valid fix, but a company the size of MS should have known in the long run, fix the function instead.
KeepTrackOfIt.com - Find the lowest gas prices in your area graphically
As Microsoft have "intergrated" all their api's into one core buggy OS it doesnt suprise me. Fixing the actual function would probably crash loads of others. But hey thats the microsoft way..
..
Frankly it would be better if they started over again.. Look at the situation now.. even M$ themselves have to create infect a machine to track down spammers instead of fixing the root problem. Its like an aircraft with Gaffer Tape holding it together (with a paint job to make it look cool in new version of windows vXXX).. and they couldnt blame weather
I also feel really sorry for m$ coders.. they have a lot of talent but they are probably in a situation where they dont want to mess with code too much as changing things will bring the whole system down.. and a lot of chair throwing.
As Ballmer is a coder himself maybe he should join the troops in the basement and get to the fix and a steady system. Only them will users believe that Wind is a truly great system. At the moment m$ are in denial.
The article criticizes Microsoft for not fully understanding the vulnerability, and issuing an incomplete patch.
I understand that in a best case scenario, a vendor should release a 100% effective patch. However, in reality, that's not always going to be the case.
Microsoft released a patch that stopped the public vulnerable attack vector. Then, once they were alerted that they didn't fix all possible vectors, they issued a new patch (albeit quite a few months later).
With the large amount of bugs and vulnerabilities that a software behemoth like Windows is going to have, is it really that unthinkable that an incomplete first-patch would be released? I'd wager that even OSS products routinely have incomplete first-patches.
From TFA:
It's being called the "story of a dumb patch."
Soon to be a 200-part epic, starring John Goodman as Steve Balmer.
Coming to a Windows Vista box near you!
Now we get to listen hundreds of people who's programming experience consists of 5000 lines or C/Perl/Python tell everyone what the proper process is for matching vulnerable code.
At least they tried! And mommy says thats what counts.
The Story of a Microsoft Patch
A Tragedy in Three Acts
Now wait a minute...
(1) Let's see some proof of that Samba exploit
(2) Are you seriously saying that some kind of Samba exploit is anywhere near as serious as this csrss.exe vulnerability?
Has any Windows security problem ever hurt Microsoft's stock price?
I checked MSFT a couple of times when mail-based malware was running amok, seriously enough to reach the general news media. No effect.
If that's the overall pattern when it comes to Microsoft security issues and Microsoft's business success, it goes a long way toward explaining security missteps like MS05-018. There's no direct incentive for them to master security.
org.slashdot.post.SignatureNotFoundException: ewg
Maybe because they didn't really care about the other ways to get in, but all they cared about in this case was their image to the outer world, and thereby being able to say "See, look at us, we patch our flaws immediately".
Why didn't they fix the vulnerable function in the first place (is there a specific reason)? Sure, adding validation seems like a quick and valid fix, but a company the size of MS should have known in the long run, fix the function instead.
One possible reason is that changing the code to make it "safe" would have broken application compatability. I would be very surprised if this was not the reason...
This would explain why, instead of fixing the underlying problem, they chose to wrap it in validation to reduce the risk. It sounds like they did not do a complete analysis of the problem, but I think that's a method problem rather than a rundamental flaw in how they fixed it.
But when it's found "Hey, calling this function with these arguments causes a crash", why *isn't* fixing the function the first thing that comes to mind?
You can either:
1) Give some references, or
2) Accept the Troll moderation you are about to recieve.
Your choice..
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
Bugger. My mod points expired.
That's the most sensible and balanced Microsoft-related post I've read in quite a while.
The problem, as far as I can see, is that CSRSS.exe, which implements some important parts of win32 (important enough for the kernel to die in sympathy if CSRSS dies), is also responsible for the menial tasks of drawing console windows.
If the code to draw console windows were in a separate, unprivileged process, or even better a library, this bug would not be particularly exploitable. The worst DoS possible would be to prevent anyone from making console windows until the process was restarted.
There was another console bug a few years ago, see here. Printing a few tabs and backspaces to the console would cause the machine to blue screen.
...in my case, I have found that the total disk space consumed by Windows 2000 patches is bigger than the original Windows 2000 install itself! To make matters worse, I am now very low on disk space. I console myself by the fact that disk drives are cheaper nowadays. Whether these patches actually work as advertised is an open question, but I have my doubts though. All I see are a bunch of Hot Fix entries and nothing more.
We decided to tell IBM, and they patched it. But not fully: the same hole was still open. It was not anymoe possible to access the configuration data by appending a dot, but this time is was enough to add a "%20" to the filename or something similar.
Instead of moving those configuration files out of the webroot!
There is always going to be the same fundamental flaw in software development: humans.
Humans write the original code that produces bugs. Other humans (who may or may not fully understand the code they're working on because the original developer left the company) write patches to fix those bugs and in the process of doing so, create new ones.
Its the nature of the beast, it happens everywhere. Don't get me wrong, Microsofts overall record is pretty weak and I think they have made some serious design flaws with their OS, but to write a whole article on one bugfix smells a little like flamebait to me.
A Microsoft bashing story on Slashdot??
Nobody but MS can fix it, and if they don't do a good job (Epp said the specific error points to a "bigger problem" at Redmond because the company is well aware of the principles of checking string copy functions to stop buffer overflows. "[These] principles seem to have been missed by the developers working on the patch."), there's not much else others can do. If MS software and patches are not reliable, that is a problem for those running MS software.
As a developer, there are times we'll just gloss over a security problem to get the worst of it fixed ASAP with the least risk of breaking something else in the progress (and there are also holes that I'm desperately hoping no-one finds before I have time to completely rewrite the code, and beat to death the programmer responsible for it in the first place, but that's a rant for another day).
It's possible that the first fix was just a temporary measure they knew wouldn't break anything else, while they rewrote the problem function and put it through proper testing. On the other hand, this is Microsoft, so I may be being overgenerous here...
Here is an example, perhaps, where FOSS has an advantage. Microsoft might not be able to fix the function because it is "in the wild" and there could be many dependent "already-compiled" applications which would/could be affected. In the FOSS world where backwards binary compatibility is not an issue, a source patch could be made available. Oftentimes the way these sorts of problems are handled by Microsoft is they roll out a new updated API, leaving the old ones in place. This obviously doesn't address the installed base of buggy code, but fixes the problem going forward - assuming they can convince the developers to adopt the new API. Unfortunately, this course of action is also not applicable to a security patch scenario. So, MS issues an imperfect patch addressing, hopefully, the most flagrant problems, and queues the function as one needing to be deprecated in a future release.
The more you regulate a company, the worse its products become.
This is a valid approach, if the hole was being exploited by script kiddies or an automated worm. If your system was being DOSed, you would take the quickfix rather than waiting two weeks for the proper one.
A huge unidentified virus is approaching the Computer. It was made in the far past by another life than the human race, and occupied and inhabited by a vicious exploit in the long period. In order to save the Computer, the strongest Windows patches go into action.
You can hold down the "B" button for continuous firing.
This happens over and over and over again— with some users, I'm afraid to upgrade their software because their "world" sadly depends on the cargo cult execution of gestures to get their work done. Too many applications change how they look and feel with every upgrade that many users go off the rails whenever that happens. At least with an application, you can kind of avoid it, but when it's Windows— aw man, why not just fix the SECURITY HOLES instead of changing the UI? Please, Microsoft?
Screw it [sic; I'm being polite.], I'll keep my Mac OS X for clients and Gentoo Linux for servers and any web service that doesn't suck (Gmail, Basecamp, etc.), thank you very much.
Microsoft's days are over the moment Google decides to market an operating system that includes GFS for redundant data-storage and their MapReduce for batch processing. These things are big contributors to how its even possible for Google to exist. Simplicity trumps mediocrity.
One must also consider the possibility that the folks doing the coding and the quality assurance (SQA) may not be the original authors of the specific branch involved, and therefore did not have the proper experience level required to do the research and make the judgement calls. With the rumored turnover Microsoft has seen lately, I wonder if this is not a possibility?
More and more of the post-development activities (break/fix, SQA, implementation/packaging, etc.) for software are happening in little bubbles, somewhat removed from the core competency group that created the original code. We even see this touted as the right way to do things from sources that are considered to experts in the process + workflow arena (well, some folks consider them experts, anyway). When this becomes the standard operating procedure, any company runs the risk of bad patches to any kind of software: you can not limit the culpability to Microsoft.
when it rains, it gets real soggy. when it pours, i'm under the tap just _waiting_ for the joy
It's a glitch in the Matrix. It usually means they've changed something...
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
I attended a data security meeting held at the university where I work. We had a guest speaker from Microsoft who spoke on the subject of security. Microsoft is attempting to release security patches more often because their patches are being reverse-engineered in under two hours. The speaker also mentioned that an organization needs to respond to security threats in a more agile manner. On a side note, Microsoft is using agile software practices. Is it possible that they have misunderstood the agile mantra of good enough software?
Even whatever it was, anybody - vendors, users, whoever can fix it there and then. Try that with binary release only...
I'm wondering if the bazaar model would have tested every path as well? Or would they have tested only a few, and let the community stumble across the others? "A thousand eyes, all paths are shallow".
More likely if they fixed the function, then they would have had to produce patches for all the affected packages. Lots more time, energy and money. The pressure from sales and marketing would have been quite hard.
The missing part of this story is that, yes, it's OK to fix the function with a wrapper or a rush-release. However, they must have known that there was a long-term problem so MS should have procedures which can handle the tracking of problems like this. In the company I work for, we have just such a system, and we're just small-fry. If MS haven't got these procedures then, whoops, their bad. Their request-management must be chaotic to say the least. Anyone know how MS handle their request-to-release management? It can't be a state secret surely.
Patriotism is a virtue of the vicious
I see your point and agree that the practice is necessary, and that in another case they might have had a good reason, but according to TFA the quick patch was released on the 12th of April. The full patch was only released this month, and only then after Cesar Cerrudo released a paper on the inadequate patch. Not really the time gap you'd expect if they'd intended a full patch in the first place.
To know recursion, you must first know recursion.
Okay enough with the MS bashing. Granted they do a lot of stupid things. But you forget they still have some of the brightest programmers and intellectuals in the industry. Bar none. Yes, not even the much Slashdotter-adored Google. Recall that these are the guys who made it through the series of technical interviews when you couldn't even get your name on the MS list. They're smart people, and THAT is the bottom line. As for the patch, okay bad call. They should fix the problem. However, this is also a business. They made an executive decision to patch the publicly known path of error first and later assign resources to address the core issue. Businesses do that all the time. You think Coca Cola shuts an entire plant down to figure out why 1 out of every 5 million bottles is an inch shorter than the rest? Or Toyota stops making Tacomas because every 50,000 miles 0.0001% of Tacomas have a trasmission problem? No, they make a short-term correction and address the issue at hand. Then they focus resources on the real issue.
Contrary to what you may think, I'm not a MS fan. But they do some things well. (And please don't say they dont because you know better. You do.) AND to your post, they DO hire some of the best minds in the industry. These guys are smart. Super smart. So don't post a 10 line reply on Slashdot trying to appear as if you understand the entire dynamics of the software development business and just know the right way to do things. Its ignorant and makes you appear stupider than I'm sure you really are.
Is a microsoft patch anything like one of those Nicotine patches that help you stop smoking? If so I wonder if my health care will cover it. I'd like to slap one of those on asses of my co-workers and help get them off their addiction to microsoft.
I guess one might consider Linux to be sort of a methadone. Something that hels you with your cravings for the bad stuff, but ultimately leaves you without that satsifying high.
Personally I useto OSX, but I'm not addicted. I could stop anytime I want to. I just don't want to that's all. Now excuse me while I watch the Genie effect a few times before I send this.
Some drink at the fountain of knowledge. Others just gargle.
And you end up with 100 different methods of fixing the bug.
Has any Windows security problem ever hurt Microsoft's stock price?
If it does, the stock price might actually go up. Companies will buy another ISA server to protect the server from its defects. Of course, Microsoft marketing does not factor in these costs to TCO. CIOs are technically backwards people but like the familiarity of a Windows screen so they buy readily into more Microsoft.
Only Microsoft could get away with producing the problem, make itself look like a hero for fixing or mitigating it and then financially benefit from the defects in the product. An ISA server is an admission of that. Why fix the problem when you can sell another server license, ISA.
Microsoft is a marketing company, and Windows is the biggest patched conglomerate software out there today. Few remain that actually understand it. Windows will eventually fail under the weight of it's patching.
Kind of reminds me of the Pied Piper.
Probably goes like this:
Coder(s): this will take two weeks to fix and test properly
Management: you've got four hours.
Does a Christian soccer team even need a goalkeeper?
And I guess that SUN users are sort of like grumpy reformed addicts who get religion, act smug, and scowl at everyone who indulges in sugar coated operating systems.
Then there's thoughs Atari and Xbox weirdos who are like 14 year olds who huff gasoline and destroy so many brain cells they never move on, trapped the vegitative of their pathetic twitching existence.
But when it's found "Hey, calling this function with these arguments causes a crash", why *isn't* fixing the function the first thing that comes to mind?
Logically your right, but Microsoft is a marketing machine. They would rather you buy another ISA server so they can profit from defects. http://www.microsoft.com/isaserver/default.mspx
I think that's the most poorly worded and redundant story intro i've ever seen on Slashdot.
If management do *just* that, then they deserve to go the way of the dinosaurs.
Patriotism is a virtue of the vicious
IANAP, but couldn't they have put the validation code in the function itself?
My new blog
Another bash at M$FT. Not fair, come on ... Slashdot out to destroy the giant now ?
Your analogy is partly right. Only MS and humans are different categories, because humans cannot read MS code. MS can make mistakes, and MS can fix them, but other humans don't get a chance to look at the code and fix it as well. So only a smaller subset of humans can look over MS's code, the same ones who made the mistakes in the first place, and who can't get input from other humans. It would be less likely for mistakes to remain in MS's code if they weren't the only ones working on it.
The lack of documentation (or source code) for certain functions is also biting them in the ass, because the programmer cannot tell if the output is correct or not compared to a reference (documentation/source implementation) or if they are getting that output because a bug was triggered. The programmer will assume it is correct if the function keeps working the same, but they won't know that a bug was involved in helping their program work the way THEY intended even if it's not working the way it's supposed to. So we end up with a bunch of applications that may get broken, and if the vendor is out of business, they may never run again if certain bugs are fixed.
Twinstiq, game news
Maybe this will make them feel better?
Microsoft has a rigorours testing and regression process which ensures that quality products and patches are produced. That's why it takes them so long to release patches once issues are reported.
Yeah right... There's no news here. This is hardly the first time it has happened. Microsoft is slipshod and second rate in all respects.
For those of working on any windows app, if possible, as an experiment put your app through some memory leak detection software (like Purify etc). I'm sure you'll be as shocked as I was to see how many OS level buffer overflows are happening at any given time. There's so many of them that it makes sense, from a cost perspective, why MS simply fixes the ones that matter as they come up.
Translation: "I'm going to defend Microsoft on Slashdot to get karma (it makes you look enlightened and individual to moderators), so in an article where Microsoft was clearly caught with their pants down, I'm going to instead distract the issue by mocking the coding experience of some of the commenters, as if that has anything to do with the #1 software company in the world not getting the 'software' part right. It's kind of like telling movie reviewers who've never made a movie before that they can't criticize movies."
"Sufferin' succotash."
Mabye some important software relied on calling that function with certain (different) arguments that would normally cause a crash but because the software did something special it does something else. It wouldn't be the first time software relied on a bug or security flaw to work properly, remember Ultima 7's use of 32 bit real mode or the way bleem bypassed the OS and created threads directly by modifying the LDT base address (the Win9x only MapLS/UnMapLS trick)? The reason Wine took so long is because they have to be bug for bug compatible with Windows without opening major security holes even though Wine has to emulate security flaws in Windows (like the WM_TIMER Shatter attack) because some software depends on the flaws being there.
"They happen to be very fast to identify consumer needs or technology trends (either by researching or copying others) and integrate them quickly in their product portfolio. I think that aggresive way to integrate new features tends to help a lot in writing bad code."
Well I'm sure glad that F/OSS doesn't quickly integrate "consumer needs", or "technology trends" into our code. No sir, we make you wait for unified sound, and GPU accelerated windowing systems.
The next time MS claims it fixes security holes faster then anyone else ...
Never underestimate the dark side of the Source
Then the programmers should say it'll take a week when it'll only really take a day ;).
But one method probably gets rolled into the official Samba project. Besides, I still haven't seen a cite of the actual so-called bug (I'm not saying it didn't exist, just that no one in this branch has gotten up off their ass to go find a cite).
Go ahead and mod me off topic but why was parent modded down? there's nothing trolly about it
All paths?!?!
How do we know in the future that this function won't be used again in something/somewhere else? Since we all know how "wonderful" M$ is at documentation, how many here think that there'll be a note in there that specifies something extra that needs to be done before the call to that function. Talk about wasted time/money.
You patch the function that needs to be patched, period. That way the vulnerability just goes away no matter who might call that function in the future. You also won't have to worry about "all the paths" as you kill them all with one stone.
Not patching the function in question is just asking for trouble later on.
Sheez. Talk about a neural misfire by this guy.
Yes, that is way to difficult for users. Users like the girl who called me about her brand new laptop that was working fine out of the box and then turned off and wouldn't turn back on (Plug it in, stupid!). Users like the guy who spilled some Sprite on his laptop and then, because he didn't want the keys to be sticky, poured water all over it! Get one of these people to even spell "emulator"--I dare you.
and PR is all about appearances.
Free Software: Like love, it grows best when given away.
(1) I think the previous AC was referring to the Samba 2.x series exploit that Digital Defense unearthed back in 2003. See http://www.digitaldefense.net/labs/advisories/DDI- 1013.txt.
Note that this is a remote root access by an anonymous user, as Samba is commonly deployed. It was indeed serious.
This vulnerability may have been the result of a vulnerability in Microsoft's SMB protocol itself, which also unpatched for about the same length of time. I can't recall at the moment, and I don't have backups of my notes from the time right at hand. It was a late night, I'm still sucking coffee, and feeling lazy.
(2) Strictly speaking, that would depend on your threat model, wouldn't it? That said, I would regard the vulnerability in CSRSS as typically being far more dangerous.
What you do with a computer does not constitute the whole of computing.
IMHO, the top of the thread wasn't flamebait, or a troll. He was correct about the vulnerability, though as I said above, this may have been due to a problem with MS SMB, which was then reverse engineered into Samba. That reverse engineering effort is *hard*. It's not too suprising that something could slip through.
Also, Samba has had a few buffer overflows, etc. It's not like OSS is immune to this sort of thing. There just tends to be less of it, and the fixes tend to be both quicker and of higher quality, for widely deployed packages, at any rate.
The MS bashing does get tiresome, even to a Unix-lover such as myself. It's just so damn *easy* that it occasionally gets to be repetitive and boring. And I do wish he'd taken the trouble to look up the reference--the burden was definitely on him.
Mods--over to you.
What you do with a computer does not constitute the whole of computing.
There are different levels of competency in any organization. This particular bug is the result of one person's mistake and could just as easily have been done by the original author as anyone else. The fact that it was released to the public is the result of a flaw in the process. For the prices Microsoft charges, they should be able to build in a measure of redundancy and reliability into their process.
This space intentionally left blank.
The best way is to take your time estimate (1 week), strip the units from it (1), double it (2), and finally add the unit back in, using one larger a unit (2 months).
;-)
Some more examples:
3 hours -> 3 -> 6 -> 6 days
10 weeks -> 10 -> 20 -> 20 months
"Your effort to remain what you are is what limits you."
http://channel9.msdn.com/ShowPost.aspx?PostID=6830 2
The above is a very large (168 Mb)* video interview with the team.
*Could someone transcode this down to a more reasonable size?
That's why MS does this.
You can have all the protection you want and it doesn't help if the user thwarts it. The user owns the machine, they have ultimate control. They are not going to put up with not being allowed to do things like open attachments. So they have to do their best to educate the users and give them a chance to not screw themselves.
You have very little grasp of the problems involved in trying to make a machine secure without the owner's cooperation.
http://lkml.org/lkml/2005/8/20/95
Then slam the door in his face & eat pizza while waiting for the cops to show up.
Now that you've been arrested, take this opportunity to have some fun. Use your one phone call to ring up the same pizza place and order 20 or 30 pizzas to be delivered to the police station.
Laugh!
(and hope they give you a slice or two))
[Fuck Beta]
o0t!
I was going to mention Apple explicitly, but I didn't.
Yes, you have to enter your password to do root stuff on a Mac. But users are so conditioned to doing it that it ceases to provide much protection. Virtually all installers will ask for your password, so it'd be easy to put a worm out there that asks for it and then does bad things to your machine and others.
Like I said, it is difficult. Apple isn't succeeding either.
http://lkml.org/lkml/2005/8/20/95
No Mercy. No Regret. Just Kill.
If you are not going to roll back (who is?) then you culd probably get rid of all those redundant stuff.
Get into your %SystemRoot%. Delete all (and I mean it) stuff in hidden directories there, which have anything like kb... fix... in their names. Get advice or support @ your site, if you are uneasy at it, and do it under supervision, or get it done. Defragment. Clean the hives. That's all.
At the end of the day, you should have some 2 Gig more diskspace than in the morning. Take Ghost, Acronis or what-you-like for data rescue and use it on your spring clean system. Now you are truly done.
Yours, Waran
Sig? What sig?! Ah, sig! Sigh.
And I have had the opposite experience, so I have a feeling this particular issue has all kinds of contributing factors. Newer folks where I work have come to me asking about code that I wrote or updated as much as five years ago (and yes, I realize that five-year-old code can itself be a little disturbing), but I usually need just a couple of minutes to recall what was going on and why. The reason: comments.
This may be stereotyping - and if it is, please forgive my generalization - but over the past few years I have seen a noticeable dearth of decent comments in the majority of code I review or get pulled in to fix. There are exceptions, but they are rarely where (and when) you need them. I should have put this in the original post, because upon further reflection I wonder if the lack of good documentation - in the code or in another repository - is also a contributing factor to a lot of half-assed patching.
This is all IMO, of course; I hope I see more of the exceptions than the rule.
when it rains, it gets real soggy. when it pours, i'm under the tap just _waiting_ for the joy
http://216.239.59.104/search?q=cache:xSevAZ0lKYEJ: www.argeniss.com/research/MSBugPaper.pdf+&hl=en&cl ient=firefox-a
/.ing
seems that whoever was running the server that paper was on pulled it presumablly because of the
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
You do realize:
If you are moderating in this story, posting a comment will disable all previous moderations and ban you from moderating in that story
and
You have no control over other moderators and you're an arrogant fucktard if you think you speak for all the moderators here.
and
Read some of the security mailing lists to prove that your sorry fanboy ass is so fucking wrong that its not even funny.
That sort of defeats the argument.
It is no different to wait for a vendor patch to a closed source product than it is to wait for an "official" patch for an open source product.
Yes, it is different, because you have the option of using an unofficial patch (yours or someone else's) in the interim.