unix command sanity check

[john guardian]

Why not run the java cmd for the version?

That's a very good question. Long story short is that some cellar-dweller mushroom-head of a Solaris Admin in the Montgomery, AL area reported a potential security issue (root priv escalation) when running ANY command, not just JAVA with the -v, -V, -version or version arg options, etc. So management all over the company is jumping on this OMIGOD bandwagon and all the admins here need to find a reliable alternative to check apps, like java, for versioning across our entire enterprise. Not just HP-UX though. We also have other vendor 'Nix products as well.

I just happen to have responsibility for the JAVA app(s) that run across all computer systems.

Thx.

[Steven Schweda]

Still rivaling mud in the clarity department.

So, you're trying to determine the versions
of some set of programs of some type or other
without actually running those programs?

Good luck.

This whole thing sounds like nonsense, by the
way. If you're worried about, say, a
non-root user running, say, "java -version",
and blowing up the world, then you may as
well just turn off all your computers.

man strings

(On the bright side, "strings" doesn't seem
to have a "-v"-like option, at least on
HP-UX.)


> [...] reported [...]

Sounds like an interesting report. Goofy,
but interesting.

[john guardian]

No. The worry isn't that a normal user would do this. Just that root would. The thought is that the binary might actually be a malicious root toolkit that root activates when running the cmd to interrogate it for the version.

[john guardian]

BTW: strings might work great for "some" of our systems. But others use backporting to update the executable, so strings wouldn't pick that up as most if not all vendors who use backporting don't bother to update the version, and thus the version string reported by the strings command.

That's why I'm looking for a single "best" approach to making the job easier and more generic.

[Steven Schweda]

> [...] Just that root would. [...]

So, not really a "root priv escalation"
problem, more of a root priv exploitation
problem.

> [...] don't bother to update the version,
> and thus the version string reported by the
> strings command.

And if someone patches a program to insert
this greatly feared exploit, then you _would_
expect to find a changed version? Really?

It sounds to me as if your actual concern is
(or should be) the integrity of your files.
This can sometimes be verified using
checksums or direct comparison with
known-good files. I can't imagine how
extracting some kind of version string from
any executable will reveal anything of any
great value.

> That's why I'm looking for a single "best"
> approach to making the job easier and more
> generic.

Again, good luck. Unless I completely
misunderstand your goal, you would seem to be
doomed. (To either hard work, or meaningless
results. Probably both.)

[john guardian]

we have to check versions from time to time when upgrading OTHER apps.

Checksums are great, but that requires ALOT of manual labor locally on every machine.

Look, I can't go into detailed explanations here because there's a book's worth of info I'd have to tell you.

Rather than knocking or wondering why I'm trying to get this info w/o using the above described method, could you offer any other positive, tried and true means of doing so?

I'm looking for solutions, not discussions within an encounter group.

Thx

[Steven Schweda]

> Checksums are great, but that requires ALOT
> of manual labor locally on every machine.

Why "manual" labor? Why not a shell script,
or some other automated scheme?

> Look, I can't go into detailed explanations
> here [...]

> [...] could you offer any other positive,
> tried and true means of doing so?

So, you want precise solutions, but you don't
want to provide a precise description of the
problem? My psychic powers are too weak to
be of much use in such a situation.

From your description so far, it's unclear to
me exactly what you want, partly because what
you seem to be looking for would seem to me
to have approximately no value.

> I'm looking for solutions, not discussions
> within an encounter group.

You may need what you're not seeking more
than what you are.

[Dennis Handly]

>If you did, can you send me the cmd used along with the screen output?

After fixing the missing single quote I get more awk errors:
awk '/assemblyIdentity version=/ {print $2}' $(whence java)
awk: Input line cannot be longer than 3,000 bytes.
The input line number is 61. The file is /opt/java1.4/jre/bin/java.
The source line number is 1.

[Dennis Handly]

>If you did, can you send me the cmd used along with the screen output?

After fixing the missing single quote I get more awk errors:
awk '/assemblyIdentity version=/ {print $2}' $(whence java)
awk: Input line cannot be longer than 3,000 bytes.
The input line number is 61. The file is /opt/java1.4/jre/bin/java.
The source line number is 1.

strings -a doesn't find anything either.

[john guardian]

To Steven S: The company I'm doing this temp job for requires that I be as non-specific as I have been. It is NOT how I would like to present and talk about the issue. When working for someone else, I simply respect their wishes, even if it means it's that much harder to solve a problem. I asked a simple question, "please run a cmd and copy me with what your output looks like". Instead you answered my question with more questions. Not helpful, but thanks for the reply.

To Dennis H: Yes Dennis, I know there's a missing single quote. One of the hazards of typing too fast, but you've never done that, correct?

Your reply could have been much more helpful if you had attached whatever output you were getting from a screenshot or cut-and-paste, whether it was good, bad or otherwise. But thanks, as it was more helpful than some of the other replies in terms of actually trying the cmd to get some output.