My Buffalo Terastation (HD-H1 0TGL/R5) is identified on my network as running apache 1.3.33
My IT guys say:
apache .lt. 1.3.37 contained a mod_rewrite buffer overflow attack, "RED, URGENT" update or get kicked off the network
apache .lt. 1.3.41 contained multiple vulnerabilities, mod_proxy, mod_imap, mod_status and mod_proxy_ftp, DoS, XSS, "YELLOW, MODERATE" update or get kicked off the network
If I want to continue using my drive, I must update to apache 1.3.41 or later.
nelsonm had a similar request in July (for a Terastation II Rackmount), Colin137 suggested that an update to apache was on the way. No action in that thread since July. I may cross-post this...
Please advise,
-csfv
@PCPiranha and Support team,
Is there any particular policy in place w/ regard to these type of security issues?
Industry audits are now counting my Buffalo NAS devices as 'Linux Servers' that I don't have root access to, so if there's a procedure or policy in place regarding security audits we could submit to the auditors it would be awesome. (i.e. I'm required to receive information from the root account manager, which I assume would be Buffalo?).
Either that, or are you familiar w/ how other companies are dealing w/ these type of requirements that have processes I could...'borrow' ;)
Ill see what I can do Rinthos... I will have to try to get that information from corporate.
What kind of documentation are you looking for?
Apprecite the assistance! :)
For supported (which makes me think 'under warranty') systems, something which would convey a 'regular interval' where security risks are evaluated against an industry repository and some sort of comitment from review cycle date to issue resolved date. EXAMPLE:.
"If you have a supported Terastation III and identify a security risk, please contact us as security@buffalo-security.com, or contact support and reference a security issue, and our team of specialists will evaluate the risk and if applicable will work to resolve it within the life of the product)
End Example.
More detailed example:
If I had a Redhat Linux Server w/ no third party applications (lets just say Rhel 4update 5), on a regular interval (ie. once every 90 days) evaluate my server against a Redhat patch repository and for security risks identified, provide a remediation target on my system of ~60 days. If someone named Tom is the system admin/root, I need a comitment from Tom to address security issues, since I can't, but ultimately I am responsible since I pay for the server.
I.e.: January 1 Review for Security Issues, by March 1 install applicable redhat patches (testing in between most likely). Start next review on April 1, etc
Obviously I can rely on Redhat (in this example) to perform most of the work, but I'm still responsible for the security of my server. So if a security issue is identified and Redhat is unable to address in my version (i.e. 4u5) I may have to update to 4u6 to resolve it (based on the availability of the fix).
I'm trying to push that Terastation/Linkstations are 'special devices/appliances' and not Linux servers, but the closest to compromise I can seem to reach w/ industry compliance partners is "The vulnerabilities then are based on external facing interfaces" i.e. Web Server, SSH, ftp, etc. (even if not supported, if the interfaces are enabled, they are in-scope). In some cases (Such as FTP) if I can disable the interface, it's acceptable, but obviouisly the 'apache' example here isn't disable-able (fun word).
Appreciate any help you can offer on this, thanks! :)
---
Thanks all for the responses,
Rinthos's idea sounds neat, and would help in my situation also.
I've been told:
"You must update apache to some new version immediately."
All I can reply is:
"I've asked the vendor, a patch may show up sometime between now and 6 months from now. Or never."
Some sort of audit response/schedule or at least an expected date for patch cycles would go a long way towards keeping my server alive. And it would keep me from getting yelled at on the "security-all" mailing list. I'm currently writing up a lien against my security violation notice, you can see how this looks bad, right?
[Edited to include thanks, sorry about that.]
i'm in the same boat as everyone, i just bought a tera station pro II rackmount and i need an apache and openssl update soon! if i don't t get an update soon, i may return the product! i'm hoping to get an exception from my network security personnel but, if that fails, i will return the product. does anyone know how to get root access? i read forums of getting in through modications of the UPS port, but i'm not doing it because i don't know what i would be doing.
How many TS Pro IIs do you have? (blitz49 and csfv)
Good evening, thanks for checking.
I own only one terastation (hd-h1.0TGL/R5), so I definitely don't count as a bulk consumer of Buffalo products. However, I would guess that my concerns are echoed by many other users, including the three or four posting in this and related threads on your forums.
Do you have an ETA on an apache patch? I'm currently trying to convert my security lien to a waiver, but I don't know if that will fly. I have told them that the vendor is not likely to release a patch in the next few months, we'll work it from there. Purchasing new hardware is an option, as is just building my own server -- though it was to avoid rolling my own network storage system that I originally sought out the terastation... I'm fundamentally lazy, and the terastation is so close to perfect for what I needed. I just didn't realize what would happen if my security needs got out of sync with the Buffalo team.
I'll check back to these forums every week or so until the lien expires.
Thanks,
csfv