Showing posts with label vulnerability. Show all posts
Showing posts with label vulnerability. Show all posts

Monday, October 18, 2010

Oh Java, Why Do You Hate Us?

Brian Krebs, writing in his Krebs on Security blog, comments on reports from Microsoft that the number of attacks against Java vulnerabilities has overtaken attacks against Adobe products. Adobe is obviously breathing a sigh of relief.

Says Krebs:

My research shows the reason for the spike, and it precedes the 3rd quarter of 2010: Java exploits have been folded into a number of the top “exploit packs,” commercial crimeware kits sold in the hacker underground that make it simple to seed hacked or malicious sites with code that exploits a variety of browser flaws in a bid to install malware.

All automation, all the time. Point and click assaults on known threat vectors. If you install it, they will come.

I'm less concerned because I run Linux boxes, but I still exercise caution with the Java in my environment. Relying on Java's auto-update feature has proven woefully inadequate.

Krebs has previously recommended removing Java from your machine if possible, but it's so intertwined with browsers and third-party apps that successfully getting Java off and keeping it off is a Herculean task.



Thursday, August 5, 2010

Critical Adobe Reader Flaw Virtually Ignored

If a tree falls in the woods and there's no one there to hear it, does it still make a sound? Such is the conundrum faced by philosophers for generations.

What if a critical flaw in Adobe Reader was demonstrated before a group of security professionals at the Black Hat conference and none of them made a sound, either?

That's what Charlie Miller must be thinking. He's the security expert that presented the vulnerability at Black Hat. His lament?

"Adobe security is so bad that […] not a single person tweeted it. Sad."

Adobe has acknowledged the flaw and is said to be working on a fix. Whether the patch is released out of band or at Adobe's next scheduled quarterly security release remains to be seen. Also unclear is the list of versions impacted by the vulnerability. The only good news is that there are no reports of exploits in the wild.

Some question how many more security blows Adobe can endure before going down for the count. My response is to look at Microsoft's track record. Many years into their latest secure coding push, Redmond is scheduled to release 14 patches to close 34 vulnerabilities in their August 2010 Bulletin Release. This mandates a massive amount of testing and deployment for enterprise customers, yet Windows is still the dominant operating system and office suite. The cost of switching away is substantial due to user training, infrastructure, and application impacts that it's almost cheaper to stick with the ugliness you know.

The same holds true for Adobe. It's the PDF reader with the most saturation, and not just among corporate environments. Home users are virtually guaranteed to have Adobe Reader installed on their systems, even though fully functional alternatives exist. Many have found Reader installed as a bundled offering from another application. The home user is also more likely to have an unpatched operating system and outdated software offerings, making exploit trivial. Antivirus protection? Please.

Adobe's install base and numerous versions places the company in the same predicament as Microsoft. There's a lot of old, insecure stuff out there, and even offering an automatic update solution only partially solves the problem. If Adobe can get 80% of the vulnerable installs patched, that still leaves hundreds of thousands, perhaps millions, of ripe targets out there. And when the next critical Adobe flaw appears - and you know it's when, and not if - the hamster wheel spins again.

My advice is the same as always. Dump Adobe products for less target-rich alternatives. A simple Google search on PDF readers will return scores of options onto your screen. Be sure to completely uninstall any Adobe software currently on your machine, being wary of third-party apps that might have plunked down some version while you whistled through a boring install routine. If in doubt, use Task Manager to look for processes associated with Adobe products.

Otherwise, abandon hope all ye who enter Adobeville. Like another Scream sequel, this will not end well.





Thursday, June 10, 2010

Adobe Flash Player Update Fixes 32 Security Flaws

It should tell you something that Adobe's latest Flash Player update, released in response to ongoing exploits of a particular vulnerability, actually plugs 32 holes in the buggy software.

The Metasploit Framework has code that targets the critical flaw previously reported, so don't mess around in getting this update installed. You'll need to run the update for each browser on your system, so if you use Internet Explorer and Firefox, remember to update both.

You can test which version of Flash Player is currently installed by visiting this site with each of your browsers. You can then download and install the correct version at the Flash Player Download page.

If you'd like more information about Adobe's security struggles, check out the following posts:

Critical Adobe Flaw Being Exploited In The Wild - Again

Adobe Reader and Internet Explorer: Most Attacked

