Sun has released JAVA 6 update 13. This release contains multiple security fixes 254569, 254570, 254571, 254608, 254609, 254610, and 254611.
Most of these are privilege escalation vulnerabilities. 254569 can allow malicious code to be executed.
Archive for March 2009
Java Runtime Environment 6.0 Update 13
Session IDs and Anonymous Surveys
My company is using a consulting firm to run a survey on employee engagement. The survey is supposedly anonymous and only aggregate data is viewed.
When I went to take the survey, I noticed that the URL was https://www.%externalvender%.com/Base/Custom/%company%/survey.asp?Survey=42&UserSessionid=23419&l=1
Being a security professional, I opened another window and started decrementing the UserSessionID in the URL. Sure enough, I began seeing other employees responses. Even in an anonymous response this should not happen. Users are prompted to supply their division, location, age (optional), length of tenure (option) and ethnicity (optional). If the optionals are supplied it shouldn’t be hard to figure out who filled in the responses. Users shouldn’t be able to see other users responses.
The URL is HTTPS so I figured it wasn’t a caching issue on our end, but just to be sure I reproduced the results from an external computer.
So what lessons can be learned here? First, dont use a predictable session ID (in this case it was sequential). I’m not a web security guy, but I’m thinking a cookie could be used also to prevent this session browsing as well.
update- This problem was reported to the vendor when I discovered it. They found that it was caused by a recent update. The removed the update.
Thunderbird Updated
Thunderbird 2.0.0.21 is out.
The security fixes are listed here
MFSA 2009-10 Upgrade PNG library to fix memory safety hazards
MFSA 2009-09 XML data theft via RDFXMLDataSource and cross-domain redirect
MFSA 2009-07 Crashes with evidence of memory corruption (rv:1.9.0.7)
MFSA 2009-01 Crashes with evidence of memory corruption (rv:1.9.0.6).
apsb09-04: Adobe Reader/Acrobat 8.14 and 7.1.1
http://www.adobe.com/support/security/bulletins/apsb09-04.html
As scheduled Adobe has released updates Adobe Reader 8.x and 7.x.
While Adobe has taken a lot of flack for their handling of this patch, I appreciate that they gave dates for releasing the patches and held to it. Its not like some previous Adobe patches where 7.x owners were urged to upgrade rather than waiting for a patch that might never get released.
Caching and Product AutoUpdaters.
I noticed today that Adobe Acrobat 9 Professional wasn’t able to download updates when “Help .> Check for Updates” is selected from within the product. Using Wireshark, I obtained the URLs used to request updates from Adobe. Comparing the results inside my network to those outside of the network, I determined that the BlueCoat proxy on our network had older page cached.
The cached statistics for that page claimed that it had verified with the server that it had a current copy of the file. I blew away the cached content and set swupmf.adobe.com to ‘no cache’. The Adobe Acrobat client was then able to see that updates were necessary.
The Adobe server used eTag. That should have prevented this problem.
Caching can cause issues. When it causes issues with autoupdate mechanisms, would you even notice.
ISA 2006 and Forms Based Authentication
I’ve been working on upgrading ISA 2004 to ISA 2006 (on new hardware as well). We use SecurID authentication at ISA, and then Forms Based Authentication on the Front End OWA server. While this had worked fine with ISA 2004, it didn’t work at all under 2006.
A quick Google found one post on a Microsoft forum with the same problem. Their conclusion was that this was not possible. The poster cited a ISA 2006 book as saying it was an either/or situation. “You can’t do Forms Based Authentication on both ISA and OWA.”
Fortunately, I searched a bit more and found a solution. http://support.microsoft.com/kb/935206
I found I already had files newer than those in the referenced patch. By running the script and configuring OWA publishing as a regular web publishing object, I was able to get it to work.
Adobe 9.1
You should already know this but Adobe released the 9.1 update. This patch needs to be deployed ASAP. Updates for 8 are expected by March 18th. I’m not sure if updates for 7 will come out then or later.
I checked SMS and found that around 10% of our systems have Adobe Reader 9. Our standard is 8.1.3. After I packaged 9 for deployment, I was told that Adobe Reader 9 has a conflict with another application we use. So I’m a bit surprised that this many systems would have 9.
So it looks like I’m going to have to deploy Adobe Reader 8 and 9 updates. For Reader, Adobe didn’t release a MSP, so it’s a full upgrade.
Adobe does release a MSP for Acrobat, the update is only a single increment. So to upgrade from 8.0.0, several patches must be applied. I hadn’t realized that until this week. We’ve been giving users some bad instructions.
BlueCoat ProxyClient
I’ve been interested in extending HTTP security out to our remote users. When users are in the office their HTTP traffic is antivirus scanned and URL filtered. When remote, they only have desktop antivirus to protect them. As more and more users are mobile, I think it is important to address this.
BlueCoat offers a ProxyClient that can provide traffic acceleration and URL filtering. The URL filtering occurs the same way as with K9 or with a Phishing filter. The URL is sent to their servers and categorized then allowed or blocked accordingly.
Location based rules are created so that acceleration or URL filtering is enabled as appropriate.
I quickly found that the release notes weren’t kidding. SMB signing is incompatible with CIFS acceleration. I was hoping that the traffic would still be accelerated through compression and byte caching. My tests seemed to show that traffic was a bit slower when acceleration was enabled.
The dreaded FIPS complaint setting
(Ok, a typo in the subject, but it was funny so left it in)
The Technet blogs require registration to comment, and don’t allow me to use my Microsoft Live account to log in, much less openID. I didn’t feel like registering for yet another “community” so I left without commenting.
The ISA server product team blog at Technet wrote about a case where the customer Cannot Browse a HTTPs Site Published by ISA Server 2006 without using TLS 1.0 on Internet Explorer
I chuckled reading that headline because I’ve been there before.
When I upgraded to ISA 2004, I installed from scratch and applied a recommended hardening policy. I tested it with my computer using Internet Explorer and Firefox, and went home happy. I couldn’t understand why I received email from my manager reporting that people couldn’t get in.
I figured out relatively quickly that my system had TLS 1.0 enabled and the systems that couldn’t access using IE did not. That lead me to the FIPS compliant setting in group policy. I actually blogged about this in 2006.
The problem also occurs if you configure that setting on the clients. In January 2008, I also wrote about this setting and the FDCC and what a mistake I thought it was to require clients to turn it on.