The Adobe Attacks Keep On Coming

Adobe To Fix Flash Flaws This Week

Another Day, Another Adobe Zero-Day Exploit




Vulnerability in Microsoft Windows Help and Support Function

In the wake of a patch Tuesday that put forth fixes for 34 flaws, Microsoft has issued Security Advisory 2219475 for a publicly-released vulnerability in the help and support center function of Windows XP and Windows Server 2003. Successful exploit could result in remote code execution.

Google security researchers reported the vulnerability to Microsoft on June 5, and publicly released information about the flaw and how it might be used in attacks on June 9.

Microsoft is obviously cranky at Google for the public disclosure, as evidenced by their snarky entry within their Microsoft Security Response Center blog posting:

As always, Microsoft strives to work with security researchers to address vulnerabilities in our software. This helps ensure that customers receive comprehensive, high-quality updates before cyber criminals learn of - and work to exploit - a vulnerability. Responsible disclosure protects the computer ecosystem and individual computer users from harm.

No exploits in the wild have been publicly reported, and its Microsoft's hope that this remains the case while a fix is developed. The suggested workaround is to unregister the HCP protocol.

This isn't the first time flaws in Microsoft's help center have been reported. Thankfully, the vulnerability is not present in Vista and Windows 7 on the client side, or Server 2000 and Server 2008.

Don't expect an out-of-band patch for this one, unless widespread attacks begin popping up. 



Tuesday, June 8, 2010

Microsoft Security Bulletin for June 2010 Is A Doozy

Hope you weren't planning to take any time off for the next couple of weeks if you're a Windows admin, because Microsoft released their June 2010 patches today, and brother, you've got some work to do.

Ten bulletins addressing 34 separate vulnerabilities make up this month's offering. Products affected include Windows, Office, SharePoint, Internet Explorer, IIS, and the .NET framework. You know - just about everything outside of databases.

Three fixes in particular are worthy of your immediate attention. MS10-033 affects Windows and could allow remote code execution, so prioritize testing and deployment in your environment. MS10-034 is an update for ActiveX Kill Bits and Redmond deems it critical for Windows 2000, XP, Vista, and Windows 7. MS10-035 is a cumulative update for Internet Explorer that addresses six issues, only one of which was publicly known prior to release of the bulletin according to Microsoft.

SANS has a nice breakdown of the patches, associated CVEs, known exploits, and their recommendations for patching prioritization.

The Microsoft Security Response Center blog has Redmond's latest information about this month's bulletin.

As always, test these hotfixes in a dev environment to see if anything breaks before you deploy them into production, and make sure your antivirus and IDS signatures are up to date. It's typical to see the bad guys reverse-engineer certain patches seeking the root vulnerability that they can then exploit before patching can commence.

Home users should ensure that automatic updates are turned on and that your antivirus software is at the latest version with the most updated virus definitions.

Enjoy.

Saturday, June 5, 2010

Critical Adobe Flaw Being Exploited in the Wild - Again

Adobe systems is reporting that a critical vulnerability affecting Adobe Acrobat, Reader, and Flash is actively being exploited in the wild.

The previously unknown flaw could crash a user's system or result in the attacker taking full control of the affected machine.

Adobe's current advice is for users to delete, rename, or remove access to the “authplay.dll” file included in both Reader and Acrobat while Adobe works on an official patch. This may not be fully effective, given that other programs may also drop this key .dll file during installation.

From the Adobe Product Security Incident Response Team blog:

A Security Advisory has been posted in regards to a new Adobe Reader, Acrobat and Flash Player issue (CVE-2010-1297). A critical vulnerability exists in Flash Player 10.0.45.2 and earlier versions for Windows, Macintosh, Linux and Solaris operating systems, and the authplay.dll component that ships with Adobe Reader and Acrobat 9.x for Windows, Macintosh and UNIX operating systems. This vulnerability could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild against both Adobe Flash Player, and Adobe Reader and Acrobat.

I've written often about Adobe's struggle with securing their product sets, and this is yet another instance where consumers are left to essentially fend for themselves.

Given the Advanced Persistent Threat environment which has developed, third-party peripheral applications continue to be seen by attackers as low-hanging fruit as they seek attack vectors to compromise consumer and corporate hosts. Adobe products are often targeted because of the ease with which they can exploited, combined with a heavy deployment saturation and poor updating practices by home users and enterprise IT departments, to the point where Adobe recently implemented code to install updates and versions automatically.

I've said it before, and I'm saying it again. Get off of Adobe products if at all possible. You can limit your attack surface by 2/3 if you simply move to an alternate .pdf file creater/reader application, and there are many free programs out there.

For now, try to implement the mitigation Adobe recommends if you can't uninstall the products, and wait for a patch.

Tuesday, April 20, 2010

Adobe Reader and Internet Explorer: Most Attacked

One key to protecting your computer (and the data on which you depend) is to limit the attack surface. The fewer avenues for compromise you have, the better chance you stand of being passed over for a more inviting target.

If you're seeking the opposite approach - to become a flaming honeypot of vulnerability - run Microsoft's Internet Explorer and Adobe Reader. 
A hole in Microsoft's Windows SMB2 (Server Message Block) protocol was the most attacked vulnerability last year, followed by holes in Adobe Reader and Flash Player, Internet Explorer 7, and Windows MPEG2 ActiveX Control, according to a Symantec report to be released on Tuesday.
I stopped running both products ages ago, mostly due to the number of zero-day exploits that ran rampant in the wild targeting these two software gems. It's bad enough when you need to scramble to deploy patches before the bad guys reverse-engineer them to create and launch exploit code. It's a whole other nightmare when the attacks begin before the public, and often the software maker, are aware of the vulnerabilities.
Of Web-based attacks, suspicious PDF file downloads was the top method, representing nearly half of such attacks, followed by six attacks on IE, one targeting Adobe SWF (Shockwave Flash), and two targeting MPEG2 ActiveX Controls, the Symantec Global Internet Security Threat Report found.

Nearly half! And I can remember when people moved from Word documents to PDF files because they were seen as more secure. In fact, many companies explicitly blocked Word docs at the gateways but allowed PDF files to drive right inside.

Now, that's not to say that there aren't other products with more announced vulnerabilities than these two, because there are. But the perfect storm might be the combination of frequent flaws, plodding response by the software makers, and product saturation. IE and Reader are heavily used by home and enterprise users, and historically both user types have been slow as molasses to patch and/or upgrade their vulnerable Adobe installs, to the point where Adobe recently announced plans to automatically apply updates in the background without user notification or interaction.

If you don't want your car stolen, do some research into which are the most stolen vehicles and then don't buy one of those. If you want to keep your computer and data safe, look at the most frequently attacked programs and then don't install them. Pick something else that gives you a fighting chance.


Tuesday, April 13, 2010

Microsoft Security Bulletin for April 2010

Microsoft has released the April 2010 Security Bulletin, and it's a doozy!

It's imperative that you install MS10-022 now. The vulnerability in VBScript Engine is being actively exploited in the wild, and there's not a lot of time to waste on this one.

MS10-020 should be next on your list, as exploit code has been made public and there's sure to be attacks that leverage this particular SMB vulnerability.

Several others are rated as critical by Microsoft, so if you're prioritizing your deployment schedule, MS10-019, MS10-026, and MS10-027 should be next in line, as "consistent" exploit code is likely, according to Redmond.

In all, twenty-five vulnerabilities in various platforms and applications are addressed in this bulletin.

So much for the Trustworthy Computing initiative, eh? The only thing on which we can count is the high number of patches requiring deployment each month.


Monday, March 15, 2010

Microsoft Offers Temp Measure for Most Recent IE Flaw

While the IT world grinds its teeth waiting for Redmond to issue a permanent fix to close the weaknesses in Internet Explorer noted in Security Advisory 981374, the software giant has released two "Fix It" solutions to hopefully limit the impacts of the exploits currently being noted in the wild.

Microsoft claims that the first stopgap is a "solution for peer factory in iepeers.dll," while the second fix enables Data Execution Prevention (DEP) for those versions of Internet Explorer that happen to support DEP.

Both measures can be downloaded to a USB flash drive and run on affected machines one at a time. That's helpful for home users or a small IT shop, but it's not particularly scalable to the enterprise environment, and there doesn't seem to be any mention of automated deployment methods.

Read the updated advisory to get the details regarding which IE/Windows versions are at risk and to download the "Fit It" code, and make sure you have a plan to roll back the changes if you notice anything not working properly after you run the fix.

No word yet on when Microsoft plans on formally releasing a patch, but with exploit code being posted online, the pressure is on to get something out quickly. We'll see if this means another out-of-band critical patch release.


Tuesday, March 9, 2010

Microsoft Releases Security Advisory 981374 for Internet Explorer 6/7

If Microsoft Tuesday wasn't enough Microsoft news for you, Redmond has also released Security Advisory 981374 for a publicly disclosed vulnerability in Internet Explorer 6 and 7.

Microsoft's solution? Upgrade to IE8!


Redmond confirms that they are seeing targeting attacks against IE6, but no mention of IE7 except for the following:

Internet Explorer Protected Mode in Internet Explorer 7 running on Windows Vista helps to mitigate the impact of this issue.

Now, that's not quite the same thing as saying you're safe if you're running IE7. More to come, certainly.

The Microsoft Security Response Center blog entry is here.



Microsoft Patch Tuesday for March 2010

Microsoft has taken pity on us and released only two patches this month. This duo of fixes is associated with 8 CVEs.

MS10-016 maps to CVE-2010-265 and impacts Windows Movie Maker. No big deal there, so move this down your prioritization list.

MS10-017 involves a bunch of CVEs related to Microsoft Excel, but there are no known exploits in the wild at this time. This is a wide-ranging vulnerability, affecting all versions of Excel, Office 2004 and Office 2008 for Mac, the Open XML File Format Converter for Mac, Excel viewer, and SharePoint 2007. As is typical, a user would need to open a specially-crafted malicious file in order to get into trouble, but we all know that users click on anything that drops into their inbox, so patch this one sooner rather than later.

The Microsoft Security Response Center blog entry has more details, and the advisory can be found here.



Monday, March 8, 2010

Fiserv Wants You To Keep Using Vulnerable Adobe Reader

Updated 3/9/10 @ 3 PM: Fiserv has posted a response via the comments, and has also contacted Brian Krebs via email with the same information.

It's good to see Fiserv trying to get out in front of this, but it's troubling that a major player would make such a recommendation in the first place.



In a perfect world, large providers of money transfers and online banking services would want their customers to be as secure as possible.

So why is Fiserv telling their credit union and financial institution customers not to update their Adobe Reader installs beyond Reader 8.1?

It seems that security updates for Reader are causing functionality issues for Fiserv, to the point that they want customers to remain on a version that's two years old.

I can't even begin to count the number of serious vulnerabilities that have been reported - and are being actively exploited - on versions through the current 9.3. Staying on the current 8.1x version is both reckless and an invitation to compromise.

Brian Krebs has a detailed write-up on his Krebs on Security blog.


Serious Apache Flaw Reported

Numerous outlets are reporting a rather serious vulnerability in Apache web server versions prior to version 2.2.15. Anyone running version 2.2.14 and earlier needs to upgrade to 2.2.15.

The vulnerability is found in Apache's core "mod_isapi" module. Successful exploit of this module could allow an attacker to gain system-level privileges. At present, it appears this flaw impacts Apache web server on Windows platforms only.

Proof of concept code has been written by Sense of Security, and although the exploit is complex in its design, it will certainly be ported to various attack frameworks which will remove some of the technical acumen needed to run the exploit.

Since it's not trivial to determine if the Apache web server has been compromised, and given that data loss is a very real possibility, updating to 2.2.15 appears to be the only solution at this point. As with all things Internet-facing, make sure you do adequate regression testing in a dev environment before pulling the trigger in production.


Tuesday, March 2, 2010

Microsoft Users, Don't Press F1

If you're running any of the older versions of the Windows platform - Windows 2000, XP, or Server 2003 - and you're using Internet Explorer 6,7, or 8, it would be a bad idea to follow any pop-up prompts to press the F1 key.

Microsoft has released Security Advisory 981169 that details a zero-day vulnerability that could allow malicious code to be installed on your PC:

The vulnerability exists in the way that VBScript interacts with Windows Help files when using Internet Explorer. If a malicious Web site displayed a specially crafted dialog box and a user pressed the F1 key, arbitrary code could be executed in the security context of the currently logged-on user.

Sit tight and wait for Redmond to issue a fix. Sound familiar?


Thursday, January 14, 2010

Another Reason Not To Use Internet Explorer

Not a big surprise, but a zero-day Internet Explorer vulnerability was leveraged in the attacks against Google and 30+ corporate networks.

There have been so many holes in IE that I don't understand how it didn't collapse under it's own weight years ago.

From an attackers perspective, it makes perfect sense - corporations make extensive use of Internet Explorer in their infrastructure due to standardization and interoperability strategies, so the attack surface is quite large. Compromise the browser, add in a little remote code execution, and you own the computer the browser is sitting on, which you can leverage to compromise other assets on the network.

Newer versions of IE are less susceptible to these kinds of malicious activity, although it's still a pretty large target. You'd be better off running Firefox with the NoScript extension installed.

If you have to stay on Internet Explorer, at least upgrade to the latest version. There's still a lot of IE6 out there, which makes no sense at all, and it's one of the more risky browser choices. Move to IE7 at a minimum, with IE8 being your best option.

And good Lord, make sure your antivirus is up to date and that you're running Microsoft Update every month - hopefully via Automatic Updates.

For your peripheral applications - many of which have seen attacks and updates of late (hello, Adobe Reader), it makes sense to install Secunia PSI for home machines to let you know when you have vulnerable or end-of-life software that's a problem.

Let's be careful out there.



Monday, December 28, 2009

Microsoft Comments on IIS Vulnerability

Security blogs and websites have been reporting a previously unknown vulnerability in Microsoft IIS that could lead to remote code execution.

From The Register:

The bug stems from the way IIS parses file names with colons or semicolons in them, according to researcher Soroush Dalili. Many web applications are configured to reject uploads that contain executable files, such as active server pages, which often carry the extension ".asp." By appending ";.jpg" or other benign file extensions to a malicious file, attackers can bypass such filters and potentially trick a server into running the malware.

Microsoft has responded via their Microsoft Security Response Center blog in very carefully crafted language that essentially notes they are still investigating this "claim", that they aren't aware of any "active attacks", and that the only systems at risk are in non-default, unsafe configurations that fail to follow Redmond's best-practice guidelines. There's the usual boilerplate language where Microsoft whines that the existence of the flaw was not "responsibly disclosed," which means the researcher didn't call Redmond with the details and give Microsoft coders a year to sit on the vulnerability before doing something about it.

Since it's likely that not every web server admin is following Microsoft's guidelines, and fewer still are security experts, odds are good that the number of sites vulnerable to exploit is large, and the clock is ticking on the bad guys launching attacks configured with the appended file suffix.

If you're not following the best practices outlined in Microsoft's blog posting, you should reexamine your web configs and begin testing in advance of any forthcoming patch. Running unsafe configurations is asking for trouble, and even if Microsoft releases a fix for this particular flaw, your web presence remains at risk until it's hardened.




Tuesday, December 15, 2009

The Adobe Attacks Keep on Coming

Hackers are actively exploiting a previously unreported vulnerability in both Adobe Acrobat and Reader to compromise vulnerable computers worldwide.

And the Adobe hits keep on coming.

The flaw, in versions 9.2 and earlier, has been assigned CVE-2009-4324. Adobe's advisory provides very little information about the weakness being exploited in the wild, and no suggestions for mitigating exposure while we await a patch.

Initial reports point to turning off Javascript within the Adobe product itself as one method of protection, which might work for now, but as more exploits are crafted and launched, the delivery and execution mechanisms might change.

An alternative is to move away from Adobe products, as I noted here, here, here, here, and here.

Adobe continues to struggle with the security architecture of their products, and moving to a quarterly patch release hasn't given them the infosec street cred they were hoping to achieve. If you're still using Adobe to process .pdf files, then you're walking around with your pants around your ankles half the time as the bad guys have their way with you. Meanwhile, Adobe works on yet another patch for their leaky ship.

Bite the bullet and start using alternative .pdf products. Most of them are even free, so there's no good excuse for sticking with a vendor who keeps doing you wrong.



Tuesday, December 8, 2009

Microsoft Security Bulletin for December 2009

Hi there, all you Microsoft kiddies. It's Microsoft Tuesday, and you know what that means!

Today Microsoft released six bulletins that reportedly address twelve vulnerabilities in various flavors of Windows, Internet Explorer, and Office.


The good news is that Redmond released MS09-072 for Internet Explorer that addresses four privately-reported and one publicly-reported vulnerabilities in IE. Exploit code for IE6 and IE7 has been floating around in the wild for awhile now, and it's certain that malicious code targeting IE8 will result once this patch is reverse-engineered. Right now, it's significantly more difficult to attack IE8 since DEP is enabled by default if you're running IE8 on XPSP3, Vista SP1 or later, Server 2008, or Windows 7. Which reminds me - why are you still using Internet Explorer, for crying out loud?

MS09-073 targets a critical vulnerability in Wordpad which is unlikely to see widespread exploitation, since it involves someone sending you a specially-crafted .doc file created in legacy Wordpad 8 format, and you would also need to open it using Wordpad or Word.

Unless you're running wireless authentication via IAS using PEAP, there's not much to worry about with MS09-071, and if you don't use Microsoft Project, MS09-074 isn't applicable to you.

There's the obligatory vulnerability targeting LSASS (MS09-069) and another flaw in Microsoft IIS (MS09-070) that leverages a weakness in ADFS, so get to them sooner rather than later, but they can be toward the bottom of your priority list.

Microsoft Security Bulletin Summary for December 2009



Sunday, November 22, 2009

IE6 and IE7 0-Day Vulnerability Confirmed


Updated 5:20 PM 11/26/09: Microsoft has released v1.1 of this advisory, updated to include some mitigation steps. This is especially important given the types of exploits being noted in the wild.


Updated 9:45 PM 11/23/09: Microsoft has released Security Advisory 977981 concerning this issue.

Original post: SANS has reported and Symantec has confirmed a flaw in Microsoft Internet Explorer that could allow attackers to compromise a vulnerable system.

According to VUPEN Security:

A vulnerability has been identified in Microsoft Internet Explorer, which could be exploited by attackers to compromise a vulnerable system. This issue is caused by a dangling pointer in the Microsoft HTML Viewer (mshtml.dll) when retrieving certain CSS/STYLE objects via the "getElementsByTagName()" method, which could allow attackers to crash an affected browser or execute arbitrary code by tricking a user into visiting a malicious web page.

According to Symantec, the current exploit shows poor reliability, but that's expected to change and the reliability is expected to rapidly improve.

Recommendations are the same as always when Internet Explorer is involved - make sure your antivirus is up to date, disable JavaScript, and only visit trusted sites until Redmond rolls out a patch.

An alternative is to use a browser with a lower attack footprint, such as Firefox with the NoScript add-on.


Monday, November 16, 2009

Successful Twitter Attack Using SSL Renegotiation Flaw

When Marsh Ray discovered a vulnerability in the secure sockets layer (SSL) protocol that allows attackers to inject text into encrypted transmissions between two endpoints, we all knew it was only a matter of time until successful man-in-the-middle attacks leveraging the flaw began to pop up.

Now comes word that a Turkish grad student has successfully stolen Twitter login credentials that were passing through encrypted data streams, much to the consternation of researchers who recently called the recently-discovered flaw conceptually interesting but of little practical value.

Anil Kurmus was able to show that by leveraging the SSL bug, he was able to demonstrate just how wrong those researchers had been, both in the simplicity of the attack and the results that could be obtained:

Despite those limitations, Kurmus was able to exploit the bug to steal Twitter usernames and passwords as they passed between client applications and Twitter's servers, even though they were encrypted. He did it by injecting text that instructed Twitter's application protocol interface to dump the contents of the web request into a Twitter message after they had been decrypted.

Now, Twitter is some seriously low-hanging fruit when it comes to an attack surface due to its architecture and the volume of third party applications that do a poor job of error handling and reporting to the user.

Twitter doesn't help their cause by including the username and password with every request sent through their site. Their API also makes is relatively painless to intercept the contents of the data stream and use it to the attacker's advantage.

To their credit, Twitter claims to have closed the hole that previously existed. Et tu, SSL?

To date, only OpenSSL has provided a patch to deal with the core vulnerability. Every other implementation has been dorking around secretly for months preparing the bug fix that will need to be rolled out internationally.

Next likely attack scenario? How about stealing authentication cookies associated with web mail accounts or social networking sites that specialize in sending and receiving messages?

If your confidence in the core security guarantee associated with TLS isn't shaken, it should be.